W3C home > Mailing lists > Public > public-html@w3.org > September 2008

RE: No tabbed browsing in HTML 5?

From: Justin James <j_james@mindspring.com>
Date: Thu, 18 Sep 2008 16:15:50 -0400
To: "'Leif Halvard Silli'" <lhs@malform.no>
Cc: "'Justin Anthony Knapp'" <justinkoavf@gmail.com>, <john@netpurgatory.com>, "'N-at-Work'" <info@n-at-work.net>, <public-html@w3.org>
Message-ID: <007201c919cb$5806b5a0$081420e0$@com>

Leif -

My concern here is that I don't think that we should be delving into the
realm of defining UA's UI behavior, and the _tab proposal requires exactly
that. What I *do* like, however, is the idea that we may need a way to
create another instance of the same browsing context, forking the process,
as it were. Something like "_fork" or "_continuation" would be sufficient.

I also feel that in scenarios where the Web developer/designer requires
precise control over how a new window is created, the corresponding DOM
functions are best suited for this task.


> -----Original Message-----
> From: Leif Halvard Silli [mailto:lhs@malform.no]
> Sent: Thursday, September 18, 2008 3:37 PM
> To: Justin James
> Cc: 'Justin Anthony Knapp'; john@netpurgatory.com; 'N-at-Work'; public-
> html@w3.org
> Subject: Re: No tabbed browsing in HTML 5?
> Nathalie, perhaps you could explain how you envisionaged the
> effect of _tab? I'll offer my perspective here.
> Justin, Lynx could also have had a form of Tabs support. In an UA
> without Tabs, it should probably just open a new Window, though it
> possibly could create a some kind of grouping as well (see below).
> With "_blank" one creates a new browsing context, where the new
> context has no "link" with the originating context. This, in fact,
> seems to me to be exactly what we would expect from a "_tab" also.
> Except that for "_tab" one would expect that the link would open
> in a Tab and not in a Window. Thus, a tab is forming a context
> anyhow, since the Tabs of a Window form a kind of group.
> Even Lynx and other UAs without Tab support in a GUI sense, could
> develope a way to group several pages into one "usage context".
> And until they support something like that, the "_tab" would have
> the same effect as "_blank".
> One possible benefit of defining _tab could be that we could also
>   define a cleaner _blank, where _blank would *always* open a new
> Window even if the browser does have support for Tabs.
> The thing with _blank is that many authors apparently expect that
> it opens in a new Window, and rely on that behaviour. By that
> expectation, they kind of expect the *opposite* of what the draft
> says that _blank does. (Draft says that _blank creates a new
> context, thus - that there is no "link" between them. )
> 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. 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.
> 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. 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!
> The question still is: When is target:_tab useful? A possible
> answer could be: On start pages of many kinds. Any page where the
> author expects the users to read the links of the page in
> parallell tabs. Also, if you operate a page without a mouse, then
> it might be convenient if it is simple to open the links in Tabs.
> 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.
> Justin James 2008-09-18 18.44:
> > The behavior of _blank, _self, etc. is only defined in HTML as
> referring to
> > browsing contexts. However a particular UA chooses to implement that
> is up
> > to them. _blank, _self, etc. have meaning, even within a browser like
> Lynx.
> > _tab does not. It just so happens that the most popular use case for
> _blank
> > is to open a new tab/window, but that does not mean that this is
> within the
> > scope of the HTML specification.
> >
> > J.Ja
> >
> > From: public-html-request@w3.org [mailto:public-html-request@w3.org]
> On
> > Behalf Of Justin Anthony Knapp
> > Sent: Thursday, September 18, 2008 11:43 AM
> > To: john@netpurgatory.com
> > Cc: N-at-Work; public-html@w3.org
> > Subject: Re: No tabbed browsing in HTML 5?
> >
> > It seems that most browsers have an option to "open in new window" or
> "open
> > in new tab" and that is probably best handled as a end-user issue. I
> > understand your rationale, though.
> >
> > And, as pointed out, someone will find a work-around: some script
> > bookmarklet or Firefox extension that opens the _tabs in _windows and
> > vice-versa. The notion of declaring parts of the browser is a bit
> silly to
> > me. Why not _new or _newdocument or somesuch to signify that this
> link is
> > probably not supposed to replace this document's display, but can be
> > displayed however the end user and the permissions of his program
> allow?
> >
> > -JAK
> > On Thu, Sep 18, 2008 at 11:33, John C. Vernaleo
> <john@netpurgatory.com>
> > wrote:
> >
> > On Thu, 18 Sep 2008, N-at-Work wrote:
> > So what do you think about ?_tab? as an additional keyword.
> >
> > http://www.w3.org/html/wg/html5/#target6
> >
> > I for one really don't see how that is a legit thing for authors to
> decide.
> >  Seems completely a user agent decision to me.  (Not to mention
> terminal
> > based browsers like lynx and screen readers that would have no
> reasonable
> > way to support it.)
> >
> > I can barely remember how I used the web before tabs, but I still
> wouldn't
> > want to give control of that to the html author (and as an author I
> wouldn't
> > want that control either).  If it were added to the spec, then
> browsers
> > would have to come up with a way to ignore them which seems like it
> means
> > extra work has to get done by everyone
> --
> leif halvard silli
Received on Thursday, 18 September 2008 20:17:03 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:38 UTC