[whatwg] Suggestion: Implementation of Tabbed Forms
mattraymond at earthlink.net
Wed Jun 30 05:43:33 PDT 2004
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">
> <legend>Home Page</legend>
> <legend>Fonts & Colors</legend>
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
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">
<legend>Fonts & Colors</legend>
> 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
>> Go tell that to a room full of web developers and see how hard they
> 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.
More information about the whatwg