670898 - Implement the HTML5 command API

Status: ASSIGNED

Description

[Jan Varga [:janv]]

Comment 1

[Jan Varga [:janv]]

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)]

(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]

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

Comment 4

[Mounir Lamouri (:mounir)]

(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)]

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

Comment 6

[Jan Varga [:janv]]

.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]]

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)]

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

Comment 9

[Jan Varga [:janv]]

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 :)