GeezerVison

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 [=range/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 effectively contained in the active range with effective command value "mixed". Otherwise false.

Inline command activated values: "superscript"

The underline command

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

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

Inline command activated values: "underline"

The unlink command

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

Action:

1. Let hyperlinks be a list of every [^a^] element that has an href attribute and is contained in the active range or is an [=tree/ancestor=] of one of its [=boundary points=].
2. Clear the value of each member of hyperlinks.
3. Return true.

Block formatting command definitions

An indentation element is either a [^blockquote^], or a [^div^] that has a style attribute that sets "margin" or some subproperty of it.

We need to allow stuff that sets border/padding because WebKit (Chrome 12 dev) sets "border: none; padding: 0px" when indenting. We need to allow stuff that sets classes because WebKit sets class="webkit-indent-blockquote". We need to allow stuff that sets dir because IE9 does. The criteria could probably be tightened up a bit to reduce false positives, but it'll do for now.

A simple indentation element is an indentation element that has no attributes except possibly

• a style attribute that sets no properties other than "margin", "border", "padding", or subproperties of those; and/or
• a dir attribute.

The notions of indentation element and simple indentation element parallel those of modifiable element and simple modifiable element.

listing and xmp are included because otherwise insertParagraph inside them won't work, since paragraphs aren't an allowed child.

A non-list single-line container is an HTML element with [=Element/local name=] "address", "div", "h1", "h2", "h3", "h4", "h5", "h6", "listing", "p", "pre", or "xmp".

A single-line container is either a non-list single-line container, or an HTML element with [=Element/local name=] "li", "dt", or "dd".

The block node of a node node is either a block node or null, as returned by the following algorithm:

1. While node is an inline node, set node to its [=tree/parent=].
2. Return node.

Bug 14062. See also Mozilla bug 590640, specifically comments 48 and on.

If a command preserves overrides, then before taking its action, the user agent must record current overrides. After taking the action, if the active range is [=range/collapsed=], it must restore states and values from the recorded list.

All block commands preserve overrides except the insertText command, which treats overrides specially.

Assorted block formatting command algorithms

TODO: When breaking a non-inline element out of an inline element, like p in b or whatever, it would make sense to re-wrap the contents in the inline tag.

To fix disallowed ancestors of node:

We often run this algorithm after we move a node someplace, just in case it wound up somewhere it's not supposed to be. This avoids things like unserializable DOMs, blocks nested inside inlines, etc.

1. If node is not editable, abort these steps.

2. This case is really intended to handle stuff like list items or table cells that wander outside their proper place. We generally convert them into [^p^]s.

   If node is not an allowed child of any of its [=tree/ancestors=] in the same editing host:

   1. If node is a [^dd^] or [^dt^], wrap the one-node list consisting of node, with sibling criteria returning true for any [^dl^] with no attributes and false otherwise, and new parent instructions returning the result of calling createElement("dl") on the context object. Then abort these steps.

   2. There's no reason to change the node to a paragraph if that won't make it an allowed child anyway.

      If "p" is not an allowed child of the editing host of node, abort these steps.

   3. If node is not a prohibited paragraph child, abort these steps.
   4. Set the tag name of node to the default single-line container name, and let node be the result.

   5. Because maybe it somehow wound up as the child of a p, like via insertHTML.

      Fix disallowed ancestors of node.

   6. Let children be node's [=tree/children=].
   7. For each child in children, if child is a prohibited paragraph child:
      1. Record the values of the one-node list consisting of child, and let values be the result.
      2. Split the parent of the one-node list consisting of child.
      3. Restore the values from values.
   8. Abort these steps.
3. Record the values of the one-node list consisting of node, and let values be the result.
4. While node is not an allowed child of its [=tree/parent=], split the parent of the one-node list consisting of node.
5. Restore the values from values.

<li>foo<ol>...</ol>bar</li>

<li>foo</li><ol>...</ol><li>bar</li>

<ol><li>[foo<ol><li>bar]</ol>baz</ol>

<p>[foo<ol><li>bar]<li>baz</ol>

To normalize sublists in a node item:

1. If item is not an [^li^] or it is not editable or its [=tree/parent=] is not editable, abort these steps.
2. Let new item be null.
3. While item has an [^ol^] or [^ul^] [=tree/child=]:
   1. Let child be the last [=tree/child=] of item.
   2. If child is an [^ol^] or [^ul^], or new item is null and child is a {{Text}} node whose {{CharacterData/ data}} consists of zero of more space characters:
      1. Set new item to null.
      2. Insert child into the [=tree/parent=] of item immediately following item, preserving ranges.
   3. Otherwise:
      1. If new item is null, let new item be the result of calling createElement("li") on the {{Node/ ownerDocument}} of item, then insert new item into the [=tree/parent=] of item immediately after item.
      2. Insert child into new item as its first [=tree/child=], preserving ranges.

The selection's list state is returned by the following algorithm:

1. If the active range is null, return "none".
2. Block-extend the active range, and let new range be the result.
3. Let node list be a list of nodes, initially empty.
4. For each node contained in new range, append node to node list if the last member of node list (if any) is not an [=tree/ancestor=] of node; node is editable; node is not an indentation element; and node is either an [^ol^] or [^ul^], or the [=tree/child=] of an [^ol^] or [^ul^], or an allowed child of "li".
5. If node list is empty, return "none".

6. The child-of-child case is necessary right now because of the following:

   <ol><li>[foo<ol><li>bar]</ol>baz</ol>
   

   With the current (July 2011) block-extend algorithm, this will become:

   {<ol><li>foo<ol><li>bar</ol>}baz</ol>
   

   because of the magical li handling in block-extend. We want this to register as ol, because after normalizing sublists it will become

   {<ol><li>foo</li><ol><li>bar</ol>}<li>baz</ol>
   

   But the text node "foo" will wind up in node list, and is not the child of an ol. This is all very messy and has to do with questionable decisions about how to handle nested lists.

   If every member of node list is either an [^ol^] or the [=tree/child=] of an [^ol^] or the [=tree/child=] of an [^li^] [=tree/child=] of an [^ol^], and none is a [^ul^] or an [=tree/ancestor=] of a [^ul^], return "ol".

7. This condition and the last are mutually exclusive, so the order is actually irrelevant. Clearly they could only both hold if no member of node list is an ol or ul, so if they both held, every member would have to be either the child of an ol and of a ul, or of an ol and an li, or a ul and an li, or of an li that's the child of both an ol and a ul. This is impossible unless the list is empty, in which case we already aborted.

   If every member of node list is either a [^ul^] or the [=tree/child=] of a [^ul^] or the [=tree/child=] of an [^li^] [=tree/child=] of a [^ul^], and none is an [^ol^] or an [=tree/ancestor=] of an [^ol^], return "ul".

8. If some member of node list is either an [^ol^] or the [=tree/child=] or [=tree/ancestor=] of an [^ol^] or the [=tree/child=] of an [^li^] [=tree/child=] of an [^ol^], and some member of node list is either a [^ul^] or the [=tree/child=] or [=tree/ancestor=] of a [^ul^] or the [=tree/child=] of an [^li^] [=tree/child=] of a [^ul^], return "mixed".
9. If some member of node list is either an [^ol^] or the [=tree/child=] or [=tree/ancestor=] of an [^ol^] or the [=tree/child=] of an [^li^] [=tree/child=] of an [^ol^], return "mixed ol".
10. If some member of node list is either a [^ul^] or the [=tree/child=] or [=tree/ancestor=] of a [^ul^] or the [=tree/child=] of an [^li^] [=tree/child=] of a [^ul^], return "mixed ul".
11. Return "none".

The alignment value of a node node is returned by the following algorithm:

This is basically like the resolved value of text-align, but with two key differences. First, it only ever evaluates to center/justify/left/right, since that's the model that the justify commands work with. Second, it ignores inline elements, because text-align has no effect on them and their alignment is actually governed by their nearest block ancestor (if any).

1. While node is neither null nor an {{Element}}, or it is an {{Element}} but its "display" property has resolved value "inline" or "none", set node to its [=tree/parent=].

2. This means there's no applicable style rule, so probably it will wind up left-aligned. Of course this ignores the fact that the alignment will really be "start", so this is wrong for RTL, but it's a pretty marginal corner case anyway. (It will only happen if, e.g., everything up to and including the html and body elements have display: inline or none.)

   If node is not an {{Element}}, return "left".

3. If node's "text-align" property has resolved value "start", return "left" if the directionality of node is "ltr", "right" if it is "rtl".
4. If node's "text-align" property has resolved value "end", return "right" if the directionality of node is "ltr", "left" if it is "rtl".
5. If node's "text-align" property has resolved value "center", "justify", "left", or "right", return that value.
6. Return "left".

Sometimes one location corresponds to multiple distinct boundary points. For instance, in the DOM <p>Hello</p>, a boundary point might lie at the beginning of the text node or the beginning of the element node, but these don't logically differ much and will appear the same to the user, so we often want to treat them the same. The algorithms here allow navigating through such equivalent boundary points, for when we want to make the selection as inclusive or exclusive as possible. For deletion, we want to delete as few nodes as possible, so we move the start node forward and the end node backward. In other cases we might do the reverse, expanding the selection. In still other cases we might want to move forward or backward to try getting to a text node.

Given a [=boundary point=] (node, offset), the next equivalent point is either a [=boundary point=] or null, as returned by the following algorithm:

1. If node's [=Node/length=] is zero, return null.
2. We don't want to move into or out of zero-length nodes, because that would move us straight through them. For instance, if {}<span></span> were equivalent to <span>{}</span>, it would also be equivalent to <span></span>{}. This produces very unexpected results for nodes like <br>.
3. If offset is node's [=Node/length=], and node's [=tree/parent=] is not null, and node is an inline node, return (node's [=tree/parent=], 1 + node's [=tree/index=]).
4. For instance, <span>foo[]</span> is equivalent to <span>foo{}</span>, which is equivalent to <span>foo</span>{}. However, <p>foo{}</p> is not equivalent to <p>foo</p>{} – the cursor might look like it's in a visibly different position.
5. If node has a [=tree/child=] with [=tree/index=] offset, and that [=tree/child=]'s [=Node/length=] is not zero, and that [=tree/child=] is an inline node, return (that [=tree/child=], 0).
6. For instance, {}<span>foo</span> is equivalent to <span>{}foo</span>, which is equivalent to <span>[]foo</span>. As noted before, though, we don't descend into empty nodes. And again, {}<p>foo</p> is different from <p>{}foo</p>.
7. Return null.

Given a [=boundary point=] (node, offset), the previous equivalent point is either a [=boundary point=] or null, as returned by the following algorithm:

1. If node's [=Node/length=] is zero, return null.
2. If offset is 0, and node's [=tree/parent=] is not null, and node is an inline node, return (node's [=tree/parent=], node's [=tree/index=]).
3. If node has a [=tree/child=] with [=tree/index=] offset − 1, and that [=tree/child=]'s [=Node/length=] is not zero, and that [=tree/child=] is an inline node, return (that [=tree/child=], that [=tree/child=]'s [=Node/length=]).
4. Return null.

The first equivalent point of a [=boundary point=] (node, offset) is returned by the following algorithm:

1. While (node, offset)'s previous equivalent point is not null, set (node, offset) to its previous equivalent point.
2. Return (node, offset).

The last equivalent point of a [=boundary point=] (node, offset) is returned by the following algorithm:

1. While (node, offset)'s next equivalent point is not null, set (node, offset) to its next equivalent point.
2. Return (node, offset).

Block-extending a range

A [=boundary point=] (node, offset) is a block start point if either node's [=tree/parent=] is null and offset is zero; or node has a [=tree/child=] with [=tree/index=] offset − 1, and that [=tree/child=] is either a visible block node or a visible [^br^].

A [=boundary point=] (node, offset) is a block end point if either node's [=tree/parent=] is null and offset is node's [=Node/length=]; or node has a [=tree/child=] with [=tree/index=] offset, and that [=tree/child=] is a visible block node.

A [=boundary point=] is a block boundary point if it is either a block start point or a block end point.

When a user agent is to block-extend a [=range=] range, it must run the following steps:

1. Let start node, start offset, end node, and end offset be the [=range/start=] and [=range/end=] nodes and [=boundary point/offsets=] of range.
2. If some [=tree/inclusive ancestor=] of start node is an [^li^], set start offset to the [=tree/index=] of the last such [^li^] in [=tree order=], and set start node to that [^li^]'s [=tree/parent=].
3. If (start node, start offset) is not a block start point, repeat the following steps:
   1. If start offset is zero, set it to start node's [=tree/index=], then set start node to its [=tree/parent=].
   2. Otherwise, subtract one from start offset.
   3. If (start node, start offset) is a block boundary point, break from this loop.

4. This just changes something like <div>{<p>foo]</p></div> to {<div><p>foo]</p></div>.

   While start offset is zero and start node's [=tree/parent=] is not null, set start offset to start node's [=tree/index=], then set start node to its [=tree/parent=].

5. If some [=tree/inclusive ancestor=] of end node is an [^li^], set end offset to one plus the [=tree/index=] of the last such [^li^] in [=tree order=], and set end node to that [^li^]'s [=tree/parent=].
6. If (end node, end offset) is not a block end point, repeat the following steps:
   1. If end offset is end node's [=Node/length=], set it to one plus end node's [=tree/index=], then set end node to its [=tree/parent=].
   2. Otherwise, add one to end offset.
   3. If (end node, end offset) is a block boundary point, break from this loop.
7. While end offset is end node's [=Node/length=] and end node's [=tree/parent=] is not null, set end offset to one plus end node's [=tree/index=], then set end node to its [=tree/parent=].
8. Let new range be a new [=range=] whose [=range/start=] and [=range/end=] nodes and [=boundary point/offsets=] are start node, start offset, end node, and end offset.
9. Return new range.

A node node follows a line break if the following algorithm returns true:

1. Let offset be zero.
2. While (node, offset) is not a block boundary point:
   1. If node has a visible [=tree/child=] with [=tree/index=] offset minus one, return false.
   2. If offset is zero or node has no [=tree/children=], set offset to node's [=tree/index=], then set node to its [=tree/parent=].
   3. Otherwise, set node to its [=tree/child=] with [=tree/index=] offset minus one, then set offset to node's [=Node/length=].
3. Return true.

A node node precedes a line break if the following algorithm returns true:

1. Let offset be node's [=Node/length=].
2. While (node, offset) is not a block boundary point:
   1. If node has a visible [=tree/child=] with [=tree/index=] offset, return false.
   2. If offset is node's [=Node/length=] or node has no [=tree/children=], set offset to one plus node's [=tree/index=], then set node to its [=tree/parent=].
   3. Otherwise, set node to its [=tree/child=] with [=tree/index=] offset and set offset to zero.
3. Return true.

Recording and restoring overrides

To record current overrides:

1. Let overrides be a list of (string, string or boolean) ordered pairs, initially empty.

2. When restoring, some commands can interfere with others. Specifically, we want to restore createLink before foreColor and underline, and subscript and superscript before fontSize. TODO: This approach only works for default styles (although I'm not sure offhand how we could handle non-default styles in principle).

   Firefox 7.0a2 and Opera 11.50 don't honor createLink with collapsed selections. If you insert text, it's not linked. The spec follows Chrome 14 dev. IE9 also ignores createLink with collapsed selections, but its behavior in other cases for collapsed selections is totally different from all other browsers, so it's not a fair comparison.

   If there is a value override for "createLink", add ("createLink", value override for "createLink") to overrides.

3. Firefox 7.0a2 and Opera 11.50 will honor repeated subscript/superscript commands on a collapsed selection, allowing you to nest them. The spec follows the general philosophy that we don't allow users to nest subscript/superscript, so the last one wins. Chrome 14 dev is similar to the spec.

   For each command in the list "bold", "italic", "strikethrough", "subscript", "superscript", "underline", in order: if there is a state override for command, add (command, command's state override) to overrides.

4. For each command in the list "fontName", "fontSize", "foreColor", "hiliteColor", in order: if there is a value override for command, add (command, command's value override) to overrides.
5. Return overrides.

To record current states and values:

1. Let overrides be a list of (string, string or boolean) ordered pairs, initially empty.
2. Let node be the first formattable node effectively contained in the active range, or null if there is none.
3. If node is null, return overrides.
4. Add ("createLink", node's effective command value for "createLink") to overrides.

5. Thus we will set state overrides based on the first formattable node, to match values. This means that if you have <p>foo<b>[bar</b>baz]</p> and hit backspace and hit A, you'll get <p>foo<b>a[]</b></p>, although bold was previously indeterminate. This is needed to match the behavior of hitting A straight away, since innerText doesn't strip wrappers when it invokes "delete the contents".

   For each command in the list "bold", "italic", "strikethrough", "subscript", "superscript", "underline", in order: if node's effective command value for command is one of its inline command activated values, add (command, true) to overrides, and otherwise add (command, false) to overrides.

6. For each command in the list "fontName", "foreColor", "hiliteColor", in order: add (command, command's value) to overrides.

7. Special case for fontSize, because its values are weird.

   Add ("fontSize", node's effective command value for "fontSize") to overrides.

   This is wrong: it will convert non-pixel sizes to pixel sizes. But I don't see any way to avoid it. Hopefully it won't come up too often. font-size is a real problem, because the mapping from specified value to computed value is lossy and not fully defined (e.g., how many px is "small"?).

8. Return overrides.

To restore states and values specified by a list overrides returned by the record current overrides or record current states and values algorithm:

1. Let node be the first formattable node effectively contained in the active range, or null if there is none.
2. If node is not null, then for each (command, override) pair in overrides, in order:
   1. If override is a boolean, and queryCommandState(command) returns something different from override, take the action for command, with value equal to the empty string.
   2. Otherwise, if override is a string, and command is neither "createLink" nor "fontSize", and queryCommandValue(command) returns something not equivalent to override, take the action for command, with value equal to override.

   3. This special case is needed because createLink has no value.

      Otherwise, if override is a string; and command is "createLink"; and either there is a value override for "createLink" that is not equal to override, or there is no value override for "createLink" and node's effective command value for "createLink" is not equal to override: take the action for "createLink", with value equal to override.

   4. The override will be some CSS value, so we have to convert it to a legacy font size.

      Otherwise, if override is a string; and command is "fontSize"; and either there is a value override for "fontSize" that is not equal to override, or there is no value override for "fontSize" and node's effective command value for "fontSize" is not loosely equivalent to override:

      1. Convert override to an integer number of pixels, and set override to the legacy font size for the result.
      2. Take the action for "fontSize", with value equal to override.
   5. Otherwise, continue this loop from the beginning.

   6. If we took the action for a command, we need to reset node, because it might have changed. For instance, if the selection was foo[bar]baz, the text node could have been split so that the first part is now outside the active range.

      Set node to the first formattable node effectively contained in the active range, if there is one.

3. Otherwise, for each (command, override) pair in overrides, in order:
   1. If override is a boolean, set the state override for command to override.
   2. If override is a string, set the value override for command to override.

Deleting the selection

TODO: Consider what should happen for block merging in corner cases like display: inline-table.

To delete the selection, given a block merging flag that defaults to true, a strip wrappers flag that defaults to true, and a string direction that defaults to "forward":

1. If the active range is null, abort these steps and do nothing.
2. Canonicalize whitespace at the active range's [=range/start=].
3. Canonicalize whitespace at the active range's [=range/end=].
4. Let (start node, start offset) be the last equivalent point for the active range's [=range/start=].
5. Let (end node, end offset) be the first equivalent point for the active range's [=range/end=].
6. If (end node, end offset) is not [=boundary point/after=] (start node, start offset):

   This is a selection like <span>foo[</span></span>]bar</span>, where the boundary points are equivalent but not identical. We just collapse it and abort, since there's nothing to delete.

   1. If direction is "forward", call collapseToStart() on the context object's selection.
   2. Otherwise, call collapseToEnd() on the context object's selection.
   3. Abort these steps.
7. If start node is a {{Text}} node and start offset is 0, set start offset to the [=tree/index=] of start node, then set start node to its [=tree/parent=].
8. If end node is a {{Text}} node and end offset is its [=Node/length=], set end offset to one plus the [=tree/index=] of end node, then set end node to its [=tree/parent=].

   The previous two steps are so that we won't leave empty text nodes anywhere.

9. Call collapse(start node, start offset) on the context object's selection.
10. Call extend(end node, end offset) on the context object's selection.

11. When we delete a selection that spans multiple blocks, we merge the end block's contents into the start block, like

    <p>fo[o</p><pre>b]ar</pre>
    -> <p>fo[]ar</p>.
    

    We figure out what the start and end blocks are before we start deleting anything.

12. Let start block be the active range's [=range/start node=].
13. While start block's [=tree/parent=] is in the same editing host and start block is an inline node, set start block to its [=tree/parent=].

14. We only merge to or from block nodes or editing hosts. (This is just in case someone makes a span into an editing host and sticks paragraphs inside it or something . . . we could probably drop that proviso.) Firefox 7.0a2 ignores the display property when merging, so it doesn't merge <span style=display:block> but does merge <p style=display:inline>. This is undesirable, because it's visually wrong. IE10PP2 and Chrome 14 dev behave more like the spec, and Opera 11.50 seems to be unable to make up its mind.

    If span isn't an allowed child, it's probably something unpleasant like a table row or a list or such. We don't want to merge to or from something like that, because we'd most likely wind up with the wrong type of child somewhere. It should be pretty hard for this to happen given the normalization we do on the selection; I'm not actually sure how it could happen at all, actually, unless you start out with a DOM that has non-allowed children someplace. So it's basically a sanity check.

    We don't let either start block or end block be a td or th. This means we'll never merge to or from a td or th. This matches Firefox 5.0a2, and reportedly Word as well. Chrome 13 dev and Opera 11.11 allow merging from a non-table cell end block to a table cell start block, but not vice versa. In IE9 the delete key just does nothing.

    If start block is neither a block node nor an [=editing host=], or "span" is not an allowed child of start block, or start block is a [^td^] or [^th^], set start block to null.

15. Let end block be the active range's [=range/end node=].
16. While end block's [=tree/parent=] is in the same editing host and end block is an inline node, set end block to its [=tree/parent=].
17. If end block is neither a block node nor an [=editing host=], or "span" is not an allowed child of end block, or end block is a [^td^] or [^th^], set end block to null.

18. Later on we'll restore overrides. This ensures that if we delete inline formatting elements and the user then types something, the typed text will have the same style as before.

19. As far as I can tell, IE9 and Opera 11.50 don't do this at all. If you delete a selection and then start typing, the new text doesn't take on the styles of the old text.

    Firefox 7.0a2 seems to do it for some styles but not others. Strikethrough, superscript, subscript, and links seem to be lost, at a minimum.

    The spec goes with something like Chrome 14 dev, which tries to preserve lots of stuff.

    Record current states and values, and let overrides be the result.

20. Now we actually begin deleting things.

21. This whole piece of the algorithm is based on deleteContents() in DOM Range, copy-pasted and then adjusted to fit.

    If start node and end node are the same, and start node is an editable {{Text}} node:

    1. Call deleteData(start offset, end offset − start offset) on start node.
    2. Canonicalize whitespace at (start node, start offset), with fix collapsed space false.
    3. If direction is "forward", call collapseToStart() on the context object's selection.
    4. Otherwise, call collapseToEnd() on the context object's selection.

    5. This is needed to restore any overrides that would otherwise be lost. TODO: In this and similar cases, we could optimize by saving only overrides, not the full state/value.

       Restore states and values from overrides.

    6. Abort these steps.
22. If start node is an editable {{Text}} node, call deleteData() on it, with start offset as the first argument and ([=Node/length=] of start node − start offset) as the second argument.
23. Let node list be a list of nodes, initially empty.

24. IE9 doesn't seem to let you do any intercell deletions: the delete key does nothing if you select across multiple cells. Firefox 5.0a2 and Opera 11.11 behave as the spec says, not removing any table things. Chrome 13 dev will remove entire rows if selected. Note that IE, Firefox, Word 2007, and OpenOffice.org 3.2.1 Ubuntu all switch to a magic cell-selection mode when you try to select between cells, at least in some cases, instead of selecting letter-by-letter.

    For each node contained in the active range, append node to node list if the last member of node list (if any) is not an [=tree/ancestor=] of node; node is editable; and node is not a [^thead^], [^tbody^], [^tfoot^], [^tr^], [^th^], or [^td^].

25. For each node in node list:
    1. Let parent be the [=tree/parent=] of node.
    2. Remove node from parent.

    3. Do this before stripping wrappers: see bug 13831.

       If the block node of parent has no visible [=tree/children=], and parent is editable or an [=editing host=], call createElement("br") on the context object and append the result as the last [=tree/child=] of parent.

    4. Taking insertText to test the case where strip wrappers is false, with value a: <p>[foo<b>bar</b>]baz becomes <p>a[]baz per spec, in IE9, and in Chrome 14 dev. Firefox 7.0a2 and Opera 11.50 make it <p>a[]<b></b>baz, with a useless wrapper. <p>foo<b>[bar</b>baz] becomes <p>foo<b>a[]</b> per spec and in IE9 and Firefox 7.0a2 and Opera 11.50; in Chrome 14 dev apparently it initially becomes <p>fooa[], but then the style is recreated. This is detectable if you do something weird like <span style=color:#aBcDeF> instead of <b>: it comes <font class=Apple-style-span color=#abcdef> or such. I follow IE9 in all cases, because it makes the most sense.

       If strip wrappers is true or parent is not an [=tree/inclusive ancestor=] of start node, while parent is an editable inline node with [=Node/length=] 0, let grandparent be the [=tree/parent=] of parent, then remove parent from grandparent, then set parent to grandparent.

       Even if strip wrappers is false, we still want to strip wrappers that aren't [=tree/inclusive ancestors=] of start node. The idea of not stripping wrappers is that we're going to insert new content right afterward, like text or an image, but that new content will be inserted at the start node. Wrappers in other places still need to be removed, because they would otherwise remain empty.

26. If end node is an editable {{Text}} node, call deleteData(0, end offset) on it.
27. Canonicalize whitespace at the active range's [=range/start=], with fix collapsed space false.
28. Canonicalize whitespace at the active range's [=range/end=], with fix collapsed space false.

29. Now we need to merge blocks. The simplest case is something like

    <p>fo[o</p><p>bar</p><p>b]az</p>
    -> <p>fo</p>{}<p>az</p>
    -> <p>fo{}az</p>
    

    where neither block descends from the other. More complicated is something like

    foo[<p>]bar</p>
    -> foo[]bar
    

    or

    <p>foo[</p>]bar
    -> <p>foo[]bar</p>
    

    where one descends from the other.

30. If block merging is false, or start block or end block is null, or start block is not in the same editing host as end block, or start block and end block are the same:
    1. If direction is "forward", call collapseToStart() on the context object's selection.
    2. Otherwise, call collapseToEnd() on the context object's selection.
    3. Restore states and values from overrides.
    4. Abort these steps.

31. We might have added a br to the start/end block in an earlier step. Now we're about to merge the blocks, and we don't want the br's to get in the way. The end block is being destroyed no matter what. If the start block winds up empty after merging, we'll add a new br child at the end so it doesn't collapse.

    If start block has one [=tree/child=], which is a collapsed block prop, remove its [=tree/child=] from it.

32. Just repeatedly blow up the end block in this case.

    If start block is an [=tree/ancestor=] of end block:

    1. Let reference node be end block.
    2. While reference node is not a [=tree/child=] of start block, set reference node to its [=tree/parent=].
    3. Call collapse() on the context object's selection, with first argument start block and second argument the [=tree/index=] of reference node.
    4. If end block has no [=tree/children=]:
       1. While end block is editable and is the only [=tree/child=] of its [=tree/parent=] and is not a [=tree/child=] of start block, let parent equal end block, then remove end block from parent, then set end block to parent.
       2. If end block is editable and is not an inline node, and its {{Node/ previousSibling}} and {{Node/ nextSibling}} are both inline nodes, call createElement("br") on the context object and insert it into end block's [=tree/parent=] immediately after end block.
       3. If end block is editable, remove it from its [=tree/parent=].
       4. Restore states and values from overrides.
       5. Abort these steps.
    5. If end block's {{Node/firstChild}} is not an inline node, restore states and values from record, then abort these steps.
    6. Let children be a list of nodes, initially empty.
    7. Append the first [=tree/child=] of end block to children.
    8. While children's last member is not a [^br^], and children's last member's {{Node/nextSibling}} is an inline node, append children's last member's {{Node/nextSibling}} to children.
    9. Record the values of children, and let values be the result.
    10. While children's first member's [=tree/parent=] is not start block, split the parent of children.
    11. If children's first member's {{Node/ previousSibling}} is an editable [^br^], remove that [^br^] from its [=tree/parent=].

33. In this case, pull in everything that comes after start block, until we hit a br or block node.

    Otherwise, if start block is a [=tree/descendant=] of end block:

    1. Call collapse() on the context object's selection, with first argument start block and second argument start block's [=Node/length=].
    2. Let reference node be start block.
    3. While reference node is not a [=tree/child=] of end block, set reference node to its [=tree/parent=].
    4. If reference node's {{Node/nextSibling}} is an inline node and start block's {{Node/lastChild}} is a [^br^], remove start block's {{Node/lastChild}} from it.
    5. Let nodes to move be a list of nodes, initially empty.
    6. If reference node's {{Node/nextSibling}} is neither null nor a block node, append it to nodes to move.
    7. While nodes to move is nonempty and its last member isn't a [^br^] and its last member's {{Node/nextSibling}} is neither null nor a block node, append its last member's {{Node/nextSibling}} to nodes to move.
    8. Record the values of nodes to move, and let values be the result.
    9. For each node in nodes to move, append node as the last [=tree/child=] of start block, preserving ranges.

34. In the last case, just move all the children of the end block to the start block, and then get rid of any elements we emptied that way.

    Otherwise:

    1. Call collapse() on the context object's selection, with first argument start block and second argument start block's [=Node/length=].
    2. If end block's {{Node/firstChild}} is an inline node and start block's {{Node/lastChild}} is a [^br^], remove start block's {{Node/lastChild}} from it.
    3. Record the values of end block's [=tree/children=], and let values be the result.
    4. While end block has [=tree/children=], append the first [=tree/child=] of end block to start block, preserving ranges.
    5. While end block has no [=tree/children=], let parent be the [=tree/parent=] of end block, then remove end block from parent, then set end block to parent.

35. We might have deleted the contents between two lists, in which case we should merge them. See bug 13976.

36. Let ancestor be start block.
37. While ancestor has an [=tree/inclusive ancestor=] [^ol^] in the same editing host whose {{Node/ nextSibling}} is also an [^ol^] in the same editing host, or an [=tree/inclusive ancestor=] [^ul^] in the same editing host whose {{Node/ nextSibling}} is also a [^ul^] in the same editing host:
    1. While ancestor and its {{Node/nextSibling}} are not both [^ol^]s in the same editing host, and are also not both [^ul^]s in the same editing host, set ancestor to its [=tree/parent=].
    2. While ancestor's {{Node/nextSibling}} has [=tree/children=], append ancestor's {{Node/nextSibling}}'s {{Node/firstChild}} as the last [=tree/child=] of ancestor, preserving ranges.
    3. Remove ancestor's {{Node/nextSibling}} from its [=tree/parent=].
38. Restore the values from values.
39. If start block has no [=tree/children=], call createElement("br") on the context object and append the result as the last [=tree/child=] of start block.
40. Remove extraneous line breaks at the end of start block.
41. Restore states and values from overrides.

Splitting a node list's parent

To split the parent of a list node list of consecutive [=tree/sibling=] nodes:

1. Let original parent be the [=tree/parent=] of the first member of node list.
2. If original parent is not editable or its [=tree/parent=] is null, do nothing and abort these steps.
3. If the first [=tree/child=] of original parent is in node list, remove extraneous line breaks before original parent.
4. If the first [=tree/child=] of original parent is in node list, and original parent follows a line break, set follows line break to true. Otherwise, set follows line break to false.
5. If the last [=tree/child=] of original parent is in node list, and original parent precedes a line break, set precedes line break to true. Otherwise, set precedes line break to false.

6. TODO: We insert things after the parent. This is bad, because it will cause them to become part of any ranges that immediately follow. For instance, if we're hitting "bar" in

   <div><p>foo<p>bar</div>{<p>baz}
   

   it becomes

   <div><p>foo</div>{<p>bar<p>baz}
   

   instead of

   <div><p>foo</div><p>bar{<p>baz}
   

   because of how range mutation rules work. This doesn't happen if we insert before. This may or may not be important enough to bother working around.

   If the first [=tree/child=] of original parent is not in node list, but its last [=tree/child=] is:

   1. For each node in node list, in reverse order, insert node into the [=tree/parent=] of original parent immediately after original parent, preserving ranges.
   2. If precedes line break is true, and the last member of node list does not precede a line break, call createElement("br") on the context object and insert the result immediately after the last member of node list.
   3. Remove extraneous line breaks at the end of original parent.
   4. Abort these steps.
7. If the first [=tree/child=] of original parent is not in node list:
   1. Let cloned parent be the result of calling cloneNode(false) on original parent.
   2. If original parent has an id attribute, unset it.
   3. Insert cloned parent into the [=tree/parent=] of original parent immediately before original parent.
   4. While the {{Node/ previousSibling}} of the first member of node list is not null, append the first [=tree/child=] of original parent as the last [=tree/child=] of cloned parent, preserving ranges.

8. Notice that a boundary point that was immediately before the element will now be immediately before its children, just because of the regular range mutation rules, without needing to worry about preserving ranges. Likewise for boundary points immediately after the element, if we wind up removing the element in the final step. Preserving ranges is only necessary for the sake of boundary points in the element or its descendants.

   For each node in node list, insert node into the [=tree/parent=] of original parent immediately before original parent, preserving ranges.

9. If follows line break is true, and the first member of node list does not follow a line break, call createElement("br") on the context object and insert the result immediately before the first member of node list.
10. If the last member of node list is an inline node other than a [^br^], and the first [=tree/child=] of original parent is a [^br^], and original parent is not an inline node, remove the first [=tree/child=] of original parent from original parent.
11. If original parent has no [=tree/children=]:
    1. Remove original parent from its [=tree/parent=].
    2. If precedes line break is true, and the last member of node list does not precede a line break, call createElement("br") on the context object and insert the result immediately after the last member of node list.
12. Otherwise, remove extraneous line breaks before original parent.

13. The parent might be null if it's a br that we removed in the last step, in which case this step isn't necessary.

    If node list's last member's {{Node/nextSibling}} is null, but its [=tree/parent=] is not null, remove extraneous line breaks at the end of node list's last member's [=tree/parent=].

To remove a node node while preserving its descendants, split the parent of node's [=tree/children=] if it has any. If it has no [=tree/children=], instead remove it from its [=tree/parent=].

Canonical space sequences

See long comment before insertText.

The canonical space sequence of length n, with boolean flags non-breaking start and non-breaking end, is returned by the following algorithm:

1. If n is zero, return the empty string.
2. If n is one and both non-breaking start and non-breaking end are false, return a single space (U+0020).
3. If n is one, return a single non-breaking space (U+00A0).
4. Let buffer be the empty string.
5. If non-breaking start is true, let repeated pair be U+00A0 U+0020. Otherwise, let it be U+0020 U+00A0.
6. While n is greater than three, append repeated pair to buffer and subtract two from n.
7. If n is three, append a three-code unit string to buffer depending on non-breaking start and non-breaking end:

   non-breaking start and non-breaking end false

   U+0020 U+00A0 U+0020

   non-breaking start true, non-breaking end false

   U+00A0 U+00A0 U+0020

   non-breaking start false, non-breaking end true

   U+0020 U+00A0 U+00A0

   non-breaking start and non-breaking end both true

   U+00A0 U+0020 U+00A0

8. Otherwise, append a two-code unit string to buffer depending on non-breaking start and non-breaking end:

   non-breaking start and non-breaking end false

   non-breaking start true, non-breaking end false

   U+00A0 U+0020

   non-breaking start false, non-breaking end true

   U+0020 U+00A0

   non-breaking start and non-breaking end both true

   U+00A0 U+00A0

9. Return buffer.

To canonicalize whitespace at (node, offset), given an optional boolean argument fix collapsed space that defaults to true:

1. If node is neither editable nor an editing host, abort these steps.
2. Let start node equal node and let start offset equal offset.

3. First we go to the beginning of the current whitespace run.

   Repeat the following steps:

   1. If start node has a [=tree/child=] in the same editing host with [=tree/index=] start offset minus one, set start node to that [=tree/child=], then set start offset to start node's [=Node/length=].

   2. TODO: Following a line break is unlikely to be the right criterion.

      Otherwise, if start offset is zero and start node does not follow a line break and start node's [=tree/parent=] is in the same editing host, set start offset to start node's [=tree/index=], then set start node to its [=tree/parent=].

   3. Otherwise, if start node is a {{Text}} node and its [=tree/parent=]'s resolved value for "white-space" is neither "pre" nor "pre-wrap" and start offset is not zero and the (start offset − 1)st code unit of start node's {{CharacterData/ data}} is a space (0x0020) or non-breaking space (0x00A0), subtract one from start offset.
   4. Otherwise, break from this loop.

4. Now we collapse any consecutive spaces, if fix collapsed space is true.

   Let end node equal start node and end offset equal start offset.

5. Let length equal zero.

6. This tries to delete spaces at the beginning of a line (bug 14119).

   Let collapse spaces be true if start offset is zero and start node follows a line break, otherwise false.

7. Repeat the following steps:
   1. If end node has a [=tree/child=] in the same editing host with [=tree/index=] end offset, set end node to that [=tree/child=], then set end offset to zero.

   2. TODO: Preceding a line break is unlikely to be the right criterion.

      Otherwise, if end offset is end node's [=Node/length=] and end node does not precede a line break and end node's [=tree/parent=] is in the same editing host, set end offset to one plus end node's [=tree/index=], then set end node to its [=tree/parent=].

   3. Otherwise, if end node is a {{Text}} node and its [=tree/parent=]'s resolved value for "white-space" is neither "pre" nor "pre-wrap" and end offset is not end node's [=Node/length=] and the end offsetth code unit of end node's {{CharacterData/ data}} is a space (0x0020) or non-breaking space (0x00A0):
      1. If fix collapsed space is true, and collapse spaces is true, and the end offsetth code unit of end node's {{CharacterData/ data}} is a space (0x0020): call deleteData(end offset, 1) on end node, then continue this loop from the beginning.
      2. Set collapse spaces to true if the end offsetth code unit of end node's {{CharacterData/ data}} is a space (0x0020), false otherwise.
      3. Add one to end offset.
      4. Add one to length.
   4. Otherwise, break from this loop.

8. We've already stripped leading whitespace, and collapsed consecutive spaces. Now we try to strip any collapsed trailing whitespace (bug 14119 again).

   If fix collapsed space is true, then while (start node, start offset) is [=boundary point/before=] (end node, end offset):

   1. If end node has a [=tree/child=] in the same editing host with [=tree/index=] end offset − 1, set end node to that [=tree/child=], then set end offset to end node's [=Node/length=].
   2. Otherwise, if end offset is zero and end node's [=tree/parent=] is in the same editing host, set end offset to end node's [=tree/index=], then set end node to its [=tree/parent=].
   3. Otherwise, if end node is a {{Text}} node and its [=tree/parent=]'s resolved value for "white-space" is neither "pre" nor "pre-wrap" and end offset is end node's [=Node/length=] and the last code unit of end node's {{CharacterData/ data}} is a space (0x0020) and end node precedes a line break:
      1. Subtract one from end offset.
      2. Subtract one from length.
      3. Call deleteData(end offset, 1) on end node.
   4. Otherwise, break from this loop.

9. Finally we replace with the canonical sequence.

   Let replacement whitespace be the canonical space sequence of length length. non-breaking start is true if start offset is zero and start node follows a line break, and false otherwise. non-breaking end is true if end offset is end node's {{CharacterData/length}} and end node precedes a line break, and false otherwise.

10. While (start node, start offset) is [=boundary point/before=] (end node, end offset):
    1. If start node has a [=tree/child=] with [=tree/index=] start offset, set start node to that [=tree/child=], then set start offset to zero.
    2. Otherwise, if start node is not a {{Text}} node or if start offset is start node's [=Node/length=], set start offset to one plus start node's [=tree/index=], then set start node to its [=tree/parent=].
    3. Otherwise:
       1. Remove the first code unit from replacement whitespace, and let element be that code unit.
       2. If element is not the same as the start offsetth code unit of start node's {{CharacterData/ data}}:

          1. We need to insert then delete, so that we don't change range boundary points. TODO: switch to using "replace data" now that DOM Core has defined that.

             Call insertData(start offset, element) on start node.

          2. Call deleteData(start offset + 1, 1) on start node.
       3. Add one to start offset.

Indenting and outdenting

<ol>
  {<li>foo</li>
  <ol><li>bar</li></ol>}
</ol>
->
<ol><ol>
  <li>foo</li>
  <li>bar</li>
</ol></ol>
->
<ol><ol><ol>
  <li>foo</li>
  <li>bar</li>
</ol></ol></ol>

To indent a list node list of consecutive [=tree/sibling=] nodes:

1. If node list is empty, do nothing and abort these steps.
2. Let first node be the first member of node list.
3. If first node's [=tree/parent=] is an [^ol^] or [^ul^]:
   1. Let tag be the [=Element/local name=] of the [=tree/parent=] of first node.

   2. This matches IE9, Firefox 4.0, and Chrome 12 dev. If there's a preceding <li>, Opera 11.10 instead adds the new parent to the end of that <li>, so it's not the child of another list, which is invalid. But the other browsers' way of doing things makes things simpler. E.g., if we want to indent an <li> and it has <ol>/<ul> children, we have to distinguish between the case where we want to indent the whole <li> or only the first part. It also allows things like

      <ol><li>
        foo
        <ol><li>bar</li></ol>
        baz
      </li></ol>
      

      in which case it's unclear what we should do if the user selects "foo" and indents. I've filed a bug on HTML5.

      Wrap node list, with sibling criteria returning true for an HTML element with [=Element/local name=] tag and false otherwise, and new parent instructions returning the result of calling createElement(tag) on the {{Node/ ownerDocument}} of first node.

   3. Abort these steps.

4. Firefox 4.0 respects the CSS styling flag for indent, but Chrome 12 dev does not. I always produce blockquotes, even if CSS styling is on, for two reasons. One, IE9 handles inline margin attributes badly: when outdenting, it propagates the margin to the parent, which doesn't actually remove it. Two, in CSS mode I'd want to use <div style="margin: 1em 40px"> to match non-CSS mode, but authors are very likely to want to remove the top/bottom margin, which they can't do if it's not a special tag. Authors who really want divs for indentation could always convert the blockquotes to divs themselves. But if people really want it, I could respect CSS styling mode here too.

   The top/bottom margins might be undesirable here, but no more so than for <ol>/<ul>/<p>/etc. Here as there, authors can remove them with CSS if they want.

   blockquote indents on both sides, so we don't have to worry about directionality. In theory it would be better if we indented only on the start side, but that requires care to get right in mixed-direction cases. Even once browsers start to support margin-start and so on, we can't use them because a) we have to work okay in legacy browsers and b) it doesn't help if a descendant block has different direction (so should be indented the other way). So let's not worry about it: most browsers don't, and the ones that do get it wrong. Just indent on both sides.

   Wrap node list, with sibling criteria returning true for a simple indentation element and false otherwise, and new parent instructions returning the result of calling createElement("blockquote") on the {{Node/ownerDocument}} of first node. Let new parent be the result.

5. Fix disallowed ancestors of new parent.

To outdent a node node:

1. If node is not editable, abort these steps.

2. The easy case is when the whole element is indented. In this case we remove the whole thing indiscriminately. In the case of blockquotes created by IE, this might change the direction of some children, but then their direction was probably changed incorrectly in the first place, so no harm.

   If node is a simple indentation element, remove node, preserving its descendants. Then abort these steps.

3. This might be a simple indentation element that had style added to it by Firefox in CSS mode, for instance (color, font-family, etc.).

   If node is an indentation element:

   1. Unset the dir attribute of node, if any.
   2. Unset the margin, padding, and border CSS properties of node.
   3. Set the tag name of node to "div".
   4. Abort these steps.

4. Approximate algorithms when an ancestor is causing the indentation appear to be:

   IE9

   Go to the innermost element causing indentation. If the stuff to be outdented includes all the contents of that element, get rid of it, but if it has any attributes, change it to a <p> with those same attributes. This is an excellent idea in general, but unfortunately it preserves explicitly-specified margins in style attributes, which isn't great. In other cases, it moves the stuff to be outdented outside. Not clear on all the details, seems to be pretty confusing. Also does a bunch of seemingly arbitrary normalization like removing divs and some attributes from some things . . .

   Firefox 4.0

   Go to the innermost element causing indentation. If the stuff to be outdented includes all the contents of that element, get rid of it, even if it has arbitrary attributes. Otherwise, move the stuff to be outdented outside the indenting element. If there are any intervening elements that include stuff not to be outdented, wrap the outdented stuff in copies (which can duplicate id's, etc.).

   Chrome 12 dev

   Go to the outermost element causing indentation (even if the current element is itself causing indentation). Move the text to be outdented outside that outermost element, without regard to any intervening elements. Then recreate the original styles on the moved text, in some fashion. Something like that; it confuses me and doesn't seem to be reasonable.

   Opera 11.00

   Like Firefox, except it goes to the outermost element, not the innermost. Also seems to special-case to avoid duplicate id's, and has a few other quirks.

   Overall, all flawed, so I'll make up my own, patterned after pushing down styles. First we search ancestors for a simple indentation element, which we stand a chance of completely removing. Failing that, we look for an indentation element that's not simple, so we can't completely remove it.

   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}} that is neither a simple indentation element nor an [^ol^] nor a [^ul^], append current ancestor to ancestor list and then set current ancestor to its [=tree/parent=].
7. If current ancestor is not an editable simple indentation element:
   1. Let current ancestor be node's [=tree/parent=].
   2. Let ancestor list be the empty list.
   3. While current ancestor is an editable {{Element}} that is neither an indentation element nor an [^ol^] nor a [^ul^], append current ancestor to ancestor list and then set current ancestor to its [=tree/parent=].

8. When asked to outdent a list wrapped in a simple indentation element, Chrome 12 dev removes the list instead of the simple indentation element. Opera 11.10 seems to remove both. IE9 and Firefox 4.0 remove the simple indentation element, as does the spec.

   If node is an [^ol^] or [^ul^] and current ancestor is not an editable indentation element:

   1. Unset the reversed, start, and type attributes of node, if any are set.
   2. Let children be the [=tree/children=] of node.

   3. We can't turn it into a div if it's the child of an ol or ul, because that's not allowed: there's no way to group li's (see HTML bug 13128).

      If node has attributes, and its [=tree/parent=] is not an [^ol^] or [^ul^], set the tag name of node to "div".

   4. Otherwise:
      1. Record the values of node's [=tree/children=], and let values be the result.
      2. Remove node, preserving its descendants.
      3. Restore the values from values.
   5. Fix disallowed ancestors of each member of children.
   6. Abort these steps.
9. If current ancestor is not an editable indentation element, abort these steps.

10. If we get to this point, we have an ancestor to split up.

    Append current ancestor to ancestor list.

11. We can't outdent it yet, because we need its children to remain intact for the loop.

    Let original ancestor be current ancestor.

12. 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. Let target be the [=tree/child=] of current ancestor that is equal to either node or the last member of ancestor list.
    4. If target is an inline node that is not a [^br^], and its {{Node/nextSibling}} is a [^br^], remove target's {{Node/nextSibling}} from its [=tree/parent=].
    5. Let preceding siblings be the [=tree/precedings=] [=tree/siblings=] of target, and let following siblings be the [=tree/followings=] [=tree/siblings=] of target.
    6. Indent preceding siblings.
    7. Indent following siblings.
13. Outdent original ancestor.

Toggling lists

ol ol { list-style-type: lower-alpha }
ol ol ol { list-style-type: lower-roman }

To toggle lists, given a string tag name (either "ol" or "ul"):

1. Let mode be "disable" if the selection's list state is tag name, and "enable" otherwise.
2. Let other tag name be "ol" if tag name is "ul", and "ul" if tag name is "ol".
3. Let items be a list of all [^li^]s that are [=tree/inclusive ancestors=] of the active range's [=range/start=] and/or [=range/end=] node.

4. TODO: This overnormalizes, but it seems like the simplest solution for now.

   For each item in items, normalize sublists of item.

5. Block-extend the active range, and let new range be the result.
6. If mode is "enable", then let lists to convert consist of every editable HTML element with [=Element/local name=] other tag name that is contained in new range, and for every list in lists to convert:

   1. Convert it to the right name. If possible, we want to merge with a neighboring list of the correct type. Failing that, we set the tag name.

      If list's {{Node/ previousSibling}} or {{Node/nextSibling}} is an editable HTML element with [=Element/local name=] tag name:

      1. Let children be list's [=tree/children=].
      2. Record the values of children, and let values be the result.
      3. Split the parent of children.
      4. Wrap children, with sibling criteria returning true for an HTML element with [=Element/local name=] tag name and false otherwise.
      5. Restore the values from values.
   2. Otherwise, set the tag name of list to tag name.
7. Let node list be a list of nodes, initially empty.

8. We exclude indentation elements so that selecting some random text and doing indent followed by insertOrderedList will have the same result as the reverse. Specifically,

   <blockquote>[foo]</blockquote> ->
   <blockquote><ol><li>[foo]</li></ol></blockquote>
   

   per spec and Firefox 4.0 and (more or less) Chrome 12 dev. Opera 11.10 instead does <ol><li>foo</li></ol>, so the indentation vanishes. IE9 does <ol><ol><li>foo</li></ol></ol>, but that doesn't make semantic sense and is different from how it would work if you reversed the commands. OpenOffice.org 3.2.1 (Ubuntu) and Word 2007 both agree with the spec in this case.

   For each node node contained in new range, if node is editable; the last member of node list (if any) is not an [=tree/ancestor=] of node; node is not an indentation element; and either node is an [^ol^] or [^ul^], or its [=tree/parent=] is an [^ol^] or [^ul^], or it is an allowed child of "li"; then append node to node list.

9. We don't want to touch these. E.g., assuming tag name is "ol",

   [foo<ol><li>bar</ol>baz]
   -> <ol><li>[foo<li>bar<li>baz]</ol>
   not <ol><li>[foo</li><ol><li>bar</ol><li>baz]</ol>.
   

   But

   <ul><li>foo<li>[bar</li><ol><li>baz</ol><li>quz]</ul>
   -> <ul><li>foo</ul><ol><li>[bar</li><ol><li>baz</ol><li>quz]</ol>
   not <ul><li>foo</ul><ol><li>[bar</ol><ul><ol><li>baz</ol></ul><ol><li>quz]</ol>
   

   If mode is "enable", remove from node list any [^ol^] or [^ul^] whose [=tree/parent=] is not also an [^ol^] or [^ul^].

10. If mode is "disable", then while node list is not empty:
    1. Let sublist be an empty list of nodes.
    2. Remove the first member from node list and append it to sublist.
    3. If the first member of sublist is an HTML element with [=Element/local name=] tag name, outdent it and continue this loop from the beginning.
    4. While node list is not empty, and the first member of node list is the {{Node/nextSibling}} of the last member of sublist and is not an HTML element with [=Element/local name=] tag name, remove the first member from node list and append it to sublist.
    5. Record the values of sublist, and let values be the result.
    6. Split the parent of sublist.
    7. Fix disallowed ancestors of each member of sublist.
    8. Restore the values from values.
11. Otherwise, while node list is not empty:
    1. Let sublist be an empty list of nodes.

    2. Accumulate consecutive sibling nodes in sublist, first converting them all to li's (except if they're already lists).

       While either sublist is empty, or node list is not empty and its first member is the {{Node/nextSibling}} of sublist's last member:

       1. Thus <p>foo</p> becomes <ol><li>foo</ol> instead of <ol><li><p>foo</ol>, and likewise for div, but other things will be put inside the <li>.

          If node list's first member is a [^p^] or [^div^], set the tag name of node list's first member to "li", and append the result to sublist. Remove the first member from node list.

       2. Otherwise, if the first member of node list is an [^li^] or [^ol^] or [^ul^], remove it from node list and append it to sublist.
       3. Otherwise:
          1. Let nodes to wrap be a list of nodes, initially empty.

             [Page truncated to keep GeezerVison snappy.]