[whatwg] Suggestion: Implementation of Tabbed Forms

Ian Hickson ian at hixie.ch
Sun Aug 29 13:20:13 PDT 2004

On Thu, 26 Aug 2004, Matthew Raymond wrote:
> Ian Hickson wrote:
> > On Tue, 17 Aug 2004, Matthew Raymond wrote:
> > 
> > > > Tabs are not mutually exclusive, they are just an unordered group 
> > > > of related sections that are usually shown such that only one is 
> > > > visible at any one time.
> > > 
> > > Why do we need semantic mutual exclusion at all? It seems to be some 
> > > kind of semantic justification of the presentational value of having 
> > > a group of sections where only one can display at a time. On a 
> > > practical level, just how useful is non-presentational mutual 
> > > exclusion in markup?
> > 
> > I've run into several cases where I've needed this. For example, 
> > writing a game application with four screens, all implemented in the 
> > same HTML file: the login screen, the game "lobby" screen, the actual 
> > game screen, and the results screen. Only one of those is to be 
> > displayed at any one time.
>    That's _presentational_ mutual exclusion. I fail to see how that 
> amounts to _semantic_ mutual exclusion.

I disagree. I think it is very much a semantic mutual exclusion. It makes 
no sense to be showing the game screen when the user hasn't yet logged in, 
for instance.

> > > > Anyway, the spec currently has a separate section for tabs, which 
> > > > says that the tabbed version of the above would be:
> > > > 
> > > >    <tabbox>
> > > >      <section>
> > > >        <h1>Section 1</h1>
> > > >      </section>
> > > >      <section>
> > > >        <h1>Section 2</h1>
> > > >      </section>
> > > >    </tabbox>
> > > 
> > > Quick note: I have to say, I don't like the header tags being 
> > > treated as tag labels. There are cases where we've done something 
> > > similar, but only when absolutely necessary. I'm a little concerned 
> > > that we're getting too clever with our markup rather than having a 
> > > straight-forward standard.
> > 
> > What's not straight-forward about this?
>    Well, for starters, exactly how would someone unfamiliar with HTML5 
> know that the <h1> element contains the name of the tab for that 
> section? Why wouldn't the user just believe that the name is simply a 
> heading within the section?

How would someone unfamiliar with HTML4 know that <var> is for marking up 
variables? How would someone not familiar with HTML5 know that <section> 
referred to a document section, and not a band section? (<section 

The name _is_ simply a heading within the section. And the heading's 
section title is the tab's title. I don't understand why that is a 
problem? I think it's a bit semantically dubious to have to give the 
section titles twice.

> I would object far less if it were this:
> <sectionlabel for="section1"><h1>Section 1</h1></sectionlabel>
> <section id="section1">
>   Content.
> </section>

But that's really ugly.

   <h1>Section 1</h1>

...would not be as ugly, but even then, you've lost most of the 
possibilities of doing magic with <section> (as described in the spec, 
like using CSS selectors to style the <h1>) and it makes defining <h1>'s 
semanics a lot harder.

> I'm strongly opposed to the use of <h1> as a tab label. [...] The reason 
> for my objection is semantic overloading. The <h1> element would mean 
> different things _semantically_ depending on the situation.

Why is that a problem?

What would <h1> mean there if it wasn't "section header"?

>    What I don't understand about the example is that there seems to be 
> an implied <iframe>, since there is no |target| specified.

No <iframe>; the links just act like normal links and replace the current 
page if they have no target="" attribute.

(This is similar to how the www.whatwg.org pages have a tab strip at the 
top with links to several pages.)

> > > It could also be used with simple Javascript events, so vendors 
> > > could keep tabstrip even if they decide to pass on <section>.
> > 
> > Not sure what you mean here.
>    Right now, people can create tabs using DHTML. If webmasters had a 
> tabstrip like the one that exists in VB, all they would have to do is 
> write some Javascript that would run when a tab is clicked that would 
> change the ZOrder of a block so that it is on top. Without the tabstrip, 
> the webmasters have to implement the entire tabstrip widget, and for 
> DHTML, that means you run into styling problems.

So basically you are saying "<tabstrip> allows people who have JS enabled 
to write JS that hooks into the <tabstrip> element to fake a tabstrip?" If 
so, then I don't understand your concern. If JS is enabled, they can 
synthesise all the elements they want from the markup, just like a native 
implementation would.

>    A section, in most people's minds, would be a set of paragraphs in a 
> document, not a (presentationally) mutually exclusive block.

That's exactly the point. It needn't be rendered as a tab, that's just the 
preferred default rendering for visual UAs. It could, in fact, be rendered 
just as the sections one after the other (as it would in most legacy UAs).

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

More information about the whatwg mailing list