[whatwg] Web Forms 2.0 Feedback

[Matthew Thomas]

On 8 Dec, 2004, at 3:19 PM, Ian Hickson wrote:
>
> On Wed, 10 Nov 2004, Matthew Thomas wrote:
>>>
>>> In the current spec, <optgroup> may be nested, but this doesn't imply
>>> hiearchical menus like in the HTML4 spec. It would just mean indented
>>> options under headings, like you see in Windows sometimes
> ...
> When I said Windows, I meant the OS. I think the Windows XP Printer 
> window has this (but I don't have it at hand to check).

<http://www.uwec.edu/help/WinXP/print.htm>
<http://www.wellesley.edu/Computing/WinXP/printing.html>
I don't see it ... Maybe I'm looking at examples with not enough 
printers.

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

> ...
>> (For example: "You can search for DOCTYPEs all day at w3.org without
>> finding one page that lists them all. And when you do hunt down a
>> DOCTYPE (generally in relation to a particular Recommendation or 
>> Working Draft), it's often one that won't work on your site."
>> <http://alistapart.com/articles/doctype/>)
>
> The answer to that, of course, is for us to drop DOCTYPEs altogether,
> which I suggest we do in any XML-based version.

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

> ...
> All the presentational stuff will likely be deprecated, but I don't 
> really see any sensible way in which we can drop semantic markup 
> elements. For example, I'd love to drop <div> and <tfoot>, but I don't 
> see any sensible way to do that. It would likely lose the goodwill of 
> many authors.
> ...

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.

-- 
Matthew Thomas
http://mpt.net.nz/