Proposal: target=”_tab”

[BorekB]

Summary: Introduce a new browsing context name “_tab” which would advise a browser to open the link in a new tab. Sample usage: <a href=”...” target=”_tab”>. Similar method should be available in JavaScript too.

Motivation: Opening links in new windows versus new tabs is very different from the user perspective. Each behavior has its common use case – for instance, tabs are useful for content that you want to read later while new windows can be useful for help pop-ups etc. However, there is only one way to specify that the link should open in a new browsing context: target=”_blank” (target=”_tab” is missing). The same applies to JavaScript where we have window.open() but nothing like window.openToTab(). This is an obvious mismatch.

Common answer is that the browsing context is a user preference, which unfortunately doesn’t work very well in practice. Let me demonstrate; imagine a large form with help icons next to each label or input field – I as a user know that I would like a small pop-up (possibly without the menu bar and the toolbar) and that is my preference for _this type_ of links. For links that point to external web pages, I might want to open them in new windows. And for Google Reader, I might prefer reading the items in new tabs. As you can see, browsing context is my user preference but is site-specific or even link-specific and therefore almost impossible to implement at the browser level. For example, if you want the ‘v’ keyboard shortcut to behave naturally in Google Reader in Firefox, i.e. to open links in new tabs, you have to modify Firefox’s settings to run in a “single window, multiple tabs” mode. However, this will cause confusion when some other website genuinely needs to open a new window (to display help, for instance).

As the example above shows, leaving the browsing context up to the user preferences is a nice theory but in practice, web developers should have a way to suggest what should happen – although I agree that it should be generally override-able by user settings or by an explicit action (like middle-clicking the link). The demand for _tab context amongst web developers is clear when you do a Google search for _tab: http://www.google.com/search?q=_tab.

Implementation: should be pretty straightforward as almost all browsers support tabs these days. Those that don’t can fall back to opening new window which is the default behavior anyway.

Compatibility: The change is backwards compatible.

Related proposals: There was a proposal by mpt about target=”_reference” that you can find here: http://lists.whatwg.org/pipermail/whatw ... 14564.html. I feel that, although it might be a superset of target=”_tab”, this _tab should still be considered. Firstly, implementing _tab would be much much easier than implementing _reference (I would even call implementing _tab into current browsers trivial). Secondly, _tab is semantically stronger than _reference and is therefore more straightforward to use for web developers.

What do you think?

Regards,
Borek

[zcorpan]

How about making target=_blank and window.open() without specified size open in a new tab while window.open() with specified size opens in a window? Would that work?

[BorekB]

How about making target=_blank and window.open() without specified size open in a new tab while window.open() with specified size opens in a window? Would that work?

I believe that there are genuine use cases for both new windows and tabs even in "normal window mode" (i.e. no explicit width/height) so no, I don't think it's a good idea to change the behaviour of _blank to open in new tabs.

I think it would be beneficial to have a concept of distinct _blank and _tab in both HTML and JavaScript.

[zcorpan]

I believe that there are genuine use cases for both new windows and tabs even in "normal window mode" (i.e. no explicit width/height)

Could you elaborate on what these use cases are?

In the first post you said

Each behavior has its common use case – for instance, tabs are useful for content that you want to read later while new windows can be useful for help pop-ups etc.

But the author can't possibly know whether the user wants to read something now or later, and help popups generally have specified width/height.

[BorekB]

I believe that there are genuine use cases for both new windows and tabs even in "normal window mode" (i.e. no explicit width/height)

Could you elaborate on what these use cases are?

The point is that currently web developers don't have any way to instruct the browser to open a link in a new tab and as I tried to explain above, user preference in the browser settings does not always work (because my preference might be different for different web pages or even for different links on the same page).

One concrete example where this causes problems to me as a user is Google Reader (as mentioned in the first post). In a tabbed browser, one possible usage pattern in GReader is to quickly browse through all the new posts and open the ones of your interest into new tabs that you will read later. GReader supports this scenario with a 'v' shortcut which opens the link in a new window. Because this is unnatural in a tabbed browser, it is suggested that you modify your browser's behaviour to open _blank-type links to new tabs instead.

I don't like this as a user - I'm changing my global preference just to make one application more pleasant to work with (not to mention that many users will have hard times finding this setting in the browser configuration). If there was something like target="_tab", GReader could implement this behaviour seamlessly. Or it could provide an option in GReader settings which would basically mean that I could set the user preference for just this one website -- and I would love to be able to do that.

I hope that this explains the benefits of adding target="_tab" a little better.

By the way, is this forum a good place to propose new features? Is this read by the same people as in the mailing list? (I really don't like mailing lists so I posted here.)

[zcorpan]

The point is that currently web developers don't have any way to instruct the browser to open a link in a new tab and as I tried to explain above, user preference in the browser settings does not always work (because my preference might be different for different web pages or even for different links on the same page).

So how's the author to know what the user's preference is? Can't you as a user instead decide how you want to open a link when you follow a link, like, say, click if you want to open in the same tab and middle-click or ctrl-click to open in a new tab?

One concrete example where this causes problems to me as a user is Google Reader (as mentioned in the first post). In a tabbed browser, one possible usage pattern in GReader is to quickly browse through all the new posts and open the ones of your interest into new tabs that you will read later. GReader supports this scenario with a 'v' shortcut which opens the link in a new window. Because this is unnatural in a tabbed browser, it is suggested that you modify your browser's behaviour to open _blank-type links to new tabs instead.

Well, Opera opens _blank links in tabs by default. Browsers with tabs generally also have a way for the user to open normal links in tabs so there's really no need for GReader to implement this "shortcut".

I don't like this as a user - I'm changing my global preference just to make one application more pleasant to work with (not to mention that many users will have hard times finding this setting in the browser configuration). If there was something like target="_tab", GReader could implement this behaviour seamlessly. Or it could provide an option in GReader settings which would basically mean that I could set the user preference for just this one website -- and I would love to be able to do that.

Isn't it better to have site-specific prefs in the browser than to give authors the power to decide for you whether you want windows or tabs?

I hope that this explains the benefits of adding target="_tab" a little better.

It explains the problem a bit better but I'm not convinced that _tab is a good solution to the problem. By the way, you haven't explained what the use-cases are for authors being able to open both tabs and windows with unspecified size.

By the way, is this forum a good place to propose new features?

Yes, but it is not a guarantee that the editors will respond to it. If you want that you should post to whatwg@whatwg.org. Anyone can of course forward discussions here to the list, and I've done so a few times in the past.

Is this read by the same people as in the mailing list?

Some people read only the mailing list, some read only the forum, some read both, and others read neither.

[BorekB]

The point is that currently web developers don't have any way to instruct the browser to open a link in a new tab and as I tried to explain above, user preference in the browser settings does not always work (because my preference might be different for different web pages or even for different links on the same page).

So how's the author to know what the user's preference is? Can't you as a user instead decide how you want to open a link when you follow a link, like, say, click if you want to open in the same tab and middle-click or ctrl-click to open in a new tab?

The author doesn't know what the user preference is but that's fine -- that's why we have "settings" page in almost all web applications.

One concrete example where this causes problems to me as a user is Google Reader (as mentioned in the first post). In a tabbed browser, one possible usage pattern in GReader is to quickly browse through all the new posts and open the ones of your interest into new tabs that you will read later. GReader supports this scenario with a 'v' shortcut which opens the link in a new window. Because this is unnatural in a tabbed browser, it is suggested that you modify your browser's behaviour to open _blank-type links to new tabs instead.

Well, Opera opens _blank links in tabs by default. Browsers with tabs generally also have a way for the user to open normal links in tabs so there's really no need for GReader to implement this "shortcut".

I'm not sure that opening all _blank links into new tabs is a good idea (running Firefox in this mode certainly causes some confusion on some websites). Here we come to the main argument again -- I think that even in the world of tabbed browsers, it is still good from time to time to open a link in a new window.

I don't like this as a user - I'm changing my global preference just to make one application more pleasant to work with (not to mention that many users will have hard times finding this setting in the browser configuration). If there was something like target="_tab", GReader could implement this behaviour seamlessly. Or it could provide an option in GReader settings which would basically mean that I could set the user preference for just this one website -- and I would love to be able to do that.

Isn't it better to have site-specific prefs in the browser than to give authors the power to decide for you whether you want windows or tabs?

I think it would be substantially easier to give GReader's team a way to open a link in a new tab for me than to wait for all browsers to implement some clever settings page that would allow me to say "when I press 'v' on GReader's page, I want it to open in a new tab" (yes, my user preference is that complicated; I don't actually want to open all links in GReader in new tabs -- that demonstrates why, in my opinion, is hard or even impossible to implement this on a browser level).

BTW, I don't agree with your formulation "give authors the power to decide for you whether you want windows or tabs" -- having target="_tab" would just mean that you could move user preference from the browser level to the web app level. We already have this in window.open where the web developer can specify what UI elements of the browser will be visible -- that is much more "intrusive" but seems to be widely accepted as useful.

I hope that this explains the benefits of adding target="_tab" a little better.

It explains the problem a bit better but I'm not convinced that _tab is a good solution to the problem. By the way, you haven't explained what the use-cases are for authors being able to open both tabs and windows with unspecified size.

As an example, if there was a print preview functionality in GReader, it might be reasonable to open this in a new window (that's what most websites with similar functionality do). At the same time, opening blog posts might make more sense with new tabs.

Generally, the reason I would like to see target="_tab" in the spec is that it would be a really simple thing to add -- and it would be pretty easy to implement in the browsers too. And it would make sense to web developers. And there is a demand for it. Quite honestly, I don't see many reasons why not to include it -- you might be right that browsers should offer better configuration options and all that theory about browser/web app level is interesting but why can't we have both? target="_tab" in the specs and the possibility to override those settings locally would make sense to me.

Borek

[zcorpan]

As an example, if there was a print preview functionality in GReader, it might be reasonable to open this in a new window (that's what most websites with similar functionality do). At the same time, opening blog posts might make more sense with new tabs.

I guess that's fair enough.

http://lists.whatwg.org/pipermail/whatw ... 15006.html

[BorekB]

As an example, if there was a print preview functionality in GReader, it might be reasonable to open this in a new window (that's what most websites with similar functionality do). At the same time, opening blog posts might make more sense with new tabs.

I guess that's fair enough.

http://lists.whatwg.org/pipermail/whatw ... 15006.html

Wow, what a nice and concise summary :) Thank you, Simon.

[Pacoup]

Why isn't anyone considering deprecating target all together as in XHTML. Just leave the choice to the user, that way there is no confusion as to what to expect from a website's functionality.

There is the argument that some people are used to having pages open in a new browser window or tab without them having to act upon it, but I don't see how anyone would prefer an ambiguous web.

Yet again, don't you go panick about compatibility. This is something every browser, even IE 6, knows how to deal with (right click, open in a new window). And besides, even if someone writes it in it's code, it's going to be interpreted anyway because of HTML 4 compatibility. That doesn't mean we can't make it deprecated for the good of the web's future.

Edit: Yes, I know some web functionality makes sense when opening a new window. Maybe we should try avoiding that interface design functionality, there are ways.

[SneakyWho_am_i]

I used to have this paranoid obsession with the target attribute. I felt I had to open ALL offsite links in new windows so that my users wouldn't navigate away from my site.

Say no to drugs.

It's not actually useful at all for that purpose, and it's just really, really highly annoying. I am a tabbed browser (huh?!) and I find it very, very annoying now when on one of my ten example.com tabs, I click a link only to find it opens a NEW tab to example.org. It's greedy, how many tabs do you think you need open in my window anyway?

Web designers, please don't open things in new windows unless you really, REALLY HAVE to. It's annoying.

I wasn't aware actually that Firefox had a preference for this. Nice. There are always userscripts, too.

Firefox, like Opera, opens target="_blank" into a new tab, not a new Window. (A blank what?) and that's not too bad. A whole extra window means drawing a whole lot of extra chrome, it's super wasteful.

HOWEVER after bashing the target attribute so much and declaring my hatred for certain abused values, I am not against the attribute per se.
It has one very obvious use case:
IFRAMES.
We're allowed to create static windows, we should be able to control navigation in them from their parent windows. The target attribute is and always will be perfect for this; if you deprecate target make sure you get rid of iframe first.

I will love you forever if you get rid of the _xxxx values though

[PMB9]

What about CSS3 Hyperlink Presentation Module?

[Pacoup]

[quote="SneakyWho_am_i"]Web designers, please don't open things in new windows unless you really, REALLY HAVE to. It's annoying. [quote]

You are right. I think this target thing should be restricted to use by Javascript. For example, you might want users to click a little plus button for more information on a certain shopping item but have the information pop-up in a little window, instead of navigating away from say, a form to buy something.

Maybe this is a behavior that should be added in HTML, since shopping is an integral part of the Web now.