On 12/04/2012 09:27 PM, Ian Hickson wrote:
On Thu, 29 Nov 2012, Olli Pettay wrote:
I think we need to keep the contextmenu functionality, and I don't see
reasons to not to do it the way Gecko has it now (using <menu
type="context"> and <menuitem>).
Do you mean as opposed to allowing <menuitem> to refer to commands
declared elsewhere in the spec?
I'm not against <command> elements.
The main advantage of command="" is that it allows a context menu (or
toolbar menu, or anything else if we start adding command="" to other
elements like <button> or something) to define a command in one place, and
then refer to it other places, so that an author can e.g. disable it in
one place and have all the UI update.
I think that's pretty useful. Is this not something Gecko will implement?
(It's based on XUL...)
I'm also still hoping from input from Safari, Opera, and IE regarding what
kinds of stuff would be acceptable to implement here.
type=button might be nice.
Some feedback that was raised on IRC was that it might make more sense to
have a <button type=menu> that, when clicked, shows the contextmenu="". Or
a <button type=menu menu=...> that uses the designated menu. Or <button
type=menu> Label <menu type=context>...</menu> </button> or some such.
Yup, some form of these might be ok.
Need to just remember that the contents of <button> are handled differently in
different engines. Some pass the events through <button>, but others
honor the old spec where events aren't supposed to go to child elements
of <button>
The idea being that it's easier to style a <button> to work like a menu
button than to style the <menu> element itself, since you really want the
<menu> element to be styled as part of being the actual menu part.
In Gecko MenuItem inherits Command, so it has type, label, icon etc. We
could merge those two interfaces.
The spec has no Command interface. Do you mean HTMLCommandElement, or the
command* attributes on HTMLElement?
I mean HTMLCommandElement.
But if we keep <command> the merge obviously shouldn't happen.
