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 specified command value of current ancestor for command is not null, clear the value of current ancestor.
    6. For every child in children:
       1. If child is node, continue with the next child.

       2. TODO: This will be incorrect for relative font sizes. If the font size on the parent was removed and the font size on the child is in ems or percents or something, it will now change value. This isn't likely to come up, so we'll ignore it for now.

          If child is an {{Element}} whose specified command value for command is neither null nor equivalent to propagated value, continue with the next child.

       3. If child is the last member of ancestor list, continue with the next child.
       4. Force the value of child, with command as in this algorithm and new value equal to propagated value.

Forcing the value of a node

To force the value of a node node to new value:

This algorithm checks if the node has the desired value, and if not, it wraps the node (or, if that's not possible, its descendants) in a simple modifiable element. After forcing the value, descendants might still have a different value.

1. Let command be the current command.
2. If node's [=tree/parent=] is null, abort this algorithm.
3. If new value is null, abort this algorithm.
4. If node is an allowed child of "span":

   1. Even if the value matches, we stick it in a preceding sibling if possible. This ensures "a<cite>b</cite>c" -> "<i>a<cite>b</cite>c</i>" instead of "<i>a</i><cite>b</cite><i>c</i>". While we're at it, we also handle more elaborate cases like <b>foo</b>[bar]<b>baz</b> and even <i><b>foo</b></i>[bar]<i><b>baz</b></i> (the latter becomes <b><i>foo</i>bar<i>baz</i></b>).

      Theoretically this algorithm could pointlessly reorganize the DOM in the event of unreasonable style rules, but it's not a big enough deal for us to care, since the resulting style will still be right.

      Reorder modifiable descendants of node's {{Node/ previousSibling}}.

   2. Reorder modifiable descendants of node's {{Node/nextSibling}}.

   3. The new parent instructions we'd want are too complicated to reasonably feed into the wrap algorithm, so we just let them return null and do the wrapping ourselves if sibling criteria didn't return true.

      Wrap the one-node list consisting of node, with sibling criteria returning true for a simple modifiable element whose specified command value is equivalent to new value and whose effective command value is loosely equivalent to new value and false otherwise, and with new parent instructions returning null.

5. Bug 13996.

   If node is invisible, abort this algorithm.

6. If the effective command value of command is loosely equivalent to new value on node, abort this algorithm.
7. If node is not an allowed child of "span":
   1. Let children be all [=tree/children=] of node, omitting any that are {{Element}}s whose specified command value for command is neither null nor equivalent to new value.

   2. This means that if it has no children, we do nothing. IE9 inserts an empty wrapper element in that case, but I'm not sure what the point is, and no one else does, so I don't. WebKit seems to ignore the node if its only child consists solely of whitespace, but I don't see any grounds for that and no one else does, so I don't.

      Force the value of each node in children, with command and new value as in this invocation of the algorithm.

   3. Abort this algorithm.
8. If the effective command value of command is loosely equivalent to new value on node, abort this algorithm.
9. Let new parent be null.
10. If the CSS styling flag is false:
    1. If command is "bold" and new value is "bold", let new parent be the result of calling createElement("b") on the {{Node/ownerDocument}} of node.
    2. If command is "italic" and new value is "italic", let new parent be the result of calling createElement("i") on the {{Node/ownerDocument}} of node.

    3. TODO: Actual UAs use strike, not s, but s is shorter and HTML5 makes strike invalid. I've gone with s for now, but maybe we want to change the spec to require strike.

       If command is "strikethrough" and new value is "line-through", let new parent be the result of calling createElement("s") on the {{Node/ ownerDocument}} of node.

    4. If command is "underline" and new value is "underline", let new parent be the result of calling createElement("u") on the {{Node/ownerDocument}} of node.

    5. See comment for foreColor for discussion. TODO: Define more carefully what happens when things are out of range or not integers or whatever.

       If command is "foreColor", and new value is fully opaque with red, green, and blue components in the range 0 to 255:

       1. Let new parent be the result of calling createElement("font") on the {{Node/ ownerDocument}} of node.
       2. Set the color attribute of new parent to the result of applying the rules for serializing simple color values to new value (interpreted as a simple color).
    6. If command is "fontName", let new parent be the result of calling createElement("font") on the {{Node/ownerDocument}} of node, then set the face attribute of new parent to new value.
11. If command is "createLink" or "unlink":
    1. Let new parent be the result of calling createElement("a") on the {{Node/ownerDocument}} of node.
    2. Set the href attribute of new parent to new value.

    3. Nested a elements are bad, because they can't be serialized to text/html. hrefs should already have been cleared in a previous step, but we might have <a name> or such lurking about.

       Let ancestor be node's [=tree/parent=].

    4. While ancestor is not null:

       1. TODO: This will mean any link-specific attributes will be transferred, which makes them both invalid and useless. Is that okay? I don't really want to list them all, because that sort of list is prone to bitrot.

          If ancestor is an [^a^], set the tag name of ancestor to "span", and let ancestor be the result.

       2. Set ancestor to its [=tree/parent=].

12. WebKit is the only engine that ever outputs anything but font tags for fontSize. For size=7, it uses font-size: -webkit-xxx-large. We just output a font tag no matter what for size=7.

    If command is "fontSize"; and new value is one of "x-small", "small", "medium", "large", "x-large", "xx-large", or "xxx-large"; and either the CSS styling flag is false, or new value is "xxx-large": let new parent be the result of calling createElement("font") on the {{Node/ownerDocument}} of node, then set the size attribute of new parent to the number from the following table based on new value:

    • x-small: 1
    • small: 2
    • normal: 3
    • large: 4
    • x-large: 5
    • xx-large: 6
    • xxx-large: 7

13. We always use sup/sub elements, even in CSS mode, following Gecko and contradicting WebKit. This is because <span value="vertical-align: sub/super">, the obvious equivalent (and what WebKit uses), behaves quite differently: it doesn't reduce font-size, which is ugly. WebKit's behavior is a bug anyway.

    If command is "subscript" or "superscript" and new value is "subscript", let new parent be the result of calling createElement("sub") on the {{Node/ownerDocument}} of node.

14. If command is "subscript" or "superscript" and new value is "superscript", let new parent be the result of calling createElement("sup") on the {{Node/ownerDocument}} of node.
15. If new parent is null, let new parent be the result of calling createElement("span") on the {{Node/ownerDocument}} of node.

16. This preserves boundary points correctly, as usual.

    Insert new parent in node's [=tree/parent=] before node.

17. If the effective command value of command for new parent is not loosely equivalent to new value, and the relevant CSS property for command is not null, set that CSS property of new parent to new value (if the new value would be valid).

    Need to be explicit. I think "if the new value would be valid" means "if the new value isn't xxx-large for font-size", need to double-check.

18. If command is "strikethrough", and new value is "line-through", and the effective command value of "strikethrough" for new parent is not "line-through", set the "text-decoration" property of new parent to "line-through".
19. If command is "underline", and new value is "underline", and the effective command value of "underline" for new parent is not "underline", set the "text-decoration" property of new parent to "underline".
20. Append node to new parent as its last [=tree/child=], preserving ranges.
21. If node is an {{Element}} and the effective command value of command for node is not loosely equivalent to new value:
    1. Insert node into the [=tree/parent=] of new parent before new parent, preserving ranges.
    2. Remove new parent from its [=tree/parent=].
    3. Let children be all [=tree/children=] of node, omitting any that are {{Element}}s whose specified command value for command is neither null nor equivalent to new value.
    4. Force the value of each node in children, with command and new value as in this invocation of the algorithm.

To reorder modifiable descendants of a node node, given a command command and a value new value:

1. Let candidate equal node.
2. While candidate is a modifiable element, and candidate has exactly one [=tree/child=], and that [=tree/child=] is also a modifiable element, and candidate is not a simple modifiable element or candidate's specified command value for command is not equivalent to new value, set candidate to its [=tree/child=].
3. If candidate is node, or is not a simple modifiable element, or its specified command value is not equivalent to new value, or its effective command value is not loosely equivalent to new value, abort these steps.
4. While candidate has [=tree/children=], insert the first [=tree/child=] of candidate into candidate's [=tree/parent=] immediately before candidate, preserving ranges.

5. If candidate had no children, any boundary point inside it will get moved to its parent here, which is okay. We don't want to preserve ranges, because that would move boundary points that originally were in candidate but were moved to its parent by the last step to move to node's parent.

   We move to after node so that boundary points before and after node wind up consistently inside candidate when we move preserving ranges. If we had

   {<node>foo<candidate></candidate></node>}
   

   it thus becomes

   {<node>foo</node>}<candidate></candidate>
   

   by the range mutation rules, and then when we move preserving ranges, it becomes

   <candidate>{<node>foo</node>}</candidate>
   

   which is reasonable.

   If we had inserted candidate before node, instead it would go

   {<candidate></candidate><node>foo</node>}
   {<candidate><node>foo</node>}</candidate>
   

   because of the interaction of regular range mutation rules with preserving-ranges rules.

   Insert candidate into node's [=tree/parent=] immediately after node.

6. Append the node as the last [=tree/child=] of candidate, preserving ranges.

Setting the selection's value

To set the selection's value to new value:

foo bar baz,

foo bar baz.

foo bar baz,

1. Let command be the current command.

2. IE9 seems to wrap the whole line instead, or something like that, although it does nothing for createLink. We follow all other browsers' general behavior: change the state/value, and then make sure that takes effect if the user types something before changing the cursor position.

   If there is no formattable node effectively contained in the active range:

   1. If command has inline command activated values, set the state override to true if new value is among them and false if it's not.
   2. If command is "subscript", unset the state override for "superscript".
   3. If command is "superscript", unset the state override for "subscript".
   4. If new value is null, unset the value override (if any).
   5. Otherwise, if command is "createLink" or it has a value specified, set the value override to new value.
   6. Abort these steps.

3. The last sentence here just prettifies the resulting range a bit.

   If the active range's [=range/start node=] is an editable {{Text}} node, and its [=range/start offset=] is neither zero nor its [=range/start node=]'s [=Node/length=], call splitText() on the active range's [=range/start node=], with argument equal to the active range's [=range/start offset=]. Then set the active range's [=range/start node=] to the result, and its [=range/start offset=] to zero.

4. If the active range's [=range/end node=] is an editable {{Text}} node, and its [=range/end offset=] is neither zero nor its [=range/end node=]'s [=Node/length=], call splitText() on the active range's [=range/end node=], with argument equal to the active range's [=range/end offset=].
5. Let element list be all editable {{Element}}s effectively contained in the active range.
6. For each element in element list, clear the value of element.

7. We skip non-editable nodes.

   IE9

   Allows everything to be modified by execCommand(), regardless of whether it's editable.

   Firefox 4.0

   Ignores execCommand() if the start and end of the selection are not both editable. If the start and end are editable but something in the middle is not, seems to relocate the non-editable part in the middle or something like that.

   Chrome 12 dev

   Ignores execCommand() if the start and end of the selection are not both editable. If the start and end are editable but something in the middle is not, applies the given command but skips the non-editable parts. But the state doesn't ignore the non-editable parts, so if you bold such a selection you can't unbold it, for instance, since the middle part will remain bold (so it will keep on trying to bold it instead of switching to unbold).

   Opera 11.00

   Ignores execCommand() if the start and end of the selection are not both editable. If the start and end are editable but something in the middle is not, applies the command to everything, even the non-editable part.

   I chose to go with the non-IE behavior, per discussion. Ignoring non-editable things is convenient for the common use-case of an editor, where you don't want the user to bold random parts of the UI when they hit the bold button. For cases where it's not desired, you can always turn designMode on briefly before using execCommand(), so the non-IE behavior is a lot easier to work around than the IE behavior.

   I don't see the value in ever just ignoring execCommand(). If the start and end are not editable, I'm going to say you should still style any editable nodes in between. I'm also going to ignore non-editable nodes for the purposes of determining state, so (for instance) if all the editable nodes are bolded, it will unbold instead of bolding.

   Let node list be all editable nodes effectively contained in the active range.

8. TODO: This is inefficient. It would be most efficient to only push down values on the highest-level effectively contained nodes, and to batch operations so we handle runs of adjacent siblings at once. Should we bother fixing this?

   For each node in node list:

   1. Push down values on node.

   2. If the node isn't an allowed child of "span", forcing its value will just force its children's value, which is redundant. So don't.

      If node is an allowed child of "span", force the value of node.

The backColor command

This command must not be enabled if the editing host is in the plaintext-only state.

For historical reasons, backColor and hiliteColor behave identically.

Action:

1. If value is not a valid CSS color, prepend "#" to it.
2. If value is still not a valid CSS color, or if it is currentColor, return false.
3. Set the selection's value to value.
4. Return true.

Standard inline value command

Relevant CSS property: "background-color"

Equivalent values: Either both strings are valid CSS colors and have the same red, green, blue, and alpha components, or neither string is a valid CSS color.

The bold command

This command must not be enabled if the editing host is in the plaintext-only state.

If the selection is collapsed (but not if it contains nothing but is not collapsed), IE9 wraps the whole line in a <strong>. This seems bizarre and no one else does it, so I don't do it. It's a similar story for similar commands (fontName, italic, etc.). Except not for strikethrough, where it just does nothing if the selection is empty. Why strikethrough? I don't know.

Action: If queryCommandState("bold") returns true, set the selection's value to "normal". Otherwise set the selection's value to "bold". Either way, return true.

Inline command activated values: "bold", "600", "700", "800", or "900"

Relevant CSS property: "font-weight"

Equivalent values: Either the two strings are equal, or one is "bold" and the other is "700", or one is "normal" and the other is "400".

The createLink command

This command must not be enabled if the editing host is in the plaintext-only state.

Action:

1. Firefox 4b11 and Chrome 11 dev both silently do nothing in this case. IE 9 RC and Opera 11 both treat the request literally. Gecko and WebKit probably have it right here: users who enter no URL are very unlikely to want to link to a relative URL resolving to the current document. If they really want to, they can always specify "#" for the value, or the author can rewrite it, so it's not like this makes the API less useful.

   If value is the empty string, return false.

2. There are three approaches here. For instance, if you ask browsers to create a link to "http://example.org" on the "b" here:

   <a href=http://example.com><b>Abc</b></a>
   

   Chrome 10 dev produces:

   <b><a href=http://example.com>A</a><a href=http://example.org>b</a><a href=http://example.com>c</a></b>
   

   Firefox 4b11 produces (roughly):

   <a href=http://example.com><b>A<a href=http://example.org>b</a>c</b></a>
   

   (This doesn't round-trip through text/html serialization.) IE 9 RC and Opera 11 produce simply:

   <a href=http://example.org><b>Abc</b></a>
   

   The last behavior probably best matches user expectations. If you happen to miss out a character when selecting the link you want to change, do you really intend to only change the link of part of it?

   For each editable [^a^] element that has an href attribute and is an [=tree/ancestor=] of some node effectively contained in the active range, set that [^a^] element's href attribute to value.

3. Set the selection's value to value.
4. Return true.

The fontName command

This command must not be enabled if the editing host is in the plaintext-only state.

Action: Set the selection's value to value, then return true.

Standard inline value command

Relevant CSS property: "font-family"

The fontSize command

This command must not be enabled if the editing host is in the plaintext-only state.

Action:

1. Strip leading and trailing whitespace from value.
2. If value is not a valid floating point number, and would not be a valid floating point number if a single leading "+" character were stripped, return false.
3. If the first character of value is "+", delete the character and let mode be "relative-plus".
4. Otherwise, if the first character of value is "-", delete the character and let mode be "relative-minus".
5. Otherwise, let mode be "absolute".
6. Apply the rules for parsing non-negative integers to value, and let number be the result.
7. If mode is "relative-plus", add three to number.
8. If mode is "relative-minus", negate number, then add three to it.
9. If number is less than one, let number equal 1.
10. If number is greater than seven, let number equal 7.
11. Set value to the string here corresponding to number:

    The entry for 7 here is an issue: there's no CSS value that corresponds to it. Even if we got one added to the drafts, it wouldn't be backward-compatible to use it. WebKit is the only engine that supports CSS output for fontSize, and it uses -webkit-xxx-large in this case, which is unworkable. Instead, we just always output a font tag for size 7. If authors want conforming markup, they'll need to give CSS sizes above size 7, not legacy sizes.

    • 1: x-small
    • 2: small
    • 3: medium
    • 4: large
    • 5: x-large
    • 6: xx-large
    • 7: xxx-large
12. Set the selection's value to value.
13. Return true.

This follows Firefox 6.0a2. Chrome 14 dev always returns false. Note that indeterminacy here keys off the effective command value, while the value is based only on an approximation (a number from one to seven). Thus it's possible for every subrange of the selection to have the same value, but for the selection to still be indeterminate. Setting the fontSize to the value will make it determinate without changing anything's value.

Indeterminate: True if among formattable nodes that are effectively contained in the active range, there are two that have distinct effective command values. Otherwise false.

Value:

1. If the active range is null, return the empty string.

2. See comment for standard inline value commands on how I decided on this choice of node.

   Let pixel size be 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=], in either case interpreted as a number of pixels.

3. Return the legacy font size for pixel size.

Relevant CSS property: "font-size"

The legacy font size for an integer pixel size is returned by the following algorithm:

1. Let returned size be 1.
2. While returned size is less than 7:
   1. Let lower bound be the resolved value of "font-size" in pixels of a [^font^] element whose size attribute is set to returned size.
   2. Let upper bound be the resolved value of "font-size" in pixels of a [^font^] element whose size attribute is set to one plus returned size.
   3. Let average be the average of upper bound and lower bound.
   4. If pixel size is less than average, return the one-code unit string consisting of the digit returned size.
   5. Add one to returned size.
3. Return "7".

The foreColor command

This command must not be enabled if the editing host is in the plaintext-only state.

                        IE10PP2       Firefox 7.0a2            Chrome 14 dev            Opera 11.50
blue                    blue          blue                     #0000ff                  #0000ff
f                       #f            -                        -                        #f00000
#f                      #f            -                        -                        #f00000
00f                     #00f          -                        #0000ff                  #00000f
#00f                    #00f          rgb(0, 0, 255)           #0000ff                  #00000f
0000ff                  #0000ff       -                        #0000ff                  #0000ff
#0000ff                 #0000ff       rgb(0, 0, 255)           #0000ff                  #0000ff
000000fff               #0000ff       -                        -                        -
#000000fff              #0000ff       -                        -                        -
rgb(0, 0, 255)          rgb(0,0,255)  rgb(0, 0, 255)           #0000ff                  #00b000
rgb(0%, 0%, 100%)       rgb(0,0,255)  rgb(0, 0, 255)           #0000ff                  #00b000
rgb( 0 ,0 ,255)         rgb(0,0,255)  rgb(0, 0, 255)           #0000ff                  #00b000
rgba(0, 0, 255, 0.0)    #ba0000       rgba(0, 0, 255, 0)       rgba(0, 0, 255, 0)       #00ba00
rgb(15, -10, 375)       rgb(15,0,255) rgb(15, 0, 255)          #0f00ff                  #00b015
rgba(0, 0, 0, 1)        #ba0010       rgb(0, 0, 0)             -                        #00ba00
rgba(255, 255, 255, 1)  #000055       rgb(255, 255, 255)       #ffffff                  #00ba02
rgba(0, 0, 255, 0.5)    #ba0000       rgba(0, 0, 255, 0.5)     rgba(0, 0, 255, 0.5)     #00ba00
hsl(240, 100%, 50%)     #000150       rgb(0, 0, 255)           #0000ff                  #000024
cornsilk                cornsilk      cornsilk                 #fff8dc                  #fff8dc
potato quiche           #0000c0       -                        -                        #000a00
transparent             transparent   -                        rgba(0, 0, 0, 0)         #00a000
currentColor            #c0e000       currentcolor             rgba(0, 0, 0, 0)         #c000e0

Action:

1. TODO: Define "valid CSS color" (here and in other color places).

   If value is not a valid CSS color, prepend "#" to it.

2. currentColor is bad for the same reason as relative font sizes. It will confuse the algorithm, and doesn't seem very useful anyway.

   If value is still not a valid CSS color, or if it is currentColor, return false.

3. Set the selection's value to value.
4. Return true.

Standard inline value command

Relevant CSS property: "color"

Equivalent values: Either both strings are valid CSS colors and have the same red, green, blue, and alpha components, or neither string is a valid CSS color.

The hiliteColor command

This command must not be enabled if the editing host is in the plaintext-only state.

For historical reasons, backColor and hiliteColor behave identically.

Action:

1. If value is not a valid CSS color, prepend "#" to it.

2. currentColor is bad for the same reason as relative font sizes. It will confuse the algorithm, and doesn't seem very useful anyway. For hiliteColor you could conceive of it being useful, but it will still confuse the algorithm, so ban it for now anyway.

   If value is still not a valid CSS color, or if it is currentColor, return false.

3. Set the selection's value to value.
4. Return true.

For indeterminacy, this follows no one. Firefox 6.0a2 and Chrome 14 dev both always return false. However, the spec makes sense, since it's consistent with other commands.

Standard inline value command

Relevant CSS property: "background-color"

Equivalent values: Either both strings are valid CSS colors and have the same red, green, blue, and alpha components, or neither string is a valid CSS color.

The italic command

This command must not be enabled if the editing host is in the plaintext-only state.

Action: If queryCommandState("italic") returns true, set the selection's value to "normal". Otherwise set the selection's value to "italic". Either way, return true.

Inline command activated values: "italic" or "oblique"

Relevant CSS property: "font-style"

The removeFormat command

This command must not be enabled if the editing host is in the plaintext-only state.

A removeFormat candidate is an editable HTML element with [=Element/local name=] "abbr", "acronym", "b", "bdi", "bdo", "big", "blink", "cite", "code", "dfn", "em", "font", "i", "ins", "kbd", "mark", "nobr", "q", "s", "samp", "small", "span", "strike", "strong", "sub", "sup", "tt", "u", or "var".

Action:

1. Let elements to remove be a list of every removeFormat candidate effectively contained in the active range.
2. For each element in elements to remove:
   1. While element has [=tree/children=], insert the first [=tree/child=] of element into the [=tree/parent=] of element immediately before element, preserving ranges.
   2. Remove element from its [=tree/parent=].

3. The last sentence just prettifies the resulting range a bit.

   If the active range's [=range/start node=] is an editable {{Text}} node, and its [=range/start offset=] is neither zero nor its [=range/start node=]'s [=Node/length=], call splitText() on the active range's [=range/start node=], with argument equal to the active range's [=range/start offset=]. Then set the active range's [=range/start node=] to the result, and its [=range/start offset=] to zero.

4. If the active range's [=range/end node=] is an editable {{Text}} node, and its [=range/end offset=] is neither zero nor its [=range/end node=]'s [=Node/length=], call splitText() on the active range's [=range/end node=], with argument equal to the active range's [=range/end offset=].
5. Let node list consist of all editable nodes effectively contained in the active range.

6. TODO: Splitting the parent is really a block algorithm. It's not clear whether it's desirable to use for inline nodes. Perhaps it's okay, but it makes me a little uneasy.

   For each node in node list, while node's [=tree/parent=] is a removeFormat candidate in the same editing host as node, split the parent of the one-node list consisting of node.

7. This step is for cases like <p style=font-weight:bold>foo[bar]baz</p>, where splitting/removing tags won't help. We don't need to run superscript, since subscript does the same thing here. We run subscript first so <sub>/<sup> won't upset fontSize.

   For each of the entries in the following list, in the given order, set the selection's value to null, with command as given.

   1. subscript
   2. bold
   3. fontName
   4. fontSize
   5. foreColor
   6. hiliteColor
   7. italic
   8. strikethrough
   9. underline
8. Return true.

The strikethrough command

This command must not be enabled if the editing host is in the plaintext-only state.

TODO: See underline TODO.

Action: If queryCommandState("strikethrough") returns true, set the selection's value to null. Otherwise set the selection's value to "line-through". Either way, return true.

Inline command activated values: "line-through"

The subscript command

This command must not be enabled if the editing host is in the plaintext-only state.

Action:

1. Call queryCommandState("subscript"), and let state be the result.
2. Set the selection's value to null.
3. If state is false, set the selection's value to "subscript".
4. Return true.

Indeterminate: True if either among formattable nodes that are effectively contained in the active range, there is at least one with effective command value "subscript" and at least one with some other effective command value; or if there is some formattable node effectively contained in the active range with effective command value "mixed". Otherwise false.

For ^_foo, Firefox 6.0a2 and Opera 11.11 say the state is true for both superscript and subscript, and indeterminate is false; Chrome 14 dev says it's true for subscript but not superscript, and indeterminate is false. We follow neither of these behaviors: we return false for both states, and say indeterminate is true. The reason is because we want to return true for a state if we'll do nothing, false if we'll do something; and if we have nesting like this, we'll always do something, namely get rid of all those ancestors and replace them with a single tag. This matches what happens in other indeterminate situations, so it's fair to consider it indeterminate.

Inline command activated values: "subscript"

The superscript command

This command must not be enabled if the editing host is in the plaintext-only state.

Action:

1. Call queryCommandState("superscript"), and let state be the result.
2. Set the selection's value to null.
3. If state is false, set the selection's value to "superscript".
4. Return true.

Indeterminate: True if either among formattable nodes that are effectively contained in the active range, there is at least one with effective command value "superscript" and at least one with some other effective command value; or if there is some formattable node