[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.


More information about the whatwg mailing list