[whatwg] Suggestion: Implementation of Tabbed Forms

Lachlan Hunt wrote:
>   What about something like the following.  It doesn't change the 
> meaning or presentation of fieldset, and does not specify anything about 
> it being presented as tabs, however tabs may be the default presentation 
> in visual user agents.
> 
> <categoryset id="firefox-options">
>     <category>
>         <label>General</label>
>         <fieldset>
>             <legend>Home Page</legend>
>             ...
>         </fieldset>
>         <fieldset>
>             <legend>Fonts &amp; Colors</legend>
>             ...
>         </fieldset>
>         ...
>     </category>
>     <category>
>         <label>Privacy</label>
>         ...
>     </category>
> </categoryset>

    That would be fine, except that the name "category" may be to 
specific. For instance, the sections could be grouped by stages or 
chronology. The sections may even be indistinguishable from each other 
except for the fact that they are in different sections. This is 
especially true if the WF2 repetition model is used to create each 
<category> element. Perhaps <group> and <groupset> would be better. We 
could then create a CSS property "group-type" to govern the 
presentational aspects.

    Actually, now that I think of it, there's still a problem. The 
<category> and <categoryset> elements would degrade to nothing in IE 
6.0, and any styling used on them would not show up. It would actually 
be worse than the <fsgroup>/<fieldset> solution in terms of degrading 
from a presentation standpoint, because at least when there were <div> 
elements, you could style them.

    (Note that in my <fsgroup> example, only the fieldsets that were 
immediate children of <fsgroup> sere intended to be rendered as tabs. 
Grandchild <fieldset> elements, et cetera, would be unaffected. Granted, 
this is not as clean as your solution...)

    Perhaps we should introduce a semantically based |type| attribute to 
<div> to specify relationships between contained elements:

<div type="groupset" id="firefox-options">
   <div type="group">
     <label>General</label>
     <fieldset>
       <legend>Home Page</legend>
       ...
     </fieldset>
     <fieldset>
       <legend>Fonts &amp; Colors</legend>
       ...
     </fieldset>
     ...
   </div>
   <div type="group">
     <label>Privacy</label>
     ...
   </div>
</div>

> This structure could be presented as tabs along the top, as buttons down 
> the side as in Firefox, or as a list like in Mozilla, or any other 
> presentation you can think of.

    Sounds good, although I think that CSS should control the 
presentation in very specific ways, while the UA should only specify the 
layout.

>>    Go tell that to a room full of web developers and see how hard they
>> laugh.
> 
>   I'm sure if the room was full of HTML terrorists...

    Oh, I can hear it now: "If you mess with the semantics of HTML, the 
terrorists win!" ;)

 > ...who've never built a
> site with anything but presentational abuse of tables and font tags, 
> they would laugh, or at least stand there bewildered about there being 
> any other way of doing it.  However, any descent web developer would 
> agree that tables for layout is incorrect.

    I've done a tableless website, with graphics and pure CSS rollovers, 
and from my experience, I can say that some website layouts would be 
exceedingly difficult to do without using tables for presentation. In 
the business world, your boss is not going to extent the web development 
schedule by days or weeks while you work out the display problems with 
your table-free layout in IE. In theory, it would be nice to create a 
solution based entirely on technological merit, but in the real world 
you have to consider toolsets, standards support, the learning curve of 
developers, et cetera.

    Hopefully, the situation with regards to table-free layout 
specifically will get better as the IE development team start working on 
it again, but I'm not holding my breath.

    This is sort of going off in a direction that has nothing to do with 
tabs--er--grouping structures that, with the aid of CSS or UA defaults, 
may be rendered as tabs. Perhaps it would be helpful if you started a 
separate thread stating your objections to specific items in WF2 you 
consider corruptions of the semantics in HTML. If there are more 
semantically correct solutions to be found that accomplish the same 
tasks as existing portions of the spec, please bring them to our attention.

>   No, the <div> element was created as a generic structural container 
> for logically and structurally grouping the document into divisions. 
> Because <div>, and <span>, have no default presentation except for being 
> block and inline, respectively, style sheets need to be used in order or 
> the structure to be percieved, but that doesn't mean it was created for 
> presentational purposes only.

    Noted. Inspiration for <div> semantic typing above.

>   The reason for using tabs is semantic, the method to implement them 
> should be structural, however the use of tabs is presentational.

    Then extending semantic grouping and adding properties to CSS to 
style the new semantic elements, as above, should cause no problem.

Received on Wednesday, 30 June 2004 05:43:33 UTC