[whatwg] Web Forms 2.0 Feedback
ian at hixie.ch
Tue Feb 12 17:35:11 PST 2008
On Wed, 8 Dec 2004, Matthew Thomas wrote:
> 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).
> 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">
> <sh data="Name">
> <sh data="Size" sortorder="S, M, L, XL, XXL, XXXL">
> <sh id="flavor" data="Flavour">
> <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">
> 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.
The big problem with the above is that it doesn't let you put <select>
drop-downs into the treegrid, something which is relatively common. The
spec now covers this, anyway.
> > > (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.)
<menu> in HTML5 is a superset of HTML 3.2's, so it doesn't need to be
distinguished. Of course, there are no SGML versions of HTML5 defined in
the HTML5 spec, so the point here may be moot now.
> > 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.
<div> is, to my regret, still in the spec, for this very reason. So are
<b>, <i>, <sup>, and <sub>, though not necessarily in a strictly
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg