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
