[whatwg] Target Attribute Values
Maciej Stachowiak
mjs at apple.com
Fri May 4 01:32:59 PDT 2007
On Apr 29, 2007, at 9:21 AM, Sander Tekelenburg wrote:
> At 00:36 +1200 UTC, on 2007-04-30, Matthew Paul Thomas wrote:
>
> [...]
>
>> If _blank is allowed, I would prefer the specification to discourage
>> authors from using _blank when another solution is practical (e.g.
>> using a <details> element in the original page)
>
> Yes, having the spec list common (ab)use cases and pointing authors
> to better
> options for those would be good.
>
>> , and encourage UAs to
>> indicate when a link will open in a different top-level browsing
>> context (e.g. by double-underlining instead of single-underlining).
>
> FWIW, iCab[*] indicateds such cases by a change of cursor upon
> hovering over
> the link. (You get the same cursor when you Cmd-click or Cmd-Shift-
> click the
> link, to load it in a new window on purpose.) This way you can keep
> such UA
> functionaility in the chrome -- no need to mess with the content's
> presentation itself.
Safari indicates in the status bar hover feedback when a link will
open in a new window, new frame or new tab, or if it will download,
if we can tell based on target setting and the user's currently
depressed modifier keys. Unfortunately when the link action is JS we
can only say that it will run a script. So it's actually better
usability if the site can use target="_blank" compared to using
window.open(), at least in Safari. We also let you override opening
in a new window via target to open in a new tab instead using the Cmd
key, but we don't have a set of modifiers to open in the current tab
in the current window. I suppose that might be useful in some cases.
We also don't support that for window.open(), though it might be
useful in some cases.
Regards,
Maciej
More information about the whatwg
mailing list