[whatwg] Suggestion: Implementation of Tabbed Forms

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.

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

    I'm strongly opposed to the use of <h1> as a tab label. I would 
object far less if it were this:

<sectionlabel for="section1"><h1>Section 1</h1></sectionlabel>
<section id="section1">
   Content.
</section>

    For WA1-compliant browsers, <sectionlabel> (or any of a million 
names for the element that would be far better than this one) would 
ignore heading elements such as <h1>.

    The reason for my objection is semantic overloading. The <h1> 
element would mean different things _semantically_ depending on the 
situation. This isn't really a problem with <menu> because it's already 
depreciated in HTML4, so the semantic value outside of being used as a 
menu is minimal.

>>>The name <tabbox> will probably be changed to <group>. See the spec 
>>>for better examples. (Graceful degradation as your example had is 
>>>possible too, since non-section elements in the tabbox are ignored.)
>>
>>   My <tabstrip> is actually more powerful, because it allows tabs to be used
>>separately from the sections concept. For instance, the <tabstrip> could be
>>used with frames:
>>
>><tabstrip>
>>  <tabs>
>>    <tab for="section1.htm" target="main">Section 1</tab>
>>    <tab for="section2.htm" target="main">Section 2</tab>
>>    <tab for="section3.htm" target="main">Section 3</tab>
>>  </tabs>
>></tabstrip>
> 
> This is also supported in the <tabbox> case, using <a> elements instead of 
> <section> elements.

    Yeah, I missed that in the spec. (Need to read more carefully 
instead of skimming...)

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

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

>>What is the motivation for passing on the <deck> of <cards> metaphor? To
>>presentational in nature?
> 
> When I think of <deck>s and <card>s, I don't think of sections or tabs.

    You're not supposed to. The <deck> element is a parallel to the XUL 
element <deck>, which only displays one element out of a group at any 
one time. The idea is that <deck> is a building block for more 
complicated UI like tabs (when combined with <tabstrip>), wizards, and 
different screens within a computer game.

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

Received on Thursday, 26 August 2004 19:42:39 UTC