[whatwg] Suggestion: Implementation of Tabbed Forms

[Ian Hickson]

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 
class="violins">).

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>
   <section>
   </section>

...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.   `._.-(,_..'--(,_..'`-.;.'