[whatwg] Web Forms 2.0 Feedback

[Ian Hickson]

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 (no examples 
> > come to mind, but I've seen it occasionally).
> 
> Bonus points if it wasn't shareware. Triple bonus points if it was
> anything produced by Microsoft, Adobe, Macromedia, Apple, Corel,
> Novell, Symantec, McAfee, Borland, or Quark.

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). Those might only be one 
level of headers, though.


> > Given the number of people who request this feature, there is clearly 
> > a demand. I'm not sure what the better solution to that demand is.
> 
> A tree control 
> <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-July/ 
> 000856.html>. Yes, it would be larger than an option menu, but I suspect 
> authors using <optgroup> are more interested in the ability to make 
> single rather than multiple selections than they are in the size of the 
> control.

Tree controls are a lot more complicated than just lists of options with 
categories, though. I agree we need a tree control, but I don't see that 
it would replace the simple case here.

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


> > > They're semantically different. The former does something that 
> > > usually will open a new page (and/or open or close a window); for 
> > > example, "OK", or "Insert Addresses...", or "Don't Save". The latter 
> > > does something that usually won't open a new page (and/or open or 
> > > close a window); for example, "Add Row", or "Remove Row", or "Play".
> > 
> > Actually they're semantically identical. The only difference is that 
> > <button> can have element content, and <input> can't.
> 
> Actually, buttons with rounded ends and buttons with rectangular ends 
> have had the semantic meanings I described above since Mac OS 8.0 
> (albeit that those meanings were not explicitly stated in the HIGs). 
> When <button> was introduced into HTML, UAs rendered it with rectangular 
> ends, while retaining rounded ends for <input type="submit">. (This 
> distinction was originally not apparent on Windows, but it has become 
> apparent since Windows XP.) This was consistent with the native meanings 
> because <input type="submit"> almost always opens a new page (and 
> sometimes opens/closes a window), whereas <button> is usually used for 
> scripts to alter the content/state of items within a page.

While it is possible that some UAs, in order to handle the difference 
between buttons that can contain arbitrary markup and buttons that just 
have text, have ended up with two different widgets, I assure you that 
semantically, the two ways of getting buttons in HTML are absolutely 
equivalent, identical, and interchangeable. Any suggestion that they are 
not is an accident.


> It is true that the semantics are currently happening by accident, and 
> they can be flouted if authors try hard enough, but they do exist. They 
> may not be worth keeping; conversely, they may be worth specializing 
> even further. (For example, Mac OS X introduces completely circular 
> buttons, primarily used for controlling playback of a media track.)

At the end of the day, a button, an item on a TTY menu, and a command in a 
voice-driven UA, are equivalent. What they look like (round, square, 
rounded, bevelled, loud, quiet, whatever) is a stylistic matter.


> > Csaba's point is well-made, actually. I don't think anything in his 
> > list warrants deprecation at this point, but it is definitely 
> > important for us not to introduce too much redundant stuff. People 
> > should not feel at all worried about suggesting that we're adding too 
> > much.
> 
> Adding a little in each revision will eventually have the same effect as 
> adding too much in a single version; the spec will become too complex 
> for people to bother reading, so authors will copy-and-paste 
> erroneous/inappropriate code from nearby pages instead of referring to 
> the spec.

Indeed, with each revision the bar for adding new features has to get 
higher and higher.


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


> So when making your list of new block elements for HTML 5, for example, 
> ideally you should have a comparable list of elements and attributes 
> that are to be removed.

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.


> > > Because that would be bizarre behavior for those people accustomed 
> > > to the behavior of native option menus, i.e. most people who have 
> > > used a computer. (And yes, I think unspecified radiogroups should 
> > > default to selecting the first, too, but apparently that wouldn't be 
> > > backward-compatible.)
> > 
> > Yeah, the spec is merely describing what UAs do. UAs have tried to do 
> > other things, but they always fall back on that behaviour because 
> > sites actually depend on it now. ...
> 
> I noticed a couple of days ago that "ISO-HTML requires that at all times 
> one and only one of the radio buttons in a set be checked. Initially, if 
> none of the <INPUT> elements in a set of radio buttons specifies 
> CHECKED, then the user agent shall mark the first radio button of the 
> set as checked" <http://www.cs.tcd.ie/15445/UG.HTML#I.RADIO>. Ah well.

Yeah, if we could go back and do again, there are lots of things that we 
would all change, I'm sure. (Like, just using XForms, or some such.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'