Re: No tabbed browsing in HTML 5?

Boris Zbarsky 2008-09-19 02.23:

> 
> Leif Halvard Silli wrote:
>> The thing with _blank is that many authors apparently expect that it 
>> opens in a new Window, and rely on that behaviour.
> 
> Other than authors specifying a size, how so, exactly?

I don't follow.

>> When a new Window opens above the current Tab or Window, then all it 
>> takes to get back to the originating Tab/Window, is that one closes 
>> the Window.
> 
> That may or may not be true depending on the behavior of the user's 
> window manager.

Think about @longdesc again: If you do not get back to the <img> 
after you have closed the "context" in which the longdesc URI was 
opened, then you cannot blame the window manager.

>> But if the page opened in a new Tab instead of a in a new Window, the 
>> outcome of closing the Tab is uncertain. Quite likely you land in 
>> another Tab than the originating one.
> 
> That's up to the UA (instead of the window manager), and is a usability 
> decision on the UA's part.  For what it's worth, some UAs have exactly 
> the behavior you seem to expect here.  But that's up to the UA (or more 
> precisely the user, but in practice users end up using the UA defaults).

These are valid points. But where are you heading with them?

I think there is one case were opening a link above abother is 
really important, and that is when there is meant to be some 
direct interaction between the originating page and the new page.

Static relationship: With target=_blank, the author has very 
little control over where the page opens. The UA preference 
(usually the default) will win. Hence target=_blank will nowadays 
typically open in a new tab, because that is the default of most 
browsers.

Interactive relationshipp: But if there is some interaction 
involved - either because it is a longdesc URI or because there is 
javascript involved, then the new page typically opens *above* the 
current window.

Yes, a such interactive window could theoretically open in a tab 
as well. And that is one reason why I am interested in the 
relatioinship between tab and browsing context.

The purpose of _tab, if any, would be to say that there *isn't* 
any interactivity relationship between two pages. So, _tab really 
is the _standalone that Hallvord spoke about. (Because, I really 
am completely unable to see why there can be any legitimate reason 
to open a link above another window *when and if* the browser 
supports tags, unless there is som interactivity relationship [or 
unless the user spesificly prefers it that way, of course].)

And I think there are legitiamte reasons to sometime help users to 
open a a link in a new tab/new horisontal context instead of 
accidentally reusing the current context.

>> Example: An Internet Banking service I use has a calendar in the form 
>> of a date selector, which opens in a new window. Upon picking a date, 
>> the window closes and the author then expects that the user will be 
>> back in the Banking page again.
> 
> Then the author is making an unwarranted assumption, whether tabs are 
> involved or not.  If he wants to actually guarantee that this assumption 
> holds, he should be calling focus() on the window he wants to end up on 
> top.  Of course some UAs disable rearrangement of window z-index via 
> focus() calls too...

You here take for granted that the calendar is opened in a new 
window. How come? Can it not open in a new Tab? Then too it will 
have focus - at least from the user's point of view. The problem 
is what should happen after you close that tab. In fact, that is 
what interaction is about. Is there any place in the spec which - 
in a windows manager and UI neutral language says that the browser 
then should jump over the tabs in between and back to the 
origianting "context"?

> In the end, the author is just not in control here; fact of life.  And I 
> don't think he _should_ be in ultimate control.

If the author uses javascript links, then neither is the user. I 
suppose you disagree with such lack of control then?

>> But in fact, because the calendar opened in a new Tab, and because I 
>> might have opned a new parallell Tab side-by-side the Banking page 
>> before I chose the Calendar, I might land in that nearby Tab instead 
>> of the Banking page. Annoying!
> 
> Sounds like your UA has suboptimal behavior.  Report a bug to its creators?

Let's stick to the subject. If I use target=_blank, then most 
browsers - if not all - will open that link in a Tab, if the 
browser supports tabs and the user has not disabled them. So, in 
fact, in such cases _blank is like _tab.

But if I am a clever javascripter, the I can work
around this and open the link in a new Window. That is 
interesting. Where is my control as  user? And where is my 
control, as a non-JavaScript author?

>> The question still is: When is target:_tab useful?
> 
> "Never", for a user who never wants to see tabs.  That is, the author 
> should not be forcing his tab-vs-window preferences on the user, period. 
>  If the user wants to have target="_blank" create a tiled UI as seen in 
> some MDI apps, and not either windows or tabs, that should be the user's 
> decision.  And the spec should not forbid this: innovation in user 
> interface design is a good thing.

Theoretically, we cannot guarantee that _self has the meaning of 
"current window" in all possible browsers either. But fortuntaly 
target="" cannot prevent you from opening the URL anyhow ...

The spec talks about "browsing context". Most seems to think that 
this means "window". The spec does not mention tabs in that 
context at all. Which to me seems like a shortcoming. Does it have 
any context implications if a link gets opened in a tab?

Of course, it says "context" in order to cover UAs more broadly, 
such as screen readers. However, *that* is an afterthought. And we 
should also be able "afterthink" about what a tab reprents, and 
define what this in a window manager and UI neutral language.

For myself, a new window represents a vertical relationship, while 
a new tab represents a horisontal relationship.

>> Even so, I am still not certain that _tab would be much used though. 
>> But it does seem to me to be logical to have one way to open a page in 
>> a Tab and another way to open a page in a new Window. The fact that we 
>> do not have a way to separate them today has at least created problems 
>> for me in my Internet Banking surfing.
> 
> Again, it sounds like what's really created problems for you is poor 
> behavior on the part of your UA.

That might be. But then we are here to specify the specification, 
so that we know what is poor behaviour. The poor app you talk 
about is the clever browser iCab. (And you failed to take any note 
of the fact that I said that it _defaults_ to behave as I 
described - allthough I am not certain that iCab currently can be 
set up to behae as Firefox does.) iCab defaults to treating 
javascript and target=_blank the same way. One could say that this 
gives its users more control. The question is: How can the UA know 
when closing a tab *should* take you back to the originating 
context and when it should not? And/Or, how can the UA know when 
it should not obey the user preference of opening a _blank in a 
new Tab?
-- 
leif halvard silli

Received on Friday, 19 September 2008 02:26:04 UTC