[whatwg] Web Forms 2.0 Feedback
ian at hixie.ch
Mon Nov 8 15:56:33 PST 2004
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
> > 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
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg