[cap-talk] Webkeys vs. the web

David-Sarah Hopwood david.hopwood at industrial-designers.co.uk
Thu Apr 2 20:34:49 EDT 2009

Sam Mason wrote:
> On Thu, Apr 02, 2009 at 07:07:05PM +0100, David-Sarah Hopwood wrote:
>> I don't see any significant difference in expected user intent between
>> clicking "[Copy Shortcut/Copy Link Location]" in a context menu, and clicking
>> a button that says "Copy this Link". If anything, the former is more
>> explicit, since a button may do almost anything; what the text of a button
>> says is merely advisory, and in general untrustworthy.
> The context menu gets the value from the "href" of the anchor which is
> also what gets copied and pasted to other documents.  If we want to save
> the user from exposing this then we want to make the anchor's href point
> somewhere bland and generally inert.

I disagree that it needs to be "inert", but that's a separate issue.
We agree that it may need to be different from the URL that is followed.

> Clicking on a "Copy this Link" allows the page's code to bring up some
> sort of edit box (like Google maps) that contains an authority designating
> capability.

OK, but that doesn't require use of a button. It's fairly straightforward
to implement a link in which the page obtained by following it normally,
is different to the page obtained by copying the URL using
"Copy Shortcut/Link Location" and then opening that URL in another
window, tab, or browser. For example:

«a href="urlToCopy"
   onclick="javascript:window.location.href='urlToFollow'; return false;"»

(Let's refer to this as the "onclick trick". I've checked that it actually
works on FF 3.0.8 and IE 7.0.6001.18000. It does not work if JavaScript
is disabled, but see [*] below. Mind the injection hazards. Angle brackets
replaced by chevrons to help this post dodge overactive spam/phishing

This is all implementation details, though. Semantics is more important.
Let's first agree (or failing that, agree to disagree) on what the
semantics should be.

>> Besides, clicking a button in page content *obviously* shouldn't be able
>> to affect the clipboard.
> Ack, web pages, as far as I know, can't put things on the clipboard.
> This is just about exposing the "right" thing to the web browser so it
> can be copied by the user.
>> More generally, I'm confused by the motivation for trying to duplicate
>> standard browser features (history, the back button, link copying, etc.)
>> in page content. *If* the standard feature doesn't do what is expected,
>> then that needs to be fixed; adding a similar feature to the page that
>> does something subtly different is a step in the wrong direction for
>> real usability.
> Does it make any more sense now?

If I understand correctly, the suggestion to use a button was because
you didn't know that it is possible to have an "a href" link with a
distinct url-to-follow and url-to-copy, right? Was there another reason?

[*] To enable links to work when JavaScript is disabled, use
    something like (also tested on FF 3.0.8 and IE 7.0.6001.18000):

TODO: run wording past HCI expert.
JavaScript is disabled. If you copy a link using "Copy Link Location"
or "Copy Shortcut", it may grant more authority than you expect.
«noscript» «a href="urlToFollow"»link«/a» «/noscript»
  '«a href="urlToCopy" '+
     'onclick="javascript:window.location.href=\'urlToFollow\'; '+
                         'return false;"»link«/a»');

David-Sarah Hopwood ⚥

More information about the cap-talk mailing list