[whatwg] Web Forms 2.0 Feedback

[Matthew Raymond]

Matthew Thomas wrote:
> On 8 Dec, 2004, at 3:19 PM, Ian Hickson wrote:
>> (One of the main reasons I haven't yet specified the tree control in 
>> the Web Apps draft is that I can't work out how to make it support the 
>> basic things a tree control needs to support while still having some 
>> sort of backwards-compatibility story, btw.)
> 
> <select id="wiblet" initialsort="flavor">
>   <shead>
>     <sh data="Name">
>     <sh data="Size" sortorder="S, M, L, XL, XXL, XXXL">
>     <sh id="flavor" data="Flavour">
>   </shead>
>   <sbody>
>     <option value="foo" icon="foo.jpg">Foo
>     <sd data="M"><sd data="Vanilla">
>     <option value="bar" icon="bar.png">Bar
>     <sd class="strange" data="XOS"><sd data="Vanilla">
>     <option value="hum" iconcolor="#a06033">Hum
>     <sd data="XXL"><sd data="Caramel">
>     <optgroup label="Adjectives">
>       <option value="squiggly" icon="squiggle.png">Squiggly
>       <sd data="S"><sd data="Strawberry">
>       <option value="hum" icon="dunce.png">Unfortunate
>       <sd data="XL"><sd data="Hokey Pokey">
>     </optgroup>
>   </sbody>
> </select>
> 
> Some things might need to be tweaked (such as the names of the new 
> elements and attributes, and the possible necessity of </option> for 
> forward compatibility); but I don't see any backward compatibility 
> problems, other than that authors may mistakenly put essential data in 
> non-primary columns.

    I notice you have a lot of elements there that imitate the elements 
for tables. Why not just use <table> as a basis for this instead of select?

| <table>
|  <colgroup>
|   <col usetree id="col_name"/>
|   <col id="col_size"  sortorder="S, M, L, XL, XXL, XXXL"/>
|   <col id="col_flavor" sort="asc"/>
|  </colgroup>
|  <thead>
|   <tr><th>Name</th><th>Size</th><th>Flavor</th></tr>
|  </thead>
|  <tbody>
|   <tr>
|    <th icon="foo.jpg">Foo</th>
|    <td>M</td>
|    <td>Vanilla</td>
|   </tr>
|   <tr>
|    <th icon="bar.png">Bar</th>
|    <td class="strange">XOS</td>
|    <td>Vanilla</td>
|   </tr>
|   <tr>
|    <th icon="hum.gif">Hum</th>
|    <td>XXL</td>
|    <td>Caramel</td>
|   </tr>
|   <tr id="tr_adjective"><th>Adjectives</th><td></td><td></td></tr>
|   <tgroup for="tr_adjective">
|    <tr>
|     <th icon="squiggle.png">Squiggly</th>
|     <td>S</td>
|     <td>Strawberry</td>
|    </tr>
|    <tr>
|     <th icon="dunce.png">Unfortunate</th>
|     <td>XL</td>
|     <td>Hokey Pokey</td>
|    </tr>
|   </tgroup>
|  </tbody>
| </table>

> Are you suggesting that it is also desirable in SGML-based versions? (A 
> doctype will help UAs distinguish between, for example, HTML 3.2's 
> <menu> and HTML 5's <menu>. That would be just the first example of 
> redefinition in what is a very young language by linguistic standards.)

    Currently, WA1 only defines <menu> as being a HTML5 menu when it's 
inside a <menubar>, so all a UA has to do is look for the proper parent 
element. Otherwise, the current specification treats <menu> the exact 
same way as HTML 4.01. Because of this, there is no need for a doctype 
with respect to menus.

> Even if goodwill was irrelevant, if you made HTML semantically complete 
> enough to drop <div>, I guarantee you would have added too many block 
> elements for authors to choose the correct one anything like most of the 
> time. <div>, <b>, <i>, <sup>, <sub>, and <span> might be presentational 
> tofu, but they keep HTML from being too complex, and that's important.

    Although I understand, and to some extent agree, I wouldn't make 
this argument. First of all, <div> and <span> were created as pure 
styling elements for situations where there may not be a semantically 
matching element in HTML. Since semantic value is as limitless as your 
imagination, it only makes sense that you have such markup.

    The elements <sup> and <sub> are not entire presentational. For 
example, how do you represent a chemical formula in HTML? If a title has 
a power at the end, how do you indicate that? Granted, they have a 
presentational component to them, but that presentation itself has a 
semantic meaning.

    Other elements, like <b> and <i>, are handy, but purely 
presentational. I can live without them if I had to. Besides, I could 
always reimplement them when XBL2 becomes available.