Bug 14961 - extend frame target types to support _tab
Summary: extend frame target types to support _tab
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: Frames (show other bugs)
Version: 523.x (Safari 3)
Hardware: All OS X 10.4
: P2 Normal
Assignee: Nobody
URL: http://www.w3.org/TR/REC-html40/types...
Keywords:
Depends on:
Blocks:
 
Reported: 2007-08-13 19:52 PDT by James Cox
Modified: 2010-09-20 02:09 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description James Cox 2007-08-13 19:52:37 PDT
opening a link which targets _new causes the current window to lose focus. This is undesirable behavior as often the user may just be opening the link to preload the content for review later. It'd be nice therefore for responsible web developers to target _tab, which would default to _new when tabs are disabled.

given most browsers now support tabs, this makes sense to work into any HTML/XHTML specs due to be released, but till then, and given the prevalence of web2.0 apps and so on making real use of _new, support for _tab would be desirable.

a further option for browsers who support this could be a preference which forces all _new links to open in tabs.
Comment 1 David Kilzer (:ddkilzer) 2007-08-13 23:21:32 PDT
Does HTML5 mention this?

Comment 2 Ian 'Hixie' Hickson 2007-08-13 23:30:12 PDT
The "_new" value is actually "_blank", not "_new".

The HTML5 spec doesn't define "_tab", in fact it actually makes the existing value "_blank" non-conforming. Authors shouldn't use it. However, it is expected that tabbed browsers would take the existing "_blank" value and use that to target new tabs.

I recommend against supporting "_tab".
Comment 3 Adam Barth 2010-09-20 02:09:16 PDT
Ok.  No _tab then.