Re: No tabbed browsing in HTML 5?

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.

You said that site authors rely on a new window being opened.  I ask how 
this manifests itself.  That is, how does the site malfunction if a tab 
is opened instead?

>> 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.

You clearly misunderstood my point.  You claim that "all it takes to get 
back to the originating Tab/Window, is that one closes the Window". 
This claim assumes a certain window management behavior in terms of 
which windows get focus when others are closed, etc.  This is no 
different from assuming certain tab-management behavior from a UA, and 
one assumption is no more justified than the other.  You claim that 
making this assumption about windows is great, while it cannot be made 
about tabs.  I don't see why you draw this distinction, and I don't 
think it's a valid 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?

My point, again, is that tabs are not as different from windows as you 
seem to think they are.

> 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.

OK.  What does that have to do with windows vs tabs?

> Static relationship: With target=_blank, the author has very little 
> control over where the page opens. The UA preference (usually the 
> default) will win.

Right.  What is the problem with that?

> 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.

I'm not sure what you mean here, to be honest.  window.open() and 
target=_blank behave identically in Firefox, for example (and in fact, 
one is implemented in terms of the other).

> 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. 

OK.  So it's not about how the UI is presented but rather about 
communicating information about how the opener and target are related? 
That's a very different thing, and I agree that it would might be good 
to have targets or some other mechanism to specify such relationships.

> (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].)

Agreed.  Also, in the interactivity case it's sounding like 
showModalDialog or equivalent is what's really being sought after.  Or 
am I missing something?

> 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.

That's what _blank is for: not reusing the current context.   Again, I 
feel like I'm missing something...

>> 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. 

No, I'm not....

> 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.

You missed my point.  When the calendar closes, it should call 
window.opener.focus() if it wants to try to ensure that its opener 
window will be the one focused.

> The problem is what should happen 
> after you close that tab.

Yes, I understand that.

> 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"?

No, and I don't think there should be: that's a UA decision in my 
opinion.  I do think that in most cases it makes the most sense for a UA 
to do that, but I don't think we should be constraining UAs that feel 
that their constituencies particular needs require a different behavior.

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

Javascript links in what sense?

>>> 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.

We _are_ on the subject.  We're discussing what influence, if any, web 
pages should be able to exert on the UI of the user-agent, and what, if 
anything, the spec should have to say about it.  Current user-agent 
behavior is, of course, relevant here, as are the reasons behind that 
behavior.

> If I use target=_blank, then most browsers - 
> if not all - will open that link in a Tab

While currently true, and making some assumptions about user 
preferences, the fact is you shouldn't be assuming that.

> But if I am a clever javascripter, the I can work
> around this and open the link in a new Window.

Again, only in some UAs, and only with default settings.  It's trivial 
to configure Firefox to not allow this, for example (except for cases 
like showModalDialog).

> Where is my control as user?

In the preferences.

> And where is my control, as a 
> non-JavaScript author?

Where is your ability to size the resulting window as a non-JavaScript 
author?  In Firefox, by default, you get a new tab unless a size is 
specified.  That's the only way a JavaScript author can get a new window 
instead, last I checked.

I would fully support adding a declarative way of sizing the 
newly-opened window.

> Theoretically, we cannot guarantee that _self has the meaning of 
> "current window" in all possible browsers either.

It makes a lot more sense to specify this, actually.

> The spec talks about "browsing context". Most seems to think that this 
> means "window".

Really?  Most who?

> 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?

Not as far as the spec is concerned.  A "browsing context" in the spec 
is just something that corresponds to a Window object.

> Of course, it says "context" in order to cover UAs more broadly, such as 
> screen readers.

No, it says "context" because it's really a pretty UI-independent 
concept that has to do with atomicity of navigation, scripting behavior, 
etc.  Its presentation in the UI doesn't matter for defining most (if 
not all) of its behavior.

> 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.

I'd be fine with that, if we really can figure out what it represents.

Of course the problem is it represents different things to different 
people, so you might run into some trouble here.

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

For me, a new window represents a new task whereas a new tab represents 
a part of the existing task that for some reason requires a separate 
Window object.

> That might be. But then we are here to specify the specification, so 
> that we know what is poor behaviour.

We're not interested in specifying "good" or "poor" UI behavior, though: 
that's in the eyes of the beholder.  If the UI of your user-agent is not 
fulfilling your needs, the right course of action is to either seek a UI 
that better fits them or try to convince your user-agent's authors to 
change the behavior of their UI.

Fundamentally, it's better to have many UAs with many different UIs all 
catering to different groups of users than it is to require homogeneity 
of UI, presumably targeted at some sort of majority group of users, at 
the expense of all other users.

> iCab defaults to treating javascript and target=_blank the same way.

OK.

> One could say that this gives its users more control.

Indeed. ;)

> 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?

Right now it has to guess.  A simple heuristic is that if you have not 
switched tabs since opening the new tab, then go back to the originating 
context.

But again, I would be fine with a way for the originating context to 
hint to the UA what the desired behavior is here.  I do think it should 
be a hint, for the UA's benefit, so that the UA can try to provide the 
best experience it can to the user.

> And/Or, how can the UA know 
> when it should not obey the user preference of opening a _blank in a new 
> Tab?

That's a quite different question, and the answer is "always obey the 
user preferences", in my opinion.

-Boris

Received on Friday, 19 September 2008 12:53:13 UTC