[whatwg] Suggestion: Implementation of Tabbed Forms
Matthew Raymond
mattraymond at earthlink.net
Thu Aug 26 19:42:39 PDT 2004
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.
More information about the whatwg
mailing list