Re: No tabbed browsing in HTML 5?

Lachlan Hunt 2008-09-18 22.33:

> hallvord@opera.com wrote:
>> I haven't checked the spec but this implementation for _blank isn't 
>> going to be compatible with the web. I know because we (Opera) tried 
>> to not set window.opener for a new window created by a _blank link - 
>> it broke Google Docs' document manager screen interaction with the 
>> opened documents.
> 
> I tested this in Firefox, IE and Safari, and they also set 
> window.opener, so this behaviour will need to be specced.  I did check 
> the spec, but I find anywhere that covered this issue appropriately.


The way the draft currently is written, the "_blank" is covered in 
the 5th list item of Section 4.1.6 which says: "Otherwise, a new 
browsing context is being requested, and what happens depends on 
the user agent's configuration and/or abilities: [etc]" [1]

I have not tested Google Docs for this yet, but the problems with 
my Internet Banking that I mentioned was in the current iCab.

Is it possible for users to set up [without any third-party 
plug-ins] the "big four" Web browsers in a way that makes them 
incompatible with e.g. Google Docs?

>> If this is in the spec we had better drop it - perhaps a brand new 
>> value like <a target="_standalone" href="..."> could do the job but
>> we can't change _blank.


It seems to me that such a "_standalone" could be defined as a 
"_yes-I-really-mean-_blank".

> We don't need a new value for this because no-one has demonstrated that 
> there is a real problem here that needs solving.  Until that happens, 
> coming up with potential solutions really isn't worthwhile.

It sounds from what you and Hallvord said above that you think 
_blank really is (and should be) what Justin called "_fork" or 
"_continuation". [2]

Another place where this is relevant is @longdesc. I believe all 
UAs with enabled support for @longdesc will open the @longdesc 
link in a new Window/browser context above the current one - and 
not in a Tab. And when you close that window, you're back to the 
originating window. This is an important effect of using @longdesc.

Note that in the @longdesc case, it doesn't matter - as much as I 
can see - whether there is a formal "link" between the windows. 
It is enough that the @longdesc URI opened in a new Window. Close 
it, and you're back.

You and Hallvord are mostly occupied with the "link" between the 
originating context and the context created by the _blank link. 
But it is also important to have an eye for the usability aspect. 
It is not enough that my browser, which opened the calendar picker 
in a Tab instad of a Window, only inserts the correct date into 
the originating page. It should also bring me, the user, back to 
the originating page, with 100% certainity. Or else, it should not 
open a Tab at all, but instead open a Window. And that is whey I 
care about whether the page actuall opens in a Tab or in a Window.

What is the relationship beween browsing context and Tab?

[1] http://www.w3.org/TR/html5/web-browsers.html#the-rules
[2] http://lists.w3.org/Archives/Public/public-html/2008Sep/0376.html
-- 
leif halvard silli

Received on Thursday, 18 September 2008 22:20:22 UTC