[whatwg] Suggestion: Implementation of Tabbed Forms

[Matthew Raymond]

Joost Smit wrote:
> Lachlan Hunt wrote:
>>   No!  Tabs are a presentational, not structural, and thus should not 
>> be included in (X)HTML, or any other semantic markup language.

    While we're at it, let's get rid of <fieldset>, <hr> and <img>. They 
can all be replaced by CSS anyway. Screw Lynx and other browsers that 
may not completely support CSS!

> I don't know for sure, tabs can be both structural and presentational i 
> think.

    Correct. More specifically, tabs themselves could be heavily 
stylized, so they are not completely presentational. They are a 
structure for visually organizing information.

> Matthew Raymond suggested to implement a tabbed form using <fieldset> 
> and <form>, while of course, you can do it in normal html too.

    Not really. As stated before in this mailing list, the idea that 
Javascript will be enabled on all clients is not correct for all 
circumstances, especially in environments where JS is considered a 
security risk.

> I think what Matthew meant is that when you define it a standard 
> (although you can do it in html) it's easier to use.

    Correct. Having tabs defined purely in HTML is a lot easier than 
creating tabs with HTML+CSS+Javascript. Some people out there writing 
web pages barely know HTML. Remember, there's a difference between 
whipping up a web page in an editor and coding DHTML-based controls.

> Btw....in the webform specification : (under 1.5 Missing features) it 
> says the following :
> "Elements or properties to create a "tabbed" or "wizard" interface. This 
> need will be addressed in a separate specification."
> 
> That's exactly how i feel about this, it doesn't belong in the webforms 
> 2.0 specification, and I think it can be a useful extension of another 
> specification.

    I never stated what spec tabs should be in. I was originally 
thinking this should be in Web Apps 1.0, but I didn't know for certain 
this couldn't be included in WF2. Thank you for clearing that up.

>>   There are already methods available that do exactly this, which 
>> remain accessible with either or both CSS and JS unavailable.
[Snip!]
> I'm sure if it can be done easy, it will be used. That's a big deal of 
> the whole WHATwg specifications i think. Most of the proposed form 
> controls can be done with html/javascript/php and whatever method you 
> choose. But it will be a lot easier with this new specification.

    Precisely. I could code just about anything in HTML+CSS+Javascript, 
but you'd still run into the following problems:

1) Performance would be poor in comparison to a natively coded HTML-only 
solution. For instance, the previous example 
(http://www.alistapart.com/d/eatcake/5.html) flickers visibly when you 
click each tab. (It also alters the page size, which tabs typically 
don't do in native UIs, but that's another issue.)

2) The implementation would not reflect the look and feel of the native 
operating system. Mozilla is just starting to get this right using 
custom CSS, XBL and XUL. Using the available W3C standards in IE 6.0, 
you don't stand a chance.

3) The implementation may not work on all browsers, especially if that 
browser lacks support for a key Javascript or CSS feature. For instance, 
in theory, CSS can completely replace HTML frames from a presentation 
standpoint. However, because of bugs in Internet Explorer, HTML frames 
are still necessary for some web site layouts.

4) Implementations that use CSS-styled <div> elements for tabs becomes 
non-modular when the user wants to change the styling of the tabs. The 
user is forced to alter the CSS (and perhaps even the Javascript) to 
change the look and feel of the tabs.