- From: <bugzilla@jessica.w3.org>
- Date: Mon, 26 Sep 2011 06:55:55 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13608 Ian 'Hixie' Hickson <ian@hixie.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |blocker --- Comment #15 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-09-26 06:55:53 UTC --- > The value is much more understandable markup I don't really see why <command> would be any less comprehensible than <menuitem>. Indeed, I probably would often suggest people use neither -- for example, if the command is just to follow a link, I'd suggest using <a>, and so on. > as well as markup which is easier > to style or otherwise deal with. For example if you want to use XBL to render > menuitems yourself you can do that more easily if menuitems all have the same > name. Changing <command> to <menuitem> doesn't prevent the menu items from being all manner of other elements as well, e.g. <a>, <button>, <select>, etc. So I don't see how that's the case. I don't really see how you'd ever style the menu via the DOM, though. The whole point is to make it render using platform-specific conventions, taking all the various HTML semantics and turning them into one consistent UI; if we were going to allow authors to style this, we'd probably just use pseudo-elements, as in: menu ::menu-item { color: yellow; background: navy; } menu ::menu-separator { border-color: white; } The menu construction algorithm really doesn't work well for something that styles the DOM directly (consider e.g. the separator collapsing, the merging into the UA menu, etc). > I'd likewise ask the opposite question. What's the benefit of using the same > element name for something that has dramatically different rendering? The rendering has no bearing on it. It's the same semantic. > The fact > that <input> does has been more a source of annoyance than a benefit. I'm not really convinced of that. It has actually been quite helpful in various ways: it makes it easy to introduce new input types, doesn't require regular parser changes, etc. In fact, as far as I can tell <menuitem>/<command> follow the same pattern as <input>: you can use them for commands, radio items, and checked items. If we were really trying to avoid the <input> design pattern, we'd have three elements, not one. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Monday, 26 September 2011 06:55:56 UTC