- From: Maciej Stachowiak <mjs@apple.com>
- Date: Fri, 4 May 2007 01:32:59 -0700
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
Received on Friday, 4 May 2007 01:32:59 UTC