[whatwg] Suggestion: Implementation of Tabbed Forms

[Matthew Raymond]

Lachlan Hunt wrote:
>   I assume you meant <fieldset>.

    Correct. Freudian slip. The VB frame control is equivalent to a
<fieldset> element.

>   Tabs are not a control in a document, they are simply a 
> presentational/functional method of displaying sections.

    There is an element of presentation to many elements in HTML. In
fact, few browsers render some elements with any noticeable difference.
For instance: TT, I, B, BIG, SMALL, STRIKE, S, and U. While the user
agent makes some determination as to how this will be rendered, do you
honestly mean to tell me that <b> and <i> have no presentational
context? Similarly, if you look at the various values of the |type|
attribute for <input>, you'll notice that pretty much ALL of the types
are used for presentational or functional purposes.

    If you like, however, we could do this:

    <fsgroup>
      <fieldset><legend>FS 1</legend> ...Some Content...</fieldset>
      <fieldset><legend>FS 2</legend> ...Some Content...</fieldset>
      <fieldset><legend>FS 3</legend> ...Some Content...</fieldset>
    </fsgroup>

    With the above, <fsgroup> is simply a group of fieldsets, and the
browser can render it however it wishes. Of course, if it just happens
to render it as three tabs, who are we do judge. ;)

> In an
> application user interface language such as XUL, they may be implemented 
> as a control, but not in a document language such as HTML.

    If you feel that HTML should ONLY be a language for documents, then
what are you doing in a mailing list for adding application-related
extensions to HTML?

>   Seperating structure from presentation and functionality does 
> everything to protect the *semantic* purity of (X)HTML.

    At some point, some basic GUI concepts have to be included at the
semantic level, or otherwise all you have is an over glorified word
processor format with scripting. Heck, even in VBA I can use canned tab
controls!

>> For instance, I could use style sheets and Javascript to create a
>> table without using any of the HTML table elements, but this means
>> recreating both the organizational structure of tables and recreating
>> the default styling of tables. Why would we want to make the
>> webmaster do all this just to avoid introducing a small bit of
>> additional markup?
>
>   If something is being displayed as a table for purely presentational 
> purposes, then that's exactly how it should be done.  If it's a table 
> because the content is logically, structurally and semantically tabular, 
> then it should be marked up in a table.

    Go tell that to a room full of web developers and see how hard they
laugh.

>>    For instance, in Netscape Navigator 4.0, your example 
>> (http://www.alistapart.com/d/eatcake/5.html) doesn't work at all. With 
>> Javascript turned off, all of the panels in the example display at the 
>> same time.
>
>   Of course it's not going to function as tabbed panes, displayed one at 
> a time with JS disabled, that's why it falls back to all the content 
> displayed at the same time.

    What's your point. If I were using a new element called
<meaningful>, it would default to just text. Does that mean that
<meaningful> is meaningless? No, it simply means it degrades to text on
older browsers.

> Does the meaning of the content change in 
> any way when it's not displayed as the tabs?  No, it doesn't...>

     Yes it does. The <div> elements may be in proximity to each other,
but there is nothing to associate them to each other semantically. And
having several <div> elements within a <div> does not necessarily
identify them as being used for the same purpose. The <div> element was
specifically created to be styled, not to establish relationships
between their contented elements.

> Therefore, the use of tabs is purely presentational.

    As stated above, clearly it is not.

>   How does it degrade poorly?  The only difference between the two 
> solutions is that one has a default presentation of a border and a 
> label.

    Wrong. The example always requires CSS and Javascript to give the
full effect. My <fieldset>-based tabbing requires only a WF2-capable
[X]HTML renderer. That means if your watch has a browser on it, you can
still use the tabs. In fact, considering the screen real estate, tabs
may be a better option. Furthermore, the Javascript and CSS can be used
to make the <fieldset> elements into tabs on non-WF2 UAs.

>  However, if fieldsets were used, then it would be semantically
> incorrect (in that example) because it's not marking up a group of form 
> fields.

    You are confused. It is you who has presented an example of tabs
containing document content, not me. All of my examples contain
form-related elements. Not that I would care if people put other things
in the <fieldset> elements, though, but you can't dismiss both by
attacking one.

> Also, in that example, the <legend>s have simply been replaced 
> by headings, so there's very little difference.

    The element <legend> is SEMANTICALLY liked to its container,
<fieldset>. Can you say the same for <div> and <h3>? Nope!

>   No, semantic purity of the mark up language *MUST* be maintained, and, 
> if anything, should infact be improved.  I think you will find that it 
> more productive and flexible when the markup is not mixed with any 
> presentation or functionality.

    Well, as long as your aren't taking a radical position, then...