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

[Bug 13608] Add <menuitem> element

From: <bugzilla@jessica.w3.org>
Date: Wed, 03 Aug 2011 21:20:14 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1QoirO-0005aD-GT@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13608

--- Comment #6 from Jonas Sicking <jonas@sicking.cc> 2011-08-03 21:20:14 UTC ---
It's a lot more clear to have the meaning of an element depend on its name,
rather than its name and its context.

In the example in

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-July/015434.html

the <command> element has three distinct meanings:

1. Create actual command which can be triggered using various UI features
2. Create a menu item
3. Create a toolbar button

As a result, the markup looks terribly confusing. Why does the <command> in the
menu have to refer to another <command>? How and why are they different? Can a
<command> in a menu refer to a <command> in a toolbar?


The markup in that example would be a lot easier to understand if it looked
like:

   <head>
    ...
    <command id="copy" label="Copy" onclick="copy()">
    <command id="cut" label="Cut" onclick="cut()">
    <command id="paste" label="Paste" onclick="paste()">
   </head>
   ...
   <toolbar>
    <button command="copy">
    <button command="cut">
    <button command="paste">
    ...
   </toolbar>
   <menu type="context">
    <menuitem command="copy">
    <menuitem command="cut">
    <menuitem command="paste">
    ...
   </menu>
   <accesskey command="copy" key="meta c">
   <accesskey command="cut" key="meta x">
   <accesskey command="paste" key="meta v">
   ...
   <toolbar>
    <button command="paste">
    ...
   </toolbar>

I'd also be fine with a separate <toolbarbutton> to separate from normal form
<button>s.

Additionally, if there's an error in the code that outputs the markup such that
nesting is a bit wrong, you end up with elements that still have the right
semantics (though they might no longer work properly due to having the wrong
parent), rather than drastically change their semantics since they now have a
parent of a different type.

I don't see what trying to abstract all forms of UI into a single <command>
element gives us?

-- 
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 Wednesday, 3 August 2011 21:20:17 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:16 UTC