Open
Bug 670898
Opened 11 years ago
Updated 7 months ago
Implement the HTML5 command API
Categories
(Core :: DOM: Core & HTML, enhancement, P3)
Core
DOM: Core & HTML
Tracking
()
NEW
People
(Reporter: janv, Unassigned)
References
(Blocks 1 open bug, )
Details
(Keywords: dev-doc-needed)
No description provided.
Reporter | ||
Comment 1•11 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
Updated•11 years ago
|
Version: unspecified → Trunk
Comment 2•11 years ago
|
||
(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?
Comment 4•11 years ago
|
||
(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•11 years ago
|
||
Replace commandObject with commandType and that's exactly how the spec currently works, no?
Reporter | ||
Updated•11 years ago
|
Status: NEW → ASSIGNED
Reporter | ||
Comment 6•11 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 :)
Reporter | ||
Comment 7•11 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 ?
Comment 8•11 years ago
|
||
Not really, since JS can't pass primitive values by reference.
Reporter | ||
Comment 9•11 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 :)
Keywords: dev-doc-needed
Updated•4 years ago
|
Priority: -- → P3
Reporter | ||
Updated•4 years ago
|
Assignee: jvarga → nobody
Status: ASSIGNED → NEW
Updated•3 years ago
|
Type: defect → enhancement
You need to log in
before you can comment on or make changes to this bug.
Description
•