[whatwg] Suggestion: Implementation of Tabbed Forms

[Lachlan Hunt]

Matthew Raymond wrote:
> Lachlan Hunt wrote:
>>   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.

   Correct, which is why strike, s and u were deprecated in HTML4, and 
b, big, hr, i, small, sub, sup, tt are all in the presentation module of 
XHTML1.1.  You may  have also noticed that most of the elements in the 
presentation module have been completly removed from XHTML2, except 
<hr/> (though it's still being questioned) and <sub>/<sup>, cause 
they're not entirely presentational.

> 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?

   Of course not, they are entirely presentational.  Where on earth did 
that come from?  I never mentioned anything about them not being 
presentational.

>  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.

   Yes, I know.  That is unfortunate.  XForms attempted to address these 
presentational tendencies of HTML forms, for example by replacing <input 
type="radio"> and <select> with a single <select1> element, which can be 
presented as either radio buttons, a dropdown list or anything else.

>    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>

   A semantic structure like that would be better, but I don't like the 
idea of the default presentation of a fieldset being changed to a tab 
when within a group like that.  Since, as you will likely know, 
fieldsets are actually quite common within tab panes when they are used.

   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 & Colors</legend>
             ...
         </fieldset>
         ...
     </category>
     <category>
         <label>Privacy</label>
         ...
     </category>
</categoryset>

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.

>    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?

   Oh, sorry I didn't realise that this list was only for people who 
actually agreed with everything the WG is doing.  Never mind the fact 
that it would make me a hypocrite if I was completely against them, yet 
said or did nothing to at least help make them better.

   I'm not saying that I'm completely against them yet, just that I have 
some problems with them, but I'll have to leave most of my issues till 
later because I haven't had much time to completely review all the 
drafts, and reach my conclusions.  At this stage, my biggest problems 
are with web forms because XForms is already a recommendation, however I 
like the concept of a seperate language for web apps.  But I will always 
diagree with making them extensions to HTML, just so they can be 
internet-explorer-operable.  I would prefer a new XML language, or 
atleast an XHTML module.

>>   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.

   I'm sure if the room was full of HTML terrorists 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.

>> 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> element was specifically created 
> to be styled, not to establish relationships  between their
> contented elements.

   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.

>> Therefore, the use of tabs is purely presentational.
> 
>    As stated above, clearly it is not.

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

>>   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.

   Exactly.  "effect" being the key word, indicates that it is entirely 
presentational.  Of course, we need some form of presentation in order 
or us, as humans, to percieve the structure and semantics easily, but 
that presentational method should not be defined, as anything but 
default presentation in the spec.

>>  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.
> 
>   It is you who has presented an example of tabs containing document content, not me.

   Yes, I know, I was simply stating that the use of fieldsets in that 
example would not be appropriate.  I presented the example to show that 
the concept of tabs is presentational, but the structure they represent 
should be marked up.

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

   The div, being a structual grouping element, semantically groups all 
of it's content.  The legend in a fieldset is not just semantically 
associated with the fieldset, it is semantically and structurally 
associated with the fieldset's content, as is the heading within the div 
example.

-- 
Lachlan Hunt

http://www.lachy.id.au/
lachlan.hunt at lachy.id.au