W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > September 2011

[Bug 13608] Add <menuitem> element

From: <bugzilla@jessica.w3.org>
Date: Mon, 26 Sep 2011 06:55:55 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1R856Z-0007ji-7z@jessica.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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:02:04 UTC