Properties of commands

This specification defines a number of commands, identified by ASCII case-insensitive strings. Each command can have several pieces of data associated with it:

• Action: What the command does when executed via execCommand(). Every command defined in this specification has an action defined for it in the relevant section. For example, the bold command's action generally makes the current selection bold, or removes bold if the selection is already bold. An editing toolbar might provide buttons that execute the action for a command if clicked, or a script might run an action without user interaction to achieve some particular effect. Actions return either true or false, which can affect the return value of execCommand().
• Indeterminate: A boolean value returned by queryCommandIndeterm(), depending on the current state of the document. Generally, a command that has a state defined will be indeterminate if the state is true for part but not all of the current selection, and a command that has a value defined will be indeterminate if different parts of the selection have different values. An editing toolbar might display a button or control in a special way if the command is indeterminate, like showing a "bold" button as partially depressed, or leaving a font size selector blank instead of showing the font size of the current selection. As a rule, a command can only be indeterminate if its state is false, supposing it has a state.
• State: A boolean value returned by queryCommandState(), depending on the current state of the document. The state of a command is true if it is already in effect, in some sense specific to the command. Most commands that have a state defined will take opposite actions depending on whether the state is true or false, such as making the selection bold if the state is false and removing bold if the state is true. Others will just have no effect if the state is true, like the justifyCenter command. Still others will have the same effect regardless, like the styleWithCss command. An editing toolbar might display a button or control differently depending on the state and indeterminacy of the command.
• Value: A string returned by queryCommandValue(), depending on the current state of the document. A command usually has a value instead of a state if the property it modifies can take more than two different values, like the foreColor command. If the command is indeterminate, its value is generally based on the start of the selection. Otherwise, in most cases the value holds true for the entire selection, but see the justifyCenter command and its three companions for an exception. An editing toolbar might display the value of a command as selected in a drop-down or filled in in a text box, if the command isn't indeterminate.
• Relevant CSS property: This is defined for certain inline formatting commands, and is used in algorithms specific to those commands. It is an implementation detail, and is not exposed to authors. If a command does not have a relevant CSS property specified, it defaults to null.

Supported commands

If you try doing anything with an unrecognized command (except queryCommandSupported), IE10 Developer Preview throws an "Invalid argument" exception. Firefox 15.0a1 throws NS_ERROR_NOT_IMPLEMENTED on querying indeterm/state/value, and returns false from execCommand/queryCommandEnabled. Chrome 19 dev returns false from everything. Opera Next 12.00 alpha throws NOT_SUPPORTED_ERR for execCommand and returns false for enabled/state/value. Originally I went with IE, although of course with a standard exception type. But after discussion (WebKit bug, Mozilla bug), I changed to match WebKit (except that I return "" for value instead of false). The issue is that there are a whole bunch of IE commands that no one else supports or wants to support, and throwing on execCommand() would make lots of pages break. WebKit was unwilling to take the compat risk, so we took the safer option.

Some commands will be supported in a given user agent, and some will not. All commands defined in this specification must be supported, except optionally the copy command, the cut command, and/or the paste command. Additional vendor-specific commands can also be supported, but implementers must prefix any vendor-specific command names with a vendor-specific string (e.g., "ms", "moz", "webkit", "opera").

I.e., no trying to look good on lazy conformance tests by just sticking in a stub implementation that does nothing.

A command that does absolutely nothing in a particular user agent, such that execCommand() never has any effect and queryCommandEnabled() and queryCommandIndeterm() and queryCommandState() and queryCommandValue() each return the same value all the time, must not be supported.

In a particular user agent, every command must be consistently either supported or not. Specifically, a user agent must not permit one page to see the same command sometimes supported and sometimes not over the course of the same browsing session, unless the user agent has been upgraded or reconfigured in the middle of a session. However, user agents may treat the same command as supported for some pages and not others, e.g., if the command is only supported for certain origins for security reasons.

Authors can tell whether a command is supported using queryCommandSupported().

Enabled commands

At any given time, a supported command can be either enabled or not. Authors can tell whether a command is currently enabled using queryCommandEnabled(). Commands that are not enabled do nothing, as described in the definitions of the various methods that invoke commands.

Among commands defined in this specification, those listed in Miscellaneous commands are always enabled, except for the cut command and the paste command. The other commands defined here are enabled if the active range is not null, its [=range/start node=] is either editable or an [=editing host=], the editing host of its [=range/start node=] is not an EditContext editing host, its [=range/end node=] is either editable or an [=editing host=], the editing host of its [=range/end node=] is not an EditContext editing host, and there is some [=editing host=] that is an [=tree/inclusive ancestor=] of both its [=range/start node=] and its [=range/end node=].

Assorted common algorithms

To move a node to a new location, preserving ranges, remove the node from its original [=tree/parent=] (if any), then insert it in the new location. In doing so, follow these rules instead of those defined by the [=insert=] and [=remove=] algorithms:

Many of the algorithms in this specification move nodes around in the DOM. The normal rules for range mutation require that any range endpoints inside those nodes are moved to the node's parent as soon as the node is moved, which would corrupt the selection. For instance, if the user selects the text "foo" and then bolds it, first we produce <b></b>foo, then <b>foo</b>. When we move the "foo" text node into its new parent, we have to do so "preserving ranges", so that the text "foo" is still selected.

1. Let node be the moved node, old parent and old index be the old [=tree/parent=] (which may be null) and [=tree/index=], and new parent and new index be the new [=tree/parent=] and [=tree/index=].

2. This is actually implicit, but I state it anyway for completeness.

   If a [=boundary point=]'s node is the same as or a [=tree/descendant=] of node, leave it unchanged, so it moves to the new location.

3. If a [=boundary point=]'s node is new parent and its [=boundary point/offset=] is greater than new index, add one to its [=boundary point/offset=].
4. If a [=boundary point=]'s node is old parent and its [=boundary point/offset=] is old index or old index + 1, set its node to new parent and add new index − old index to its [=boundary point/offset=].
5. If a [=boundary point=]'s node is old parent and its [=boundary point/offset=] is greater than old index + 1, subtract one from its [=boundary point/offset=].

TODO: Do we want to get rid of attributes that are no longer allowed here?

To set the tag name of an {{Element}} element to new name:

This is needed because the DOM doesn't allow any way of changing an existing element's name. Sometimes we want to, e.g., convert a markup element to a span. In that case we invoke this algorithm to create a new element, move it to the right place, copy attributes from the old element, move the old element's children, and remove the old element.

1. If element is an HTML element with [=Element/local name=] equal to new name, return element.
2. If element's [=tree/parent=] is null, return element.
3. Let replacement element be the result of calling createElement(new name) on the {{Node/ownerDocument}} of element.
4. Insert replacement element into element's [=tree/parent=] immediately before element.
5. Copy all attributes of element to replacement element, in order.
6. While element has [=tree/children=], append the first [=tree/child=] of element as the last [=tree/child=] of replacement element, preserving ranges.
7. Remove element from its [=tree/parent=].
8. Return replacement element.

To remove extraneous line breaks before a node node:

<br> sometimes has no effect in CSS, such as in the markup foo<br><p>bar</p>. In such cases we like to remove the extra markup to keep things tidy.

1. Let ref be the {{Node/ previousSibling}} of node.
2. If ref is null, abort these steps.
3. While ref has [=tree/children=], set ref to its {{Node/lastChild}}.
4. While ref is invisible but not an extraneous line break, and ref does not equal node's [=tree/parent=], set ref to the node before it in [=tree order=].
5. If ref is an editable extraneous line break, remove it from its [=tree/parent=].

To remove extraneous line breaks at the end of a node node:

1. Let ref be node.
2. While ref has [=tree/children=], set ref to its {{Node/lastChild}}.
3. While ref is invisible but not an extraneous line break, and ref does not equal node, set ref to the node before it in [=tree order=].
4. If ref is an editable extraneous line break:

   1. If the block ends with <span><br></span>, for instance, we want to remove the span too.

      While ref's [=tree/parent=] is editable and invisible, set ref to its [=tree/parent=].

   2. Remove ref from its [=tree/parent=].

To remove extraneous line breaks from a node, first remove extraneous line breaks before it, then remove extraneous line breaks at the end of it.

Wrapping a list of nodes

To wrap a list node list of consecutive [=tree/sibling=] nodes, run the following algorithm. In addition to node list, the algorithm accepts two inputs: an algorithm sibling criteria that accepts a node as input and outputs a boolean, and an algorithm new parent instructions that accepts nothing as input and outputs a node or null. If not provided, sibling criteria returns false and new parent instructions returns null.

This algorithm basically does two things. First, it looks at the previous and next siblings of the nodes in node list. If running sibling criteria on one or both of the siblings returns true, the nodes in node list are moved into the sibling(s). Otherwise, new parent instructions is run, and the result is used to wrap node list. For instance, to wrap node list in a <b>, one might invoke this algorithm with sibling criteria returning true only for <b> elements and new parent instructions creating and returning a new <b> element.

1. We need to treat [^br^]s as visible here even if they're not, because wrapping them might be significant even if they're invisible: it can turn an extraneous line break into a non-extraneous one.

   If every member of node list is invisible, and none is a [^br^], return null and abort these steps.

2. If node list's first member's [=tree/parent=] is null, return null and abort these steps.

3. Trailing br's like this always need to go along with their line. Otherwise they'll create an extra line if we wrap in a block element, instead of vanishing as they should.

   If node list's last member is an inline node that's not a [^br^], and node list's last member's {{Node/nextSibling}} is a [^br^], append that [^br^] to node list.

4. See bug 13811, bug 14231. If there's a non-adjacent sibling that matches the sibling criteria and only invisible nodes intervene, we want to skip over the invisible nodes. For instance, bolding <b>foo</b><!--bar-->[baz] should produce <b>foo<!--bar-->baz</b>. Similarly, and more usefully, creating an ordered list with <ol><li>foo</ol> <p>[bar]</p> should produce <ol><li>foo</li> <li>[bar]</ol>, not <ol><li>foo</ol> <ol><li>[bar]</ol>.

   While node list's first member's {{Node/previousSibling}} is invisible, prepend it to node list.

5. While node list's last member's {{Node/nextSibling}} is invisible, append it to node list.
6. If the {{Node/previousSibling}} of the first member of node list is editable and running sibling criteria on it returns true, let new parent be the {{Node/previousSibling}} of the first member of node list.
7. Otherwise, if the {{Node/ nextSibling}} of the last member of node list is editable and running sibling criteria on it returns true, let new parent be the {{Node/nextSibling}} of the last member of node list.
8. Otherwise, run new parent instructions, and let new parent be the result.

9. This can only happen if new parent instructions is run and it returns null. This can be used to only merge with adjacent siblings, in case you don't want to create a new parent if that fails.

   If new parent is null, abort these steps and return null.

10. Most callers will create a new element to return in new parent instructions, whose parent will therefore be null. But they can also return an existing node if that makes sense, so the nodes will be moved to an uncle or something. The toggle lists algorithm makes use of this.

    If new parent's [=tree/parent=] is null:

    1. Insert new parent into the [=tree/parent=] of the first member of node list immediately before the first member of node list.

    2. Basically, we want any boundary points around the wrapped nodes to go inside the wrapper. Without this step, wrapping "{}<br>" in a blockquote would go like

       {}<br>
       -> {}<blockquote></blockquote><br>
       -> {}<blockquote><br></blockquote>.
       

       The second line is due to range mutation rules: a boundary point with an offset equal to the index of a newly-inserted node stays put, so it remains before it. With this step, it goes like

       {}<br>
       -> {}<blockquote></blockquote><br>
       -> <blockquote></blockquote>{}<br>
       -> <blockquote>{}<br></blockquote>.
       

       The difference in the final step is because we move the <br> "preserving ranges". This means that adjacent boundary points get swept along with it. Previously, the <blockquote> intervened, so a boundary point after it would get taken along but one before it would not.

       Another solution that one might be tempted to consider would be to just put the wrapper after the wrapped elements. Then the boundary points would stay put, before the wrapper, so they'd still be adjacent to the nodes to be wrapped, like:

       {<p>foo</p>}
       -> {<p>foo</p>}<blockquote></blockquote>
       -> <blockquote>{<p>foo</p>}</blockquote>.
       

       The problem is that this completely breaks if you're wrapping multiple things and not all are selected. It would go like this:

       <p>foo</p>{<p>bar</p>}
       -> <p>foo</p>{<p>bar</p>}<blockquote></blockquote>
       -> <p>foo</p><blockquote>{<p>bar</p>}</blockquote>
       -> <blockquote>{<p>foo</p><p>bar</p>}</blockquote>.
       

       The last step is again because of the range mutation rules: the boundary point stays put when a new node is inserted. They're fundamentally asymmetric.

       An alternative solution would be to define the concept of moving a list of adjacent sibling nodes while preserving ranges, and handle this explicitly at a more abstract level.

       TODO: Think about this some more. Maybe there's a better way.

       If any [=range=] has a [=boundary point=] with node equal to the [=tree/parent=] of new parent and [=boundary point/offset=] equal to the [=tree/index=] of new parent, add one to that [=boundary point=]'s [=boundary point/offset=].

11. Let original parent be the [=tree/parent=] of the first member of node list.
12. If new parent is before the first member of node list in [=tree order=]:
    1. If new parent is not an inline node, but the last visible [=tree/child=] of new parent and the first visible member of node list are both inline nodes, and the last [=tree/child=] of new parent is not a [^br^], call createElement("br") on the {{Node/ ownerDocument}} of new parent and append the result as the last [=tree/child=] of new parent.
    2. For each node in node list, append node as the last [=tree/child=] of new parent, preserving ranges.
13. Otherwise:
    1. If new parent is not an inline node, but the first visible [=tree/child=] of new parent and the last visible member of node list are both inline nodes, and the last member of node list is not a [^br^], call createElement("br") on the {{Node/ ownerDocument}} of new parent and insert the result as the first [=tree/child=] of new parent.
    2. For each node in node list, in reverse order, insert node as the first [=tree/child=] of new parent, preserving ranges.

14. This could happen if new parent instructions returned a node whose parent wasn't null.

    If original parent is editable and has no [=tree/children=], remove it from its [=tree/parent=].

15. Probably because both the previous and next sibling met them. We want to merge them in this case.

    If new parent's {{Node/nextSibling}} is editable and running sibling criteria on it returns true:

    1. If new parent is not an inline node, but new parent's last [=tree/child=] and new parent's {{Node/nextSibling}}'s first [=tree/child=] are both inline nodes, and new parent's last [=tree/child=] is not a [^br^], call createElement("br") on the {{Node/ ownerDocument}} of new parent and append the result as the last [=tree/child=] of new parent.
    2. While new parent's {{Node/nextSibling}} has [=tree/children=], append its first [=tree/child=] as the last [=tree/child=] of new parent, preserving ranges.
    3. Remove new parent's {{Node/nextSibling}} from its [=tree/parent=].
16. Remove extraneous line breaks from new parent.
17. Return new parent.

Allowed children

A name of an element with inline contents is "a", "abbr", "b", "bdi", "bdo", "cite", "code", "dfn", "em", "h1", "h2", "h3", "h4", "h5", "h6", "i", "kbd", "mark", "p", "pre", "q", "rp", "rt", "ruby", "s", "samp", "small", "span", "strong", "sub", "sup", "u", "var", "acronym", "listing", "strike", "xmp", "big", "blink", "font", "marquee", "nobr", or "tt".

An element with inline contents is an HTML element whose [=Element/local name=] is a name of an element with inline contents.

A node or string child is an allowed child of a node or string parent if the following algorithm returns true:

Often we move around nodes, and sometimes this can result in unreasonable things like two <p>'s nested inside one another. This algorithm checks for DOMs we never want to have, so that other algorithms can avoid creating them or fix them if they do happen. The fix disallowed ancestors algorithm is one frequently-invoked caller of this algorithm.

1. If parent is "colgroup", "table", "tbody", "tfoot", "thead", "tr", or an HTML element with [=Element/local name=] equal to one of those, and child is a {{Text}} node whose {{CharacterData/data}} does not consist solely of space characters, return false.

2. Actually, no node can occur in the DOM after plaintext, generally. But let's not get too carried away.

   If parent is "script", "style", "plaintext", or "xmp", or an HTML element with [=Element/local name=] equal to one of those, and child is not a {{Text}} node, return false.

3. If child is a [=document=], {{DocumentFragment}}, or {{DocumentType}}, return false.
4. If child is an HTML element, set child to the [=Element/local name=] of child.
5. If child is not a string, return true.
6. If parent is an HTML element:

   1. Cannot be serialized as text/html. In some cases it can, like <a>foo<table><td><a>bar</a></td></table>baz</a>, but it's invalid in those cases too, so no need for complication.

      If child is "a", and parent or some [=tree/ancestor=] of parent is an [^a^], return false.

   2. This generally cannot be serialized either, for p. For other elements with inline contents, this serves to prevent things like <span><p>foo</p></span>, which will parse fine but aren't supposed to happen anyway.

      If child is a prohibited paragraph child name and parent or some [=tree/ancestor=] of parent is an element with inline contents, return false.

   3. Also can't be serialized as text/html.

      If child is "h1", "h2", "h3", "h4", "h5", or "h6", and parent or some [=tree/ancestor=] of parent is an HTML element with [=Element/local name=] "h1", "h2", "h3", "h4", "h5", or "h6", return false.

   4. Further requirements only care about the parent itself, not ancestors, so we don't need to know the node itself.

      Let parent be the [=Element/local name=] of parent.

7. If parent is an {{Element}} or {{DocumentFragment}}, return true.
8. If parent is not a string, return false.

9. We allow children even where some intervening nodes will be inserted, like tr as a child of table.

   If parent is on the left-hand side of an entry on the following list, then return true if child is listed on the right-hand side of that entry, and false otherwise.

   • colgroup: col
   • table: caption, col, colgroup, tbody, td, tfoot, th, thead, tr
   • tbody, tfoot, thead: td, th, tr
   • tr: td, th
   • dl: dt, dd
   • dir, ol, ul: dir, li, ol, ul
   • hgroup: h1, h2, h3, h4, h5, h6
10. If child is "body", "caption", "col", "colgroup", "frame", "frameset", "head", "html", "tbody", "td", "tfoot", "th", "thead", or "tr", return false.

11. dd/dt/li will serialize fine as the child of random stuff, but it makes no sense at all, so we want to avoid it anyway.

    If child is "dd" or "dt" and parent is not "dl", return false.

12. If child is "li" and parent is not "ol" or "ul", return false.
13. If parent is on the left-hand side of an entry on the following list and child is listed on the right-hand side of that entry, return false.
    • a: a
    • dd, dt: dd, dt
    • h1, h2, h3, h4, h5, h6: h1, h2, h3, h4, h5, h6
    • li: li
    • nobr: nobr
    • All names of an element with inline contents: all prohibited paragraph child names
    • td, th: caption, col, colgroup, tbody, td, tfoot, th, thead, tr
14. Return true.

Inline formatting command definitions

The difference between "contained" and "effectively contained" is basically that 1) in <b>[foo]</b>, the text node and the <b> are effectively contained but not contained; and 2) in <b>f[o]o</b>, the text node is effectively contained but not contained, and the <b> is neither effectively contained nor contained.

A node node is effectively contained in a [=range=] range if range is not {{AbstractRange/collapsed}}, and at least one of the following holds:

• node is contained in range.

• So like <b>f[oo]</b> or <b>f[o]o</b> or <b>f[oo</b>}, but not <b>foo[</b>} or <b>f[]oo</b>.

  node is range's [=range/start node=], it is a {{Text}} node, and its [=Node/length=] is different from range's [=range/start offset=].

• node is range's [=range/end node=], it is a {{Text}} node, and range's [=range/end offset=] is not 0.

• Basically, anything whose children are all effectively contained should be effectively contained itself, except that in a case like <b>f[o]o</b> we don't want <b> to be effectively contained even though the text node is. That's because we split the text node before we actually do anything, and the <b> will no longer be effectively contained.

  node has at least one [=tree/child=]; and all its [=tree/children=] are effectively contained in range; and either range's [=range/start node=] is not a [=tree/descendant=] of node or is not a {{Text}} node or range's [=range/start offset=] is zero; and either range's [=range/end node=] is not a [=tree/descendant=] of node or is not a {{Text}} node or range's [=range/end offset=] is its [=range/end node=]'s [=Node/length=].

A modifiable element is a [^b^], [^em^], [^i^], [^s^], [^span^], [^strike^], [^strong^], sub, sup, or [^u^] element with no attributes except possibly style; or a [^font^] element with no attributes except possibly style, color, face, and/or size; or an [^a^] element with no attributes except possibly style and/or href.

A simple modifiable element is an HTML element for which at least one of the following holds:

• It is an [^a^], [^b^], [^em^], [^font^], [^i^], [^s^], [^span^], [^strike^], [^strong^], sub, sup, or [^u^] element with no attributes.
• It is an [^a^], [^b^], [^em^], [^font^], [^i^], [^s^], [^span^], [^strike^], [^strong^], sub, sup, or [^u^] element with exactly one attribute, which is style, which sets no CSS properties (including invalid or unrecognized properties).
• It is an [^a^] element with exactly one attribute, which is href.
• It is a [^font^] element with exactly one attribute, which is either color, face, or size.
• It is a [^b^] or [^strong^] element with exactly one attribute, which is style, and the style attribute sets exactly one CSS property (including invalid or unrecognized properties), which is "font-weight".
• It is an [^i^] or [^em^] element with exactly one attribute, which is style, and the style attribute sets exactly one CSS property (including invalid or unrecognized properties), which is "font-style".
• It is an [^a^], [^font^], or [^span^] element with exactly one attribute, which is style, and the style attribute sets exactly one CSS property (including invalid or unrecognized properties), and that property is not "text-decoration".
• It is an [^a^], [^font^], [^s^], [^span^], [^strike^], or [^u^] element with exactly one attribute, which is style, and the style attribute sets exactly one CSS property (including invalid or unrecognized properties), which is "text-decoration", which is set to "line-through" or "underline" or "overline" or "none".

Conceptually, a simple modifiable element is a modifiable element which specifies a value for at most one command. As the names imply, inline formatting commands will try not to modify anything other than modifiable elements. For instance, <dfn> normally creates italics, but it's not modifiable, so running the italic command will not remove it: it will nest <span style="font-style: normal"> inside.

A formattable node is an editable visible node that is either a {{Text}} node, an [^img^], or a [^br^].

Two quantities are equivalent values for a command if either both are null, or both are strings and they're equal and the command does not define any equivalent values, or both are strings and the command defines equivalent values and they match the definition.

Two quantities are loosely equivalent values for a command if either they are equivalent values for the command, or if the command is the fontSize command; one of the quantities is one of "x-small", "small", "medium", "large", "x-large", "xx-large", or "xxx-large"; and the other quantity is the resolved value of "font-size" on a [^font^] element whose size attribute has the corresponding value set ("1" through "7" respectively).

Loose equivalence needs to be used when comparing effective command values to other values, while regular equivalence is used in other cases. The effective command value for fontSize is converted to pixels, so comparing it to a specified value literally would produce false negatives. But a specified value in pixels is actually different from a specified value like "small" or "x-large", because there is no precise mapping from such keywords to pixels.

If a command has inline command activated values defined but nothing else defines when it is indeterminate, it is indeterminate if among formattable nodes effectively contained in the active range, there is at least one whose effective command value is one of the given values and at least one whose effective command value is not one of the given values.

For bold and similar commands, IE 9 RC seems to consider the state true or false depending on the first element. All other browsers follow the same general idea as the spec, considering a range bold only if all text in it is bold, and this seems to match at least OpenOffice.org's bold feature. Opera 11.11 seemingly doesn't take CSS into account, and only looks at whether something descends from a <b>. I couldn't properly test IE9 because it threw exceptions (Error: Unspecified error.) on most of the tests I ran. But what I have here seems to match Firefox 6.0a2 in every case, and Chrome 14 dev in all cases with a few exceptions.

If a command has inline command activated values defined, its state is true if either no formattable node is effectively contained in the active range, and the active range's [=range/start node=]'s effective command value is one of the given values; or if there is at least one formattable node effectively contained in the active range, and all of them have an effective command value equal to one of the given values.

If a command is a standard inline value command, it is indeterminate if among formattable nodes that are effectively contained in the active range, there are two that have distinct effective command values. Its value is the effective command value of the first formattable node that is effectively contained in the active range; or if there is no such node, the effective command value of the active range's [=range/start node=]; or if that is null, the empty string.

The notions of inline command activated values and standard inline value commands are mostly just shorthand to avoid repeating the same boilerplate half a dozen times.

Assorted inline formatting command algorithms

The effective command value of a node node for a given command is returned by the following algorithm, which will return either a string or null:

This is logically somewhat like CSS computed or resolved values, and in fact for most commands it's identical to CSS resolved values (see the end of the algorithm). We need a separate concept for some commands where we can't rely on CSS for some reason: createLink and unlink aren't CSS-related at all, backColor and hiliteColor need special treatment because background-color isn't an inherited property, subscript and superscript rely on <sub>/<sup> instead of CSS vertical-align, and strikethrough and underline don't map to unique CSS properties.

1. If neither node nor its [=tree/parent=] is an {{Element}}, return null.
2. If node is not an {{Element}}, return the effective command value of its [=tree/parent=] for command.
3. If command is "createLink" or "unlink":
   1. While node is not null, and is not an [^a^] element that has an href attribute, set node to its [=tree/parent=].
   2. If node is null, return null.
   3. Return the [=Attr/value=] of node's href attribute.
4. If command is "backColor" or "hiliteColor":
   1. While the resolved value of "background-color" on node is any fully transparent value, and node's [=tree/parent=] is an {{Element}}, set node to its [=tree/parent=].

   2. What happens if everything's background is fully transparent? See bug. If you do queryCommandValue() for backColor/hiliteColor when no backgrounds are set anywhere, so it goes up to the root element, no two engines agree. IE10PP2 just returns a random-looking number (16777215). Firefox 8.0a2 returns "transparent", Chrome 15 dev returns "rgba(0, 0, 0, 0)", and Opera 11.50 returns "rgb(255, 255, 255)".

      Opera's behavior is incorrect. The current page might be an iframe, in which case the background really will be transparent and the (inaccessible) background color of the parent page will show through. Also, the user might have changed their preferences, but I'm not too worried about that.

      So instead we just return the value as-is. This means that it will be fully transparent, which is perhaps somewhat useless information, but it's the best we can do. More generally, any non-opaque value is not going to tell you what you actually want, namely "what color is the user actually seeing?" We have no realistic way to work around this in the general case.

      Return the resolved value of "background-color" for node.

5. If command is "subscript" or "superscript":
   1. Let affected by subscript and affected by superscript be two boolean variables, both initially false.
   2. While node is an inline node:

      1. Firefox 6.0a2 ignores vertical-align for this purpose, and only cares about <sub> and <sup> tags themselves. Opera 11.11 is similar, and in fact behaves like that even for commands like bold. The spec originally followed Chrome 14 dev, mainly because WebKit itself will produce spans with vertical-align sub or super, and we want to handle them correctly. However, Ryosuke informs me that WebKit's behavior here is viewed as a bug, so I changed it to match Gecko/Opera.

         If node is a sub, set affected by subscript to true.

      2. Otherwise, if node is a sup, set affected by superscript to true.
      3. Set node to its [=tree/parent=].
   3. If affected by subscript and affected by superscript are both true, return the string "mixed".
   4. If affected by subscript is true, return "subscript".
   5. If affected by superscript is true, return "superscript".
   6. Return null.
6. If command is "strikethrough", and the "text-decoration" property of node or any of its [=tree/ancestors=] has resolved value containing "line-through", return "line-through". Otherwise, return null.
7. If command is "underline", and the "text-decoration" property of node or any of its [=tree/ancestors=] has resolved value containing "underline", return "underline". Otherwise, return null.
8. Return the resolved value for node of the relevant CSS property for command.

The specified command value of an {{Element}} element for a given command is returned by the following algorithm, which will return either a string or null:

This is logically somewhat like CSS inline style. In addition to the caveats for effective command value, we also treat elements like <b> and <font> as having the same meaning as <span>s with inline style set, because they're logically pretty much the same and can in fact be produced by the same command depending on the CSS styling flag.

1. If command is "backColor" or "hiliteColor" and the {{Element}}'s display property does not have resolved value "inline", return null.
2. If command is "createLink" or "unlink":
   1. If element is an [^a^] element and has an href attribute, return the [=Attr/value=] of that attribute.
   2. Return null.
3. If command is "subscript" or "superscript":
   1. If element is a sup, return "superscript".
   2. If element is a sub, return "subscript".
   3. Return null.
4. If command is "strikethrough", and element has a style attribute set, and that attribute sets "text-decoration":
   1. If element's style attribute sets "text-decoration" to a value containing "line-through", return "line-through".
   2. Return null.
5. If command is "strikethrough" and element is an [^s^] or [^strike^] element, return "line-through".
6. If command is "underline", and element has a style attribute set, and that attribute sets "text-decoration":
   1. If element's style attribute sets "text-decoration" to a value containing "underline", return "underline".
   2. Return null.
7. If command is "underline" and element is a [^u^] element, return "underline".
8. Let property be the relevant CSS property for command.
9. If property is null, return null.
10. If element has a style attribute set, and that attribute has the effect of setting property, return the value that it sets property to.
11. If element is a [^font^] element that has an attribute whose effect is to create a presentational hint for property, return the value that the hint sets property to. (For a size of 7, this will be the non-CSS value "xxx-large".)
12. If element is in the following list, and property is equal to the CSS property name listed for it, return the string listed for it.
    • [^b^], [^strong^]: font-weight: "bold"
    • [^i^], [^em^]: font-style: "italic"
13. Return null.

To record the values of a list of nodes node list:

When we move nodes around, we often change their parents. If their parents had any styles applied, this will make the nodes' styles change too, which often isn't what we want. For instance, if something is wrapped in <blockquote style="color: red">, and a script runs the outdent command on it, the blockquote will be removed and the style will go along with it. Recording the values of its children first, then restoring them afterward, will ensure the nodes don't change color when outdented.

1. Let values be a list of (node, command, specified command value) triples, initially empty.

2. As with removeFormat, we put subscript first so it doesn't interfere with fontSize, and omit superscript because it's redundant with subscript.

   For each node in node list, for each command in the list "subscript", "bold", "fontName", "fontSize", "foreColor", "hiliteColor", "italic", "strikethrough", and "underline" in that order:

   1. Let ancestor equal node.
   2. If ancestor is not an {{Element}}, set it to its [=tree/parent=].
   3. While ancestor is an {{Element}} and its specified command value for command is null, set it to its [=tree/parent=].
   4. If ancestor is an {{Element}}, add (node, command, ancestor's specified command value for command) to values. Otherwise add (node, command, null) to values.
3. Return values.

To restore the values specified by a list values returned by the record the values algorithm:

1. For each (node, command, value) triple in values:
   1. Let ancestor equal node.
   2. If ancestor is not an {{Element}}, set it to its [=tree/parent=].
   3. While ancestor is an {{Element}} and its specified command value for command is null, set it to its [=tree/parent=].
   4. If value is null and ancestor is an {{Element}}, push down values on node for command, with new value null.
   5. Otherwise, if ancestor is an {{Element}} and its specified command value for command is not equivalent to value, or if ancestor is not an {{Element}} and value is not null, force the value of command to value on node.

Clearing an element's value

To clear the value of an {{Element}} element:

The idea is to remove any specified command value that the element might have for the command. This might involve changing its attributes, setting its tag name, or removing it entirely while leaving its children in place. The key caller is set the selection's value, which clears the values of everything in the selection before doing anything else to keep the markup tidy.

1. Let command be the current command.
2. If element is not editable, return the empty list.

3. We want to abort early so that we don't try unsetting background-color on a non-inline element.

   If element's specified command value for command is null, return the empty list.

4. If element is a simple modifiable element:
   1. Let children be the [=tree/children=] of element.
   2. For each child in children, insert child into element's [=tree/parent=] immediately before element, preserving ranges.
   3. Remove element from its [=tree/parent=].
   4. Return children.
5. If command is "strikethrough", and element has a style attribute that sets "text-decoration" to some value containing "line-through", delete "line-through" from the value.
6. If command is "underline", and element has a style attribute that sets "text-decoration" to some value containing "underline", delete "underline" from the value.
7. If the relevant CSS property for command is not null, unset that property of element.
8. If element is a [^font^] element:
   1. If command is "foreColor", unset element's color attribute, if set.
   2. If command is "fontName", unset element's face attribute, if set.
   3. If command is "fontSize", unset element's size attribute, if set.
9. If element is an [^a^] element and command is "createLink" or "unlink", unset the href property of element.

10. If we get past this step, we're something like <b class=foo> where we want to keep the extra attributes, so we stick them on a span.

    If element's specified command value for command is null, return the empty list.

11. Set the tag name of element to "span", and return the one-node list consisting of the result.

Pushing down values

<u>foo<font color=red>[bar]baz</font></u>
-> <u>foo</u><font color=red>bar<u>baz</u></font> (spec)
-> <u>foo</u><font color=red>bar</font><u><font color=red>baz</font></u> (Gecko)

To push down values to a node node, given a new value new value:

The idea here is that if an undesired value is being propagated from an ancestor, we remove that style from the ancestor and re-apply it to all the descendants other than node. This way we don't have to have nested styles, which is usually more cluttered (although not always).

1. Let command be the current command.

2. E.g., a text node child of a document fragment.

   If node's [=tree/parent=] is not an {{Element}}, abort this algorithm.

3. If the effective command value of command is loosely equivalent to new value on node, abort this algorithm.
4. Let current ancestor be node's [=tree/parent=].
5. Let ancestor list be a list of nodes, initially empty.
6. While current ancestor is an editable {{Element}} and the effective command value of command is not loosely equivalent to new value on it, append current ancestor to ancestor list, then set current ancestor to its [=tree/parent=].
7. If ancestor list is empty, abort this algorithm.
8. Let propagated value be the specified command value of command on the last member of ancestor list.

9. We can only remove specified values, so if the value isn't specified, give up. Unless we're actually trying to push down a null specified value, like for unlink.

   If propagated value is null and is not equal to new value, abort this algorithm.

10. If we go all the way up to the root and still don't have the desired value, pushing down values is pointless. It will create extra markup for no purpose. Except if the value is null, which basically just means "try to get rid of anything affecting the current element but don't aim for any specific value".

    Nevertheless, Chrome 14 dev does seem to do this. Running bold on <span style=font-weight:300>f[o]o</span> breaks up the span and adds a <b> as a sibling. In IE9, Firefox 6.0a2, and Opera 11.50, it instead nests the <b> inside the <span>. It's a tradeoff: WebKit's behavior is better for things like

    <font color=red>fo[o</font><font color=blue>b]ar</font>
    -> <font color=red>fo</font><font color=green>[ob]</font><font color=blue>ar</font>
    

    (where the spec adds two extra font tags instead of one), but the spec is simpler for things like

    <font color=red>f[o]o</font>
    -> <font color=red>f<font color=green>[o]</font>o</font>
    

    (where WebKit splits the existing tag up in addition to creating a new tag). I'm not particularly sure which approach is better overall, so I'll go with the majority of browsers. If these algorithms move to use runs of consecutive siblings instead of doing everything node-by-node, it might make sense to break up the parent as long as it won't create an extra node (i.e., we're styling something that includes the first or last child).

    If the effective command value of command is not loosely equivalent to new value on the [=tree/parent=] of the last member of ancestor list, and new value is not null, abort this algorithm.

11. While ancestor list is not empty:
    1. Let current ancestor be the last member of ancestor list.
    2. Remove the last member from ancestor list.
    3. If the specified command value of current ancestor for command is not null, set propagated value to that value.
    4. Let children be the [=tree/children=] of current ancestor.
    5. If the