W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2004

[whatwg] Web Forms 2.0 Feedback

From: Ian Hickson <ian@hixie.ch>
Date: Mon, 8 Nov 2004 23:56:33 +0000 (UTC)
Message-ID: <Pine.LNX.4.61.0411070509130.8631@dhalsim.dreamhost.com>
On Sat, 28 Aug 2004, Matthew Thomas wrote:
> On 21 Aug, 2004, at 3:23 AM, Csaba Gabor wrote:
> > ...
> > 3.  I'd like hierachical menus (pop up menus).  Why can't an option
> > element take other relevant HTML elements?
> 
> Hierarchical option menus don't exist as a native control on the 
> platform used by ~95 percent of Web users, and even on those platforms 
> where they do exist, they're extremely difficult to use.

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

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.


> > 4.  Does it make sense to have both an <input type=button/submit/
> > reset... and <button type=... element.
> 
> 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.


> > And for Pete's sake, have the spec say that access key properties must 
> > be reachable in a single key combination.
> 
> There are vastly more pages where type-ahead find is a more useful use 
> of unmodified keys than accesskey is, than pages where the reverse is 
> true.

Indeed.


> > 5.  One thing that bothers me is that there are so many ways to plop a 
> > submit button on a page.  You could make a link with an image, an 
> > <input type=submit onClick=...> element, an <input type=submit> 
> > element, a <button type=submit>, <button type=button onClick=...>, 
> > <input type=image ...>, <img ...>, image map, and probably I've left 
> > several out.  This smacks of bloat. As I mentioned, one button type or 
> > another should be depracated.
> 
> There are lots of ways (other than the <Hn> elements) to make something 
> look like a heading in CSS. Maybe we should deprecate CSS too. ;-)

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.


> > 7.  I've never understood why UAs render SELECT elements always on 
> > top. Can't we say/do something about that?
> 
> As far as I know, that's a combination of implementing both CSS and 
> non-sucky form controls. I doubt UAs are doing it out of negligence or 
> design, so "please stop being buggy" probably wouldn't achieve much.

There's no reason, in modern OSes, why that bug should have to exist.


> > 9.  You state in section 2.7 that the first option of a single select 
> > element is to be selected.  However, this is in opposition to what you 
> > allow for radio buttons.  And yet, single selects are essentially the 
> > equivalent of radio buttons, in a more compact form.  If you allow 
> > radio buttons to be unselected, why not allow the single select 
> > element to be unselected, too? ...
> 
> 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.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 8 November 2004 15:56:33 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:20 UTC