Comment 1 Jan Varga [:janv] 2011-07-12 04:37:56 PDT

command API attributes were recently renamed in the spec:
http://html5.org/tools/web-apps-tracker?from=6285&to=6286
so the shadowing of attributes in derived interfaces got removed too

however, we should consider to add a new attribute e.g. .commandState instead, this attribute would return an object with all these attributes

see https://bugzilla.mozilla.org/show_bug.cgi?id=617528#c71

HTML5 context menu bug is not blocked by this for now

Comment 2 Mounir Lamouri (:mounir) 2011-07-12 07:22:19 PDT

(In reply to comment #1)
> however, we should consider to add a new attribute e.g. .commandState
> instead, this attribute would return an object with all these attributes
> 
> see https://bugzilla.mozilla.org/show_bug.cgi?id=617528#c71

Jan, you told me Cameron and Olli agreed. I do agree too given that I did propose that solution.
Does someone disagree? However, you could probably mention that solution in a W3 bug (or open a new one) and implement it here.

Comment 3 Jonas Sicking (:sicking) No longer reading bugmail consistently 2011-07-12 08:56:59 PDT

What is the advantage of such a state object from a page author's point of view?

Comment 4 Mounir Lamouri (:mounir) 2011-07-12 09:10:42 PDT

(In reply to comment #3)
> What is the advantage of such a state object from a page author's point of
> view?

Checking if an element is used as a command would be more natural:
if (element.commandObject !== null) {
}

Also, checking if the browser support the feature could be done with:
if (element.commandObject !== undefined) {
}
Which seems better than checking a random attribute or all of them.

Generally speaking, it would prevent polluting HTMLElement and will remove the "command" prefix for all command API related attributes.

Comment 5 Hixie (not reading bugmail) 2011-07-12 12:00:43 PDT

Replace commandObject with commandType and that's exactly how the spec currently works, no?

Comment 6 Jan Varga [:janv] 2011-07-16 04:03:40 PDT

.getCommandInfo(out DOMString aType, out DOMString aLabel, ...) would be nice too
however I just found out that WebIDL doesn't support "out" parameters :)

Comment 7 Jan Varga [:janv] 2011-07-16 04:19:15 PDT

sorry, I forgot to mention that it would be a good compromise IMO
it doesn't pollute the namespace so much and there's no need to create a helper object.

would it be possible to add support for out arguments ?

Comment 8 Cameron McCormack (:heycam) (away Sep 28) 2011-07-16 15:11:45 PDT

Not really, since JS can't pass primitive values by reference.

Comment 9 Jan Varga [:janv] 2011-07-27 00:36:06 PDT

ok, so the original spec contained these new attributes:
.commandType, .label, .icon, .disabled, .checked

An objection was raised that this pollutes the event namespace (onfoo="")
and it was proposed to use an object called e.g. .commandState that would contain these attributes.

Now, the attributes are:
.commandType, .commandLabel, .commandIcon, .commandHidden, .commandDisabled, .commandChecked

They were renamed to fix other problem (shadowing of attributes).

I think that authors won't use such "long" variable names in onfoo="", so it should be a bit less problematic.

Actually, the editing API looks similar:
execCommand()
queryCommandEnabled()
queryCommandIndeterm()
...

Now, I'm not sure if it is good or bad :)