Implement the HTML5 command API

ASSIGNED
Assigned to

Status

()

Core
DOM: Core & HTML
ASSIGNED
6 years ago
24 days ago

People

(Reporter: janv, Assigned: janv)

Tracking

(Blocks: 2 bugs, {dev-doc-needed})

Trunk
dev-doc-needed
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Comment hidden (empty)
(Assignee)

Comment 1

6 years ago
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
Assignee: nobody → Jan.Varga
Version: unspecified → Trunk
(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.
What is the advantage of such a state object from a page author's point of view?
(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.
Replace commandObject with commandType and that's exactly how the spec currently works, no?
(Assignee)

Updated

6 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 6

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

Comment 7

6 years ago
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 ?
Not really, since JS can't pass primitive values by reference.
(Assignee)

Comment 9

6 years ago
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 :)

Updated

6 years ago
Keywords: dev-doc-needed

Updated

5 years ago
Blocks: 568516
Blocks: 802882
You need to log in before you can comment on or make changes to this bug.