HTML Editing APIs

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

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

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

A removeFormat candidate is an editable HTML element with [[localname]] "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 [[children]], insert the first [[child]] of element into the [[parent]] of element immediately before element, preserving ranges.
   2. Remove element from its [[parent]].

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

   If the active range's [[startnode]] is an editable [[text]] node, and its [[startoffset]] is neither zero nor its [[startnode]]'s [[length]], call [[splittext|]] on the active range's [[startnode]], with argument equal to the active range's [[startoffset]]. Then set the active range's [[startnode]] to the result, and its [[startoffset]] to zero.

4. If the active range's [[endnode]] is an editable [[text]] node, and its [[endoffset]] is neither zero nor its [[endnode]]'s [[length]], call [[splittext|]] on the active range's [[endnode]], with argument equal to the active range's [[endoffset]].
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 [[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

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

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

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

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

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 [[ancestor]] of one of its [[boundarypoints]].
2. Clear the value of each member of hyperlinks.
3. Return true.

Block formatting commands

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 [[localname]] "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 [[localname]] "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 [[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 [[rangecollapsed]], 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 [[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 [[contextobject]]. 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 [[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 [[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 [[parent]] is not editable, abort these steps.
2. Let new item be null.
3. While item has an [[ol]] or [[ul]] [[child]]:
   1. Let child be the last [[child]] of item.
   2. If child is an [[ol]] or [[ul]], or new item is null and child is a [[text]] node whose data consists of zero of more space characters:
      1. Set new item to null.
      2. Insert child into the [[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 [[ownerdocument]] of item, then insert new item into the [[parent]] of item immediately after item.
      2. Insert child into new item as its first [[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 [[ancestor]] of node; node is editable; node is not an indentation element; and node is either an [[ol]] or [[ul]], or the [[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 [[child]] of an [[ol]] or the [[child]] of an [[li]] [[child]] of an [[ol]], and none is a [[ul]] or an [[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 [[child]] of a [[ul]] or the [[child]] of an [[li]] [[child]] of a [[ul]], and none is an [[ol]] or an [[ancestor]] of an [[ol]], return "ul".

8. If some member of node list is either an [[ol]] or the [[child]] or [[ancestor]] of an [[ol]] or the [[child]] of an [[li]] [[child]] of an [[ol]], and some member of node list is either a [[ul]] or the [[child]] or [[ancestor]] of a [[ul]] or the [[child]] of an [[li]] [[child]] of a [[ul]], return "mixed".
9. If some member of node list is either an [[ol]] or the [[child]] or [[ancestor]] of an [[ol]] or the [[child]] of an [[li]] [[child]] of an [[ol]], return "mixed ol".
10. If some member of node list is either a [[ul]] or the [[child]] or [[ancestor]] of a [[ul]] or the [[child]] of an [[li]] [[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 [[resval]] "inline" or "none", set node to its [[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 [[resval]] "start", return "left" if the [[directionality]] of node is "ltr", "right" if it is "rtl".
4. If node's "text-align" property has [[resval]] "end", return "right" if the [[directionality]] of node is "ltr", "left" if it is "rtl".
5. If node's "text-align" property has [[resval]] "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 {{code|

Hello

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

1. If node's [[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 {{code|{}}} were equivalent to {{code|{}}}, it would also be equivalent to {{code|{} }}. This produces very unexpected results for nodes like {{code|
   }}.
3. If offset is node's [[length]], and node's [[parent]] is not null, and node is an inline node, return (node's [[parent]], 1 + node's [[index]]).
4. For instance, {{code|foo[]}} is equivalent to {{code|foo{}}}, which is equivalent to {{code|foo{} }}. However, {{code|

   foo{}

   }} is not equivalent to {{code|

   foo

   {} }} – the cursor might look like it's in a visibly different position.
5. If node has a [[child]] with [[index]] offset, and that [[child]]'s [[length]] is not zero, and that [[child]] is an inline node, return (that [[child]], 0).
6. For instance, {{code|{}foo}} is equivalent to {{code|{}foo}}, which is equivalent to {{code|[]foo}}. As noted before, though, we don't descend into empty nodes. And again, {{code|{}

   foo

   }} is different from {{code|

   {}foo

   }}.
7. Return null.

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

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

The first equivalent point of a [[boundarypoint]] (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 [[boundarypoint]] (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 [[boundarypoint]] (node, offset) is a block start point if either node's [[parent]] is null and offset is zero; or node has a [[child]] with [[index]] offset − 1, and that [[child]] is either a visible block node or a visible [[br]].

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

A [[boundarypoint]] 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 [[rangestart]] and [[rangeend]] [[nodes]] and [[bpoffsets]] of range.
2. If some [[inclusiveancestor]] of start node is an [[li]], set start offset to the [[index]] of the last such [[li]] in [[treeorder]], and set start node to that [[li]]'s [[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 [[index]], then set start node to its [[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 [[parent]] is not null, set start offset to start node's [[index]], then set start node to its [[parent]].

5. If some [[inclusiveancestor]] of end node is an [[li]], set end offset to one plus the [[index]] of the last such [[li]] in [[treeorder]], and set end node to that [[li]]'s [[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 [[length]], set it to one plus end node's [[index]], then set end node to its [[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 [[length]] and end node's [[parent]] is not null, set end offset to one plus end node's [[index]], then set end node to its [[parent]].
8. Let new range be a new [[range]] whose [[rangestart]] and [[rangeend]] [[nodes]] and [[bpoffsets]] 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 [[child]] with [[index]] offset minus one, return false.
   2. If offset is zero or node has no [[children]], set offset to node's [[index]], then set node to its [[parent]].
   3. Otherwise, set node to its [[child]] with [[index]] offset minus one, then set offset to node's [[length]].
3. Return true.

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

1. Let offset be node's [[length]].
2. While (node, offset) is not a block boundary point:
   1. If node has a visible [[child]] with [[index]] offset, return false.
   2. If offset is node's [[length]] or node has no [[children]], set offset to one plus node's [[index]], then set node to its [[parent]].
   3. Otherwise, set node to its [[child]] with [[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 {{code|

   foo[barbaz]

   }} and hit backspace and hit A, you'll get {{code|

   fooa[]

   }}, 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 [[looselyequivalent]] 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 {{code|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 [[rangestart]].
3. Canonicalize whitespace at the active range's [[rangeend]].
4. Let (start node, start offset) be the last equivalent point for the active range's [[rangestart]].
5. Let (end node, end offset) be the first equivalent point for the active range's [[rangeend]].
6. If (end node, end offset) is not [[bpafter]] (start node, start offset):

   This is a selection like {{code|foo[]bar}}, 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 [[contextobject]]'s [[selection]].
   2. Otherwise, call [[collapsetoend]] on the [[contextobject]]'s [[selection]].
   3. Abort these steps.
7. If start node is a [[text]] node and start offset is 0, set start offset to the [[index]] of start node, then set start node to its [[parent]].
8. If end node is a [[text]] node and end offset is its [[length]], set end offset to one plus the [[index]] of end node, then set end node to its [[parent]].

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

9. Call [[selcollapse|start node, start offset]] on the [[contextobject]]'s [[selection]].
10. Call [[extend|end node, end offset]] on the [[contextobject]]'s [[selection]].

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

    {{html|
    fo[o
    b]ar
    -> 
    fo[]ar
    .}}

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

12. Let start block be the active range's [[startnode]].
13. While start block's [[parent]] is in the same editing host and start block is an inline node, set start block to its [[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 {{code|}} but does merge {{code|

    }}. 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 [[endnode]].
16. While end block's [[parent]] is in the same editing host and end block is an inline node, set end block to its [[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 [[contextobject]]'s [[selection]].
    4. Otherwise, call [[collapsetoend]] on the [[contextobject]]'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 ([[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 [[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 [[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 [[children]], and parent is editable or an editing host, call [[createelement|"br"]] on the [[contextobject]] and append the result as the last [[child]] of parent.

    4. Taking insertText to test the case where strip wrappers is false, with value a: {{code<|p>[foobar]baz}} becomes {{code|

       a[]baz}} per spec, in IE9, and in Chrome 14 dev. Firefox 7.0a2 and Opera 11.50 make it {{code<|p>a[]baz}}, with a useless wrapper. {{code<|p>foo[barbaz]}} becomes {{code<|p>fooa[]}} per spec and in IE9 and Firefox 7.0a2 and Opera 11.50; in Chrome 14 dev apparently it initially becomes {{code|

       fooa[]}}, but then the style is recreated. This is detectable if you do something weird like {{code<|span style=color:#aBcDeF>}} instead of {{code<|b>}}: it comes {{code<|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 [[inclusiveancestor]] of start node, while parent is an editable inline node with [[length]] 0, let grandparent be the [[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 [[inclusiveancestors]] 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 [[rangestart]], with fix collapsed space false.
28. Canonicalize whitespace at the active range's [[rangeend]], with fix collapsed space false.

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

    {{html|
    fo[o
    bar
    b]az
    -> 
    fo
    {}
    az
    -> 
    fo{}az
    }}

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

    {{html|
    foo[
    ]bar
    -> foo[]bar}}

    or

    {{html|
    foo[
    ]bar
    -> 
    foo[]bar
    }}

    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 [[contextobject]]'s [[selection]].
    2. Otherwise, call [[collapsetoend]] on the [[contextobject]]'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 [[child]], which is a collapsed block prop, remove its [[child]] from it.

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

    If start block is an [[ancestor]] of end block:

    1. Let reference node be end block.
    2. While reference node is not a [[child]] of start block, set reference node to its [[parent]].
    3. Call [[selcollapse|]] on the [[contextobject]]'s [[selection]], with first argument start block and second argument the [[index]] of reference node.
    4. If end block has no [[children]]:
       1. While end block is editable and is the only [[child]] of its [[parent]] and is not a [[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 [[previoussibling]] and [[nextsibling]] are both inline nodes, call [[createelement|"br"]] on the [[contextobject]] and insert it into end block's [[parent]] immediately after end block.
       3. If end block is editable, remove it from its [[parent]].
       4. Restore states and values from overrides.
       5. Abort these steps.
    5. If end block's [[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 [[child]] of end block to children.
    8. While children's last member is not a [[br]], and children's last member's [[nextsibling]] is an inline node, append children's last member's [[nextsibling]] to children.
    9. Record the values of children, and let values be the result.
    10. While children's first member's [[parent]] is not start block, split the parent of children.
    11. If children's first member's [[previoussibling]] is an editable [[br]], remove that [[br]] from its [[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 [[descendant]] of end block:

    1. Call [[selcollapse|]] on the [[contextobject]]'s [[selection]], with first argument start block and second argument start block's [[length]].
    2. Let reference node be start block.
    3. While reference node is not a [[child]] of end block, set reference node to its [[parent]].
    4. If reference node's [[nextsibling]] is an inline node and start block's [[lastchild]] is a [[br]], remove start block's [[lastchild]] from it.
    5. Let nodes to move be a list of [[nodes]], initially empty.
    6. If reference node's [[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 [[nextsibling]] is neither null nor a block node, append its last member's [[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 [[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 [[selcollapse|]] on the [[contextobject]]'s [[selection]], with first argument start block and second argument start block's [[length]].
    2. If end block's [[firstchild]] is an inline node and start block's [[lastchild]] is a [[br]], remove start block's [[lastchild]] from it.
    3. Record the values of end block's [[children]], and let values be the result.
    4. While end block has [[children]], append the first [[child]] of end block to start block, preserving ranges.
    5. While end block has no [[children]], let parent be the [[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 [[inclusiveancestor]] [[ol]] in the same editing host whose [[nextsibling]] is also an [[ol]] in the same editing host, or an [[inclusiveancestor]] [[ul]] in the same editing host whose [[nextsibling]] is also a [[ul]] in the same editing host:
    1. While ancestor and its [[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 [[parent]].
    2. While ancestor's [[nextsibling]] has [[children]], append ancestor's [[nextsibling]]'s [[firstchild]] as the last [[child]] of ancestor, preserving ranges.
    3. Remove ancestor's [[nextsibling]] from its [[parent]].
38. Restore the values from values.
39. If start block has no [[children]], call [[createelement|"br"]] on the [[contextobject]] and append the result as the last [[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 [[sibling]] [[nodes]]:

1. Let original parent be the [[parent]] of the first member of node list.
2. If original parent is not editable or its [[parent]] is null, do nothing and abort these steps.
3. If the first [[child]] of original parent is in node list, remove extraneous line breaks before original parent.
4. If the first [[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 [[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 [[child]] of original parent is not in node list, but its last [[child]] is:

   1. For each node in node list, in reverse order, insert node into the [[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 [[contextobject]] 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 [[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 [[parent]] of original parent immediately before original parent.
   4. While the [[previoussibling]] of the first member of node list is not null, append the first [[child]] of original parent as the last [[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 [[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 [[contextobject]] 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 [[child]] of original parent is a [[br]], and original parent is not an inline node, remove the first [[child]] of original parent from original parent.
11. If original parent has no [[children]]:
    1. Remove original parent from its [[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 [[contextobject]] 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 [[nextsibling]] is null, but its [[parent]] is not null, remove extraneous line breaks at the end of node list's last member's [[parent]].

To remove a [[node]] node while preserving its descendants, split the parent of node's [[children]] if it has any. If it has no [[children]], instead remove it from its [[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-[[codeunit]] 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-[[codeunit]] 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 [[child]] in the same editing host with [[index]] start offset minus one, set start node to that [[child]], then set start offset to start node's [[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 [[parent]] is in the same editing host, set start offset to start node's [[index]], then set start node to its [[parent]].

   3. Otherwise, if start node is a [[text]] node and its [[parent]]'s [[resval]] for "white-space" is neither "pre" nor "pre-wrap" and start offset is not zero and the (start offset − 1)st [[codeunit]] of start node's [[cddata]] 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 [[child]] in the same editing host with [[index]] end offset, set end node to that [[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 [[length]] and end node does not precede a line break and end node's [[parent]] is in the same editing host, set end offset to one plus end node's [[index]], then set end node to its [[parent]].

   3. Otherwise, if end node is a [[text]] node and its [[parent]]'s [[resval]] for "white-space" is neither "pre" nor "pre-wrap" and end offset is not end node's [[length]] and the end offsetth [[codeunit]] of end node's [[cddata]] 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 [[codeunit]] of end node's [[cddata]] 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 [[codeunit]] of end node's [[cddata]] 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 [[bpbefore]] (end node, end offset):

   1. If end node has a [[child]] in the same editing host with [[index]] end offset − 1, set end node to that [[child]], then set end offset to end node's [[length]].
   2. Otherwise, if end offset is zero and end node's [[parent]] is in the same editing host, set end offset to end node's [[index]], then set end node to its [[parent]].
   3. Otherwise, if end node is a [[text]] node and its [[parent]]'s [[resval]] for "white-space" is neither "pre" nor "pre-wrap" and end offset is end node's [[length]] and the last [[codeunit]] of end node's [[cddata]] 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 [[cdlength]] and end node precedes a line break, and false otherwise.

10. While (start node, start offset) is [[bpbefore]] (end node, end offset):
    1. If start node has a [[child]] with [[index]] start offset, set start node to that [[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 [[length]], set start offset to one plus start node's [[index]], then set start node to its [[parent]].
    3. Otherwise:
       1. Remove the first [[codeunit]] from replacement whitespace, and let element be that [[codeunit]].
       2. If element is not the same as the start offsetth [[codeunit]] of start node's [[cddata]]:

          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 [[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 [[parent]] is an [[ol]] or [[ul]]:
   1. Let tag be the [[localname]] of the [[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 [[localname]] tag and false otherwise, and new parent instructions returning the result of calling [[createelement|tag]] on the [[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 [[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 [[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 [[parent]].
7. If current ancestor is not an editable simple indentation element:
   1. Let current ancestor be node's [[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 [[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 [[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 [[parent]] is not an [[ol]] or [[ul]], set the tag name of node to "div".

   4. Otherwise:
      1. Record the values of node's [[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 [[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 [[nextsibling]] is a [[br]], remove target's [[nextsibling]] from its [[parent]].
    5. Let preceding siblings be the [[precedingsiblings]] of target, and let following siblings be the [[followingsiblings]] 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 [[inclusiveancestors]] of the active range's [[rangestart]] and/or [[rangeend]] [[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 [[localname]] 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 [[previoussibling]] or [[nextsibling]] is an editable HTML element with [[localname]] tag name:

      1. Let children be list's [[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 [[localname]] 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 [[ancestor]] of node; node is not an indentation element; and either node is an [[ol]] or [[ul]], or its [[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 [[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 [[localname]] 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 [[nextsibling]] of the last member of sublist and is not an HTML element with [[localname]] 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 [[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.
          2. While nodes to wrap is empty, or node list is not empty and its first member is the [[nextsibling]] of nodes to wrap's last member and the first member of node list is an inline node and the last member of nodes to wrap is an inline node other than a [[br]], remove the first member from node list and append it to nodes to wrap.
          3. Wrap nodes to wrap, with new parent instructions returning the result of calling [[createelement|"li"]] on the [[contextobject]]. Append the result to sublist.

    3. In this case it's already wrapped properly, nothing more to do.

       If sublist's first member's [[parent]] is an HTML element with [[localname]] tag name, or if every member of sublist is an [[ol]] or [[ul]], continue this loop from the beginning.

    4. If sublist's first member's [[parent]] is an HTML element with [[localname]] other tag name:
       1. Record the values of sublist, and let values be the result.
       2. Split the parent of sublist.
       3. Wrap sublist, with sibling criteria returning true for an HTML element with [[localname]] tag name and false otherwise, and new parent instructions returning the result of calling [[createelement|tag name]] on the [[contextobject]].
       4. Restore the values from values.
       5. Continue this loop from the beginning.
    5. Wrap sublist, with sibling criteria returning true for an HTML element with [[localname]] tag name and false otherwise, and new parent instructions being the following:

       1. Special case: something like

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

          becomes

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

          instead of

          <ol><li>foo</ol><blockquote><ol><li>[bar]</ol></blockquote>.

          We handle the special case in new parent instructions instead of outside because we'd prefer to wind up in a sibling if there is one. We handle only previousSibling, not nextSibling, because we really mean for this to cover something like

          [foo<blockquote>bar]</blockquote>

          which we'll handle node-by-node. TODO: Maybe we should do this differently, like just special-case simple indentation elements in an earlier part of the algorithm? This way's a bit weird.

          If sublist's first member's [[parent]] is not an editable simple indentation element, or sublist's first member's [[parent]]'s [[previoussibling]] is not an editable HTML element with [[localname]] tag name, call [[createelement|tag name]] on the [[contextobject]] and return the result.

       2. Let list be sublist's first member's [[parent]]'s [[previoussibling]].
       3. Normalize sublists of list's [[lastchild]].
       4. If list's [[lastchild]] is not an editable HTML element with [[localname]] tag name, call [[createelement|tag name]] on the [[contextobject]], and append the result as the last [[child]] of list.
       5. Return the last [[child]] of list.
    6. Fix disallowed ancestors of the previous step's result.

Justifying the selection

This is the action for the four justify* commands. It's pretty straightforward, with no notable gotchas or special cases. It works more or less like a stripped-down version of set the selection's value, except it gets to be much simpler because it's much less general. (It's not similar enough to just invoke that algorithm: too many things differ between block and inline elements.)

To justify the selection to a string alignment (either "center", "justify", "left", or "right"):

1. Block-extend the active range, and let new range be the result.

2. No browser actually removes center, but it makes sense to do so.

   Let element list be a list of all editable [[element]]s [[contained]] in new range that either has an attribute in the [[htmlnamespace]] whose [[attrlocalname]] is "align", or has a [[style]] attribute that sets "text-align", or is a center.

3. For each element in element list:
   1. If element has an attribute in the [[htmlnamespace]] whose [[attrlocalname]] is "align", remove that attribute.
   2. Unset the CSS property "text-align" on element, if it's set by a [[style]] attribute.
   3. If element is a [[div]] or [[span]] or center with no attributes, remove it, preserving its descendants.
   4. If element is a center with one or more attributes, set the tag name of element to "div".

4. This could theoretically be necessary, like if it converted "<div align=right>foo</div>bar" to "foo<br>bar". Now we need to select "foo<br>", nor just "foo".

   Block-extend the active range, and let new range be the result.

5. Let node list be a list of [[nodes]], initially empty.

6. Of tested browsers, only Chrome 13 dev seems to not apply the alignment to nodes that are already aligned. Even then, it does apply it if the alignment is just inherited from the root.

   For each [[node]] node [[contained]] in new range, append node to node list if the last member of node list (if any) is not an [[ancestor]] of node; node is editable; node is an allowed child of "div"; and node's alignment value is not alignment.

7. While node list is not empty:
   1. Let sublist be a list of [[nodes]], initially empty.
   2. Remove the first member of node list and append it to sublist.
   3. While node list is not empty, and the first member of node list is the [[nextsibling]] of the last member of sublist, remove the first member of node list and append it to sublist.

   4. Wrap sublist. Sibling criteria returns true for any [[div]] that has one or both of the following two attributes and no other attributes, and false otherwise:

      • An align attribute whose [[attrvalue]] is an ASCII case-insensitive match for alignment.
      • A [[style]] attribute which sets exactly one CSS property (including unrecognized or invalid attributes), which is "text-align", which is set to alignment.

      As with inline formatting, I only ever create new elements, and don't ever modify existing ones. This doesn't match how any browser behaves in this case, but for inline formatting it matches everyone but Gecko's CSS mode, so I'm just being consistent.

      New parent instructions are to call [[createelement|"div"]] on the [[contextobject]], then set its CSS property "text-align" to alignment and return the result.

Automatic linking

Bug 13807.

When the user inserts whitespace immediately following something that looks like a URL or e-mail address, we automatically run the createLink command on it.

An autolinkable URL is a string of the following form:

1. IE9 and LibreOffice 3.3.4 both have a whitelist of URL schemes. That would be complicated and involve political decisions, so instead, we'll just accept anything that looks like a hierarchical URL scheme. Google Docs is similar (as of November 9, 2011), but it's too lax, and allows characters in the scheme that can't be in a scheme. For non-hierarchical schemes, we just whitelist mailto:, since it's the only common one that makes sense to autolink.

   Either a string matching the scheme pattern from RFC 3986 section 3.1 followed by the literal string {{code|://}}, or the literal string {{code|mailto:}}; followed by

2. We don't try to enforce that the URL is anything resembling valid per spec. Too complicated for not enough gain.

   Zero or more characters other than [[spacecharacters]]; followed by

3. If the user types a URL followed by some punctuation, we still want to autolink, but we don't want to include the punctuation if it's probably not meant as part of the URL.

   IE9 excludes !#&()*+,-.:;<=?@[]^_`{|}~ as trailing characters from both URLs and e-mails. A trailing {{code|"}} or {{code|>}} will prevent autolinking, and a trailing {{code|$%'/\}} is included in the link.

   LibreOffice 3.3.4 excludes trailing {{code|!”#'()*+,.:;<=>?[\]^_`{|}~}}, and prevents autolinking on {{code|$%&-@ }}. It includes a trailing {{code|/}} in URLs, but it inhibits linking for e-mails.

   Google Docs (as of November 9, 2011) is complicated. Trailing {{code|”’,-.}} always prevents autolinking of a URL, and trailing {{code|#%/?_}} is always included in a URL. Trailing !&=$()*+:;<>@[\]^`{|}~ prevent autolinking if there's no {{code|?}} before them, but are included in the URL if there is a {{code|?}}. For e-mails, {{code|_}} is included, and everything else prevents autolinking.

   None of these behaviors makes maximal sense. We should exclude characters if they're more likely as delimiters than actual trailing characters; include them if they're more likely as actual trailing characters; and prevent autolinking if their presence suggests that we're not actually looking at a link or e-mail address. The lists I made up for URLs are: exclude trailing !"'(),-.:;<>[]`{}, include anything else. For e-mail, exclude anything at all.

   A character that is not one of the ASCII characters !"'(),-.:;<>[]`{}.

To autolink (node, end offset):

1. While (node, end offset)'s previous equivalent point is not null, set it to its previous equivalent point.
2. If node is not a [[text]] node, or has an [[a]] [[ancestor]], do nothing and abort these steps.
3. Let search be the largest substring of node's [[cddata]] whose end is end offset and that contains no [[spacecharacters]].
4. If some substring of search is an autolinkable URL:
   1. While there is no substring of node's [[cddata]] ending at end offset that is an autolinkable URL, decrement end offset.
   2. Let start offset be the start index of the longest substring of node's [[cddata]] that is an autolinkable URL ending at end offset.
   3. Let href be the substring of node's [[cddata]] starting at start offset and ending at end offset.
5. Otherwise, if some substring of search is a valid e-mail address:
   1. While there is no substring of node's [[cddata]] ending at end offset that is a valid e-mail address, decrement end offset.
   2. Let start offset be the start index of the longest substring of node's [[cddata]] that is a valid e-mail address ending at end offset.
   3. Let href be "mailto:" concatenated with the substring of node's [[cddata]] starting at start offset and ending at end offset.
6. Otherwise, do nothing and abort these steps.
7. Let original range be the active range.
8. Create a new [[range]] with [[rangestart]] (node, start offset) and [[rangeend]] (node, end offset), and set the [[contextobject]]'s [[selection]]'s [[range]] to it.
9. Take the action for "createLink", with value equal to href.
10. Set the [[contextobject]]'s [[selection]]'s [[range]] to original range.

The delete command

1. IE9 requires the brackets. If they're not provided, it does nothing.

   If value begins with a "<" character and ends with a ">" character, remove the first and last characters from it.

2. Let value be converted to ASCII lowercase.

3. Opera 11.10 throws NOT_SUPPORTED_ERR for bad elements, all other tested browsers ignore the input. Testing in IE9, Firefox 4.0, Chrome 13 dev, and Opera 11.10, supported elements seem to be:

   Everyone

   address, div, h*, p, pre

   Everyone but IE

   blockquote

   Everyone but Opera

   dd, dt

   IE only

   dir, menu, ol, ul

   Firefox and Chrome only

   dl

   Chrome only

   article, aside, footer, header, hgroup, nav, section

   HTML5 as of May 2011 supports: address, article, aside, blockquote, div, footer, h*, header, hgroup, nav, p, pre, section, which exactly matches Chrome except minus dd/dt/dl.

   See mailing list discussion on the subject.

   If value is not a formattable block name, return false.

4. Block-extend the active range, and let new range be the result.
5. Let node list be an empty list of [[nodes]].
6. For each [[node]] node [[contained]] in new range, append node to node list if it is editable, the last member of original node list (if any) is not an [[ancestor]] of node, node is either a non-list single-line container or an allowed child of "p" or a [[dd]] or [[dt]], and node is not the [[ancestor]] of a prohibited paragraph child.
7. Record the values of node list, and let values be the result.

8. This tries to avoid misnesting if only some lines of an element are selected, so <h1>[foo]<br>bar</h1> becomes <p>[foo]</p><h1>bar</h1> instead of <h1><p>[foo]</p><br>bar</h1> or such. It tries to heuristically distinguish between divs used as line-breakers and divs used as actual wrappers by checking if they have prohibited paragraph children as descendants. It works for address too, in case there are paragraphs nested inside. Thus <address>[foo]<br>bar</address> becomes <p>[foo]</p><address>bar</address>, but <address>[foo]<p>bar</p></address> becomes <address><p>[foo]</p><p>bar</p></address>. Likewise, we don't break things out of lists or tables or such if they happen to be nested in a <div>.

   For each node in node list, while node is the [[descendant]] of an editable HTML element in the same editing host, whose [[localname]] is a formattable block name, and which is not the [[ancestor]] of a prohibited paragraph child, split the parent of the one-[[node]] list consisting of node.

9. Restore the values from values.

10. We have two different behaviors, one for div and p and one for everything else. The basic difference is that for div and p, we assume that it should be one line per element, while for other elements, we put in multiple lines separated by <br>. So if you do formatBlock to p on

    <div>foo</div><div>bar</div>

    or

    foo<br>bar

    you get

    <p>foo</p><p>bar</p>

    but formatBlock to h1 will get you

    <h1>foo<br>bar</h1>.

    IE9 will just change the elements as they are, so it gives <p>foo</p><p>bar</p> and <h1>foo</h1><h1>bar</h1> for <div>foo</div><div>bar</div>, but <p>foo<br>bar</p> and <h1>foo<br>bar</h1> for foo<br>bar. This is unreasonable, because the two possible inputs here look identical to the user and might have been produced by identical user input.

    Firefox 5.0a2 will give results like <p>foo</p><p>bar</p> or <h1>foo</h1><h1>bar</h1> no matter what (modulo oddities in its handling of divs). Opera 11.10 is similar, except it leaves a trailing <br> in the first element.

    Chrome 13 dev will give results like <p>foo<br>bar</p> or <h1>foo<br>bar</h1> no matter what.

    The specced behavior is a compromise between the existing behaviors, predicated on the fact that <h1>foo</h1><h1>bar</h1> almost never makes sense, and <p>foo<br>bar</p> isn't usually what's wanted either.

    While node list is not empty:

    1. If the first member of node list is a single-line container:

       1. If you try to format a single-line container with no children, IE10PP2 inserts an nbsp before formatting. (It uses nbsp instead of <br> to make blocks not collapse, so the equivalent for us would be to insert a <br>.) Firefox 7.0a2 and Opera 11.50 make the element disappear. Chrome 14 dev leaves it alone and doesn't format it. I follow Firefox/Opera just because it's the simplest given how I happen to have written the spec, and it's a corner case, so exact behavior isn't important.

          For blocks that contain only a collapsed whitespace node, IE10PP2 and Firefox 7.0a2 convert them like normal. Chrome 14 dev and Opera 11.50 leave it alone and don't format it. I go with the majority, which is again simpler to spec.

          Let sublist be the [[children]] of the first member of node list.

       2. Record the values of sublist, and let values be the result.
       3. Remove the first member of node list from its [[parent]], preserving its descendants.
       4. Restore the values from values.
       5. Remove the first member from node list.
    2. Otherwise:
       1. Let sublist be an empty list of [[nodes]].
       2. Remove the first member of node list and append it to sublist.
       3. While node list is not empty, and the first member of node list is the [[nextsibling]] of the last member of sublist, and the first member of node list is not a single-line container, and the last member of sublist is not a [[br]], remove the first member of node list and append it to sublist.
    3. Wrap sublist. If value is "div" or "p", sibling criteria returns false; otherwise it returns true for an HTML element with [[localname]] value and no attributes, and false otherwise. New parent instructions return the result of running [[createelement|value]] on the [[contextobject]]. Then fix disallowed ancestors of the result.
11. Return true.

Firefox 6.0a2 throws, Chrome 14 dev always returns false, Opera 11.11 doesn't support indeterm to start with, IE9 was uncooperative in testing so I'm not sure what it does. I'm speccing it just because it makes sense.

Indeterminate:

1. If the active range is null, return the empty string.
2. Block-extend the active range, and let new range be the result.
3. Let node list be all visible editable [[nodes]] that are [[contained]] in new range and have no [[children]].
4. If node list is empty, return false.
5. Let type be null.
6. For each node in node list:
   1. While node's [[parent]] is editable and in the same editing host as node, and node is not an HTML element whose [[localname]] is a formattable block name, set node to its [[parent]].
   2. Let current type be the empty string.
   3. If node is an editable HTML element whose [[localname]] is a formattable block name, and node is not the [[ancestor]] of a prohibited paragraph child, set current type to node's [[localname]].
   4. If type is null, set type to current type.
   5. Otherwise, if type does not equal current type, return true.
7. Return false.

Value:

1. If the active range is null, return the empty string.
2. Block-extend the active range, and let new range be the result.
3. Let node be the first visible editable [[node]] that is [[contained]] in new range and has no [[children]]. If there is no such [[node]], return the empty string.

4. Opera 11.11 doesn't require it be editable, so it will return "DIV" instead of "" for <div contenteditable>foo</div>.

   While node's [[parent]] is editable and in the same editing host as node, and node is not an HTML element whose [[localname]] is a formattable block name, set node to its [[parent]].

5. Chrome 14 dev will report "div" for <div><ol><li>foo</ol></div> or such. Opera 11.11 reports "". IE and Firefox didn't cooperate with testing. Opera makes more sense, and matches the fact that formatBlock now doesn't recognize such a div as a formatBlock candidate, so Opera it is.

   We don't really need to specify "editable" here, since it has to be editable if we got to this point.

   If node is an editable HTML element whose [[localname]] is a formattable block name, and node is not the [[ancestor]] of a prohibited paragraph child, return node's [[localname]], converted to ASCII lowercase.

6. Return the empty string.

The forwardDelete command

This is the same as hitting the delete key (see Additional requirements). It behaves much the same as the delete command, except of course backwards. Also, some of the special cases for backspacing don't apply, as noted in the comments. The one special case you get when deleting forward but not backward is that if the cursor is before a grapheme cluster that consists of multiple characters, like a base character with combining diacritics, we delete the diacritics too. (Backspacing just deletes the last diacritic, so you have to backspace several times to remove the whole cluster.)

Preserves overrides

Copy-pasted from delete, see there for comments.

Action:

1. If the active range is not [[rangecollapsed]], delete the selection and return true.
2. Canonicalize whitespace at the active range's [[rangestart]].
3. Let node and offset be the active range's [[rangestart]] [[node]] and [[bpoffset]].
4. Repeat the following steps:
   1. If offset is the [[length]] of node and node's [[nextsibling]] is an editable invisible [[node]], remove node's [[nextsibling]] from its [[parent]].
   2. Otherwise, if node has a [[child]] with [[index]] offset and that [[child]] is an editable invisible [[node]], remove that [[child]] from node.
   3. Otherwise, if offset is the [[length]] of node and node is an inline node, or if node is invisible, set offset to one plus the [[index]] of node, then set node to its [[parent]].

   4. No special link behavior for forwardDelete here, unlike delete.

      Otherwise, if node has a [[child]] with [[index]] offset and that [[child]] is neither a block node nor a [[br]] nor an [[img]] nor a collapsed block prop, set node to that [[child]], then set offset to zero.

   5. Otherwise, break from this loop.
5. If node is a [[text]] node and offset is not node's [[length]]:
   1. Let end offset be offset plus one.

   2. Firefox 7.0a2, Chrome 14 dev, Word 2007, and OpenOffice.org 3.2.1 Ubuntu act as the spec says, getting rid of all diacritics on forward delete. IE9 and Opera 11.50 have no special case and just delete the next character. I go with Firefox/Chrome/Word/OO.

      However, when I actually type in the text box as opposed to running semi-automated tests, IE9 has magical behavior: it replaces the base character with something that looks like ◌ U+25CC DOTTED CIRCLE. Further strikes of the delete key remove the diacritics, and the circle vanishes along with the last of them. I wasn't able to get it to actually replace the base character, so I'm not sure what the point is. The circle doesn't seem to appear in the DOM, and apparently it disappears in some circumstances. This might be worth standardizing somehow, I don't know.

      TODO: The way we remove diacritics is probably not right. We probably want to normalize to grapheme cluster boundaries, using UAX#29 or something. We also need to handle non-BMP stuff. The idea is that if the cursor is before a character that precedes a combining mark, you need to delete the combining mark too.

      While end offset is not node's [[length]] and the end offsetth [[codeunit]] of node's [[cddata]] has general category M when interpreted as a Unicode code point, add one to end offset.

   3. Call [[selcollapse|node, offset]] on the [[contextobject]]'s [[selection]].
   4. Call [[extend|node, end offset]] on the [[contextobject]]'s [[selection]].
   5. Delete the selection.
   6. Return true.
6. If node is an inline node, return true.
7. If node has a [[child]] with [[index]] offset and that [[child]] is a [[br]] or [[hr]] or [[img]], but is not a collapsed block prop:
   1. Call [[selcollapse|node, offset]] on the [[contextobject]]'s [[selection]].
   2. Call [[extend|node, offset + 1]] on the [[contextobject]]'s [[selection]].
   3. Delete the selection.
   4. Return true.

8. No special list-item behavior for forwardDelete here, unlike delete.

   Let end node equal node and let end offset equal offset.

9. If end node has a [[child]] with [[index]] end offset, and that [[child]] is a collapsed block prop, add one to end offset.
10. Repeat the following steps:
    1. If end offset is the [[length]] of end node, set end offset to one plus the [[index]] of end node and then set end node to its [[parent]].
    2. Otherwise, if end node has an editable invisible [[child]] with [[index]] end offset, remove it from end node.
    3. Otherwise, break from this loop.

11. No special indentation element behavior for forwardDelete here, unlike delete.

    If the [[child]] of end node with [[index]] end offset minus one is a [[table]], return true.

12. If the [[child]] of end node with [[index]] end offset is a [[table]]:
    1. Call [[selcollapse|end node, end offset]] on the [[contextobject]]'s [[selection]].
    2. Call [[extend|end node, end offset + 1]] on the [[contextobject]]'s [[selection]].
    3. Return true.

13. Note, any br will do here: a br immediately after a block is always significant.

    If offset is the [[length]] of node, and the [[child]] of end node with [[index]] end offset is an [[hr]] or [[br]]:

    1. Call [[selcollapse|end node, end offset]] on the [[contextobject]]'s [[selection]].
    2. Call [[extend|end node, end offset + 1]] on the [[contextobject]]'s [[selection]].
    3. Delete the selection.
    4. Call [[selcollapse|node, offset]] on the [[selection]].
    5. Return true.

14. No special list-item behavior for forwardDelete here, unlike delete.

    While end node has a [[child]] with [[index]] end offset:

    1. If end node's [[child]] with [[index]] end offset is editable and invisible, remove it from end node.
    2. Otherwise, set end node to its [[child]] with [[index]] end offset and set end offset to zero.
15. Call [[selcollapse|node, offset]] on the [[contextobject]]'s [[selection]].
16. Call [[extend|end node, end offset]] on the [[contextobject]]'s [[selection]].
17. Delete the selection.

The indent command

Preserves overrides

Action:

1. Let items be a list of all [[li]]s that are [[inclusiveancestors]] of the active range's [[rangestart]] and/or [[rangeend]] [[node]].

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

   For each item in items, normalize sublists of item.

3. Block-extend the active range, and let new range be the result.
4. Let node list be a list of [[nodes]], initially empty.
5. For each [[node]] node [[contained]] in new range, if node is editable and is an allowed child of "div" or "ol" and if the last member of node list (if any) is not an [[ancestor]] of node, append node to node list.

6. Without this step, the last child of the previous sibling might be a list, which the li wouldn't get appended to.

   If the first visible member of node list is an [[li]] whose [[parent]] is an [[ol]] or [[ul]]:

   1. Let sibling be node list's first visible member's [[previoussibling]].
   2. While sibling is invisible, set sibling to its [[previoussibling]].
   3. If sibling is an [[li]], normalize sublists of sibling.
7. While node list is not empty:
   1. Let sublist be a list of [[nodes]], initially empty.
   2. Remove the first member of node list and append it to sublist.
   3. While the first member of node list is the [[nextsibling]] of the last member of sublist, remove the first member of node list and append it to sublist.
   4. Indent sublist.

The insertHorizontalRule command

Preserves overrides

You'd think interop here would be simple, right? Nope: we have three different behaviors across four browsers. Opera 11.00 is the only one that acts more or less like the spec. IE9 and Chrome 12 dev treat the value as an id, which is weird and probably useless, so I don't do it. Firefox 4.0 produces <hr size=2 width=100%> instead of <hr>, which is also weird and almost definitely useless, so I don't do it. Then you have the varying behavior in splitting up parents to ensure validity . . .

Action:

1. Let start node, start offset, end node, and end offset be the active range's [[rangestart]] and [[rangeend]] [[nodes]] and [[bpoffsets]].
2. While start offset is 0 and start node's [[parent]] is not null, set start offset to start node's [[index]], then set start node to its [[parent]].
3. While end offset is end node's [[length]], and end node's [[parent]] is not null, set end offset to one plus end node's [[index]], then set end node to its [[parent]].
4. Call [[selcollapse|start node, start offset]] on the [[contextobject]]'s [[selection]].
5. Call [[extend|end node, end offset]] on the [[contextobject]]'s [[selection]].
6. Delete the selection, with block merging false.
7. If the active range's [[startnode]] is neither editable nor an editing host, return true.

8. We don't want to call insertNode at the start or end of a text node, because that will leave an empty text node.

   If the active range's [[startnode]] is a [[text]] node and its [[startoffset]] is zero, call [[selcollapse|]] on the [[contextobject]]'s [[selection]], with first argument the active range's [[startnode]]'s [[parent]] and second argument the active range's [[startnode]]'s [[index]].

9. If the active range's [[startnode]] is a [[text]] node and its [[startoffset]] is the [[length]] of its [[startnode]], call [[selcollapse|]] on the [[contextobject]]'s [[selection]], with first argument the active range's [[startnode]]'s [[parent]], and the second argument one plus the active range's [[startnode]]'s [[index]].
10. Let hr be the result of calling [[createelement|"hr"]] on the [[contextobject]].
11. Run [[insertnode|hr]] on the active range.

12. IE9 and Chrome 13 dev seem to never break up any ancestors, which can lead to unserializable DOMs like <hr> inside <p>. Opera 11.11 seems to always break up parents going all the way up to the contenteditable root, even ones like <div> that can contain <hr>. Firefox 5.0a2 acts the most sensibly: it only breaks up things like <p> or <b> that shouldn't contain <hr>. The spec goes with Firefox here (although the list of what to break up isn't precisely identical).

    Fix disallowed ancestors of hr.

13. Run [[selcollapse|]] on the [[contextobject]]'s [[selection]], with first argument hr's [[parent]] and the second argument equal to one plus hr's [[index]].
14. Return true.

The insertHTML command

Preserves overrides

Action:

1. Chrome 14 dev and Opera 11.11 do this even if the value is empty. Firefox 5.0a2 throws an exception.

   Firefox 7.0a2 and Chrome 14 dev do strip wrappers here, so inserting HTML in the place of <b>[foo]</b> will remove the <b>. Opera 11.50 keeps the wrappers. I follow the majority and leave the "strip wrappers" flag true.

   Delete the selection.

2. If the active range's [[startnode]] is neither editable nor an editing host, return true.

3. TODO: This has some interesting consequences. For instance, table cells and similar will just vanish if they're not in an appropriate place; and inside a script or style or xmp or such, the argument will effectively be HTML-escaped before use. Some of these consequences might be undesirable.

   Let frag be the result of calling createContextualFragment(value) on the active range.

4. Let last child be the [[lastchild]] of frag.

5. Firefox 5.0a2 also seems to not add empty elements like <b></b>, but Chrome 13 dev and Opera 11.11 do.

   If last child is null, return true.

6. Let descendants be all [[descendants]] of frag.

7. This is so we don't get something like

   <div>[foo]</div>
   -> <div>{}<br></div>
   -> <div><p>Some HTML{}</p><br></div>

   with an extra bogus line break at the end.

   If the active range's [[startnode]] is a block node:

   1. Let collapsed block props be all editable collapsed block prop [[children]] of the active range's [[startnode]] that have [[index]] greater than or equal to the active range's [[startoffset]].
   2. For each node in collapsed block props, remove node from its [[parent]].

8. We could canonicalize whitespace after inserting the fragment, but let's not. If the author wants HTML, give them HTML behavior. When asked to replace a paragraph's contents with a single space, Firefox 7.0a2 does so but inserts a <br> before it (not after); Chrome 14 dev does so and doesn't insert a <br>, so the paragraph collapses; Opera 11.50 doesn't insert the space at all, and just inserts a <br>. Correct behavior is to insert a space, then insert a <br> after it in the next step because it's an invisible node.

   Call [[insertnode|frag]] on the active range.

9. In case we remove all the contents, then remove the extra <br>, then only add a comment or something. In that case we want to re-add the extra <br>. We don't try fixing the actual inserted content: that's the author's lookout.

   If the active range's [[startnode]] is a block node with no visible [[children]], call [[createelement|"br"]] on the [[contextobject]] and append the result as the last child of the active range's [[startnode]].

10. Need to do this before fixing disallowed ancestors, since otherwise the last child might have been removed (e.g., it's an li).

    Call [[selcollapse|]] on the [[contextobject]]'s [[selection]], with last child's [[parent]] as the first argument and one plus its [[index]] as the second.

11. We want to fix all descendants, not just children. Consider <div><li>foo</li></div>, for example.

    Fix disallowed ancestors of each member of descendants.

12. Return true.

The insertImage command

Preserves overrides

Action:

1. Similar logic to createLink, except even more compelling, since an HTML document linking to itself as an image is just silly. In fact, the current HTML spec instructs UAs to not even try displaying the image, and just fail immediately if the URL is empty. Firefox 4b11 silently does nothing on an empty string, but the other three browsers I tested stick in the <img> anyway.

   If value is the empty string, return false.

2. Firefox 7.0a2 seems to strip the wrapper or not depending on the exact positioning of the selection: <b>{foo}</b> yes, <b>[foo]</b> no. Chrome 14 dev seems to strip the wrapper regardless. Opera 11.50 seems to keep the wrapper, but place the image outside it. I didn't get IE to cooperate with my tests. I chose to leave wrappers across the board because they might be meaningful: e.g., a background-color when the image is small or not fully opaque.

   Delete the selection, with strip wrappers false.

3. Let range be the active range.
4. If the active range's [[startnode]] is neither editable nor an editing host, return true.

5. Same logic as with insertHTML.

   If range's [[startnode]] is a block node whose sole [[child]] is a [[br]], and its [[startoffset]] is 0, remove its [[startnode]]'s [[child]] from it.

6. Let img be the result of calling [[createelement|"img"]] on the [[contextobject]].

7. No alt text, so it's probably invalid. This matches all browsers.

   Run [[setattribute|"src", value]] on img.

8. This winds up putting it at the original start point of the active range, as currently specced. This matches IE9 and Firefox 5.0a2. Chrome 13 dev puts it at the end point, and Opera 11.11 puts it in between (where the range would collapse if you called deleteContents()).

   Run [[insertnode|img]] on range.

9. Let selection be the result of calling [[getselection]] on the [[contextobject]].
10. Run [[selcollapse|]] on selection, with first argument equal to the [[parent]] of img and the second argument equal to one plus the [[index]] of img.
11. Return true.

The insertLineBreak command

This is the same as hitting Shift-Enter or such (see Additional requirements). It deletes the selection, and replaces it with a <br>. No real complications.

Preserves overrides

Action:

1. IE9 doesn't strip wrappers (IE10PP2 didn't work in tests). Firefox 7.0a2 strips wrappers inconsistently depending on the exact selection endpoints. Chrome 14 dev strips wrappers but recreates any styles using new wrappers. Opera 11.50 strips all wrappers.

   Delete the selection, with strip wrappers false.

2. If the active range's [[startnode]] is neither editable nor an editing host, return true.

3. script, xmp, table, . . .

   If the active range's [[startnode]] is an [[element]], and "br" is not an allowed child of it, return true.

4. If the active range's [[startnode]] is not an [[element]], and "br" is not an allowed child of the active range's [[startnode]]'s [[parent]], return true.

5. We don't want to call insertNode at the start or end of a text node, because that will leave an empty text node.

   If the active range's [[startnode]] is a [[text]] node and its [[startoffset]] is zero, call [[selcollapse|]] on the [[contextobject]]'s [[selection]], with first argument equal to the active range's [[startnode]]'s [[parent]] and second argument equal to the active range's [[startnode]]'s [[index]].

6. If the active range's [[startnode]] is a [[text]] node and its [[startoffset]] is the [[length]] of its [[startnode]], call [[selcollapse|]] on the [[contextobject]]'s [[selection]], with first argument equal to the active range's [[startnode]]'s [[parent]] and second argument equal to one plus the active range's [[startnode]]'s [[index]].
7. Let br be the result of calling [[createelement|"br"]] on the [[contextobject]].
8. Call [[insertnode|br]] on the active range.
9. Call [[selcollapse|]] on the [[contextobject]]'s [[selection]], with br's [[parent]] as the first argument and one plus br's [[index]] as the second argument.
10. If br is a collapsed line break, call [[createelement|"br"]] on the [[contextobject]] and let extra br be the result, then call [[insertnode|extra br]] on the active range.
11. Return true.

The insertOrderedList command

Preserves overrides

Action: Toggle lists with tag name "ol", then return true.

Firefox 6.0a2 sort of supports this, but it throws exceptions most of the time. It has the quirk that even if there are no ol's around, it will say it's indeterminate if there are some things that are ul's and some that are not lists at all, but this doesn't make sense and I don't duplicate it. No one else supports indeterminate for insert*List, but it makes sense if you support state.

Indeterminate: True if the selection's list state is "mixed" or "mixed ol", false otherwise.

IE9 throws exceptions in most cases, Firefox 6.0a2 in some cases as well, for no apparent reason. Ignoring those, the spec basically matches all browsers, except with a few weird random mismatches that looked like browser bugs to me.

State: True if the selection's list state is "ol", false otherwise.

The insertParagraph command

Preserves overrides

Action:

1. Delete the selection.
2. If the active range's [[startnode]] is neither editable nor an editing host, return true.
3. Let node and offset be the active range's [[rangestart]] [[node]] and [[bpoffset]].
4. If node is a [[text]] node, and offset is neither 0 nor the [[length]] of node, call [[splittext|offset]] on node.
5. If node is a [[text]] node and offset is its [[length]], set offset to one plus the [[index]] of node, then set node to its [[parent]].
6. If node is a [[text]] or [[comment]] node, set offset to the [[index]] of node, then set node to its [[parent]].
7. Call [[selcollapse|node, offset]] on the [[contextobject]]'s [[selection]].
8. Let container equal node.
9. While container is not a single-line container, and container's [[parent]] is editable and in the same editing host as node, set container to its [[parent]].

10. Bug 13841.

    If container is an editable single-line container in the same editing host as node, and its [[localname]] is "p" or "div":

    1. Let outer container equal container.
    2. While outer container is not a [[dd]] or [[dt]] or [[li]], and outer container's [[parent]] is editable, set outer container to its [[parent]].
    3. If outer container is a [[dd]] or [[dt]] or [[li]], set container to outer container.

11. We add the default wrapper in this case.

    If container is not editable or not in the same editing host as node or is not a single-line container:

    1. Let tag be the default single-line container name.
    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. Append to node list the first [[node]] in [[treeorder]] that is [[contained]] in new range and is an allowed child of "p", if any.
    5. If node list is empty:

       1. Ideally, we should normalize things so that the cursor is never in a weird place after deletion, but let's be safe and bail out if we do hit this scenario. It's not clear if we need this line in the long term, but at the time of this writing there's at least one corner case where deleting can leave the cursor inside a <tr>.

          If tag is not an allowed child of the active range's [[startnode]], return true.

       2. Set container to the result of calling [[createelement|tag]] on the [[contextobject]].
       3. Call [[insertnode|container]] on the active range.
       4. Call [[createelement|"br"]] on the [[contextobject]], and append the result as the last [[child]] of container.
       5. Call [[selcollapse|container, 0]] on the [[contextobject]]'s [[selection]].
       6. Return true.

    6. TODO: It is not at all obvious that this is the correct list of nodes in all cases. It should probably work because of how the block-extend algorithm works, but further thought would be good.

       While the [[nextsibling]] of the last member of node list is not null and is an allowed child of "p", append it to node list.

    7. Wrap node list, with sibling criteria returning false and new parent instructions returning the result of calling [[createelement|tag]] on the [[contextobject]]. Set container to the result.

12. IE9 and Chrome 13 dev just break <pre> up into multiple <pre>s. Firefox 5.0a2 and Opera 11.10 insert a <br> instead, treating it differently from <p>. The latter makes more sense. What might make the most sense is to just insert an actual newline character, though, since this is a pre after all . . .

    IE9 and Chrome 13 dev also break <address> up into multiple <address>es. Firefox 5.0a2 inserts <br> instead. Opera 11.10 nests <p>s inside. I don't like Opera's behavior, because it means we nest formatBlock candidates inside one another, so I'll go with Firefox.

    listing and xmp work the same as pre in all browsers. For Firefox and Opera, this results in trying to put a br inside an xmp, so I go with IE/Chrome for xmp.

    TODO: In cases where hitting enter in a header doesn't break out of the header, we should probably follow this code path too, instead of creating an adjoining header. No browser does this, though, so we don't.

    If container's [[localname]] is "address", "listing", or "pre":

    1. Let br be the result of calling [[createelement|"br"]] on the [[contextobject]].
    2. Call [[insertnode|br]] on the active range.
    3. Call [[selcollapse|node, offset + 1]] on the [[contextobject]]'s [[selection]].

    4. Necessary because adding a br to the end of a block element does nothing if there wasn't one there already. A single newline immediately preceding a block boundary does nothing.

       If br is the last [[descendant]] of container, let br be the result of calling [[createelement|"br"]] on the [[contextobject]], then call [[insertnode|br]] on the active range.

    5. Return true.

13. Including dt/dd here follows Firefox 5.0a2, as with the special dt/dd handling below.

    If container's [[localname]] is "li", "dt", or "dd"; and either it has no [[children]] or it has a single [[child]] and that [[child]] is a [[br]]:

    1. Split the parent of the one-[[node]] list consisting of container.
    2. If container has no [[children]], call [[createelement|"br"]] on the [[contextobject]] and append the result as the last [[child]] of container.

    3. Annoying hack to prevent the dl from being re-added when fixing disallowed ancestors. In most cases we want a wrapper dl added, but in two cases (delete and insertParagraph) we're actually trying to outdent the list item. TODO: there might be a better way to do this.

       If container is a [[dd]] or [[dt]], and it is not an allowed child of any of its [[ancestors]] in the same editing host, set the tag name of container to the default single-line container name and let container be the result.

    4. Fix disallowed ancestors of container.
    5. Return true.
14. Let new line range be a new [[range]] whose [[rangestart]] is the same as the active range's, and whose [[rangeend]] is (container, [[length]] of container).

15. We don't want the start to be just inside a node, because if it is, we'll leave behind an empty element either in the new or old container. Empty block nodes are fine, and we'll add a [[br]] later, but empty inline nodes are bad, since the user can't interact with them.

    While new line range's [[startoffset]] is zero and its [[startnode]] is not a prohibited paragraph child, set its [[rangestart]] to ([[parent]] of [[startnode]], [[index]] of [[startnode]]).

16. While new line range's [[startoffset]] is the [[length]] of its [[startnode]] and its [[startnode]] is not a prohibited paragraph child, set its [[rangestart]] to ([[parent]] of [[startnode]], 1 + [[index]] of [[startnode]]).
17. Let end of line be true if new line range [[contains]] either nothing or a single [[br]], and false otherwise.

18. IE9 makes a new header if there's a trailing <br>. Firefox 5.0a2, Chrome 13 dev, and Opera 11.10 do not, and I follow them, since it makes more sense (such a <br> is invisible).

    If the [[localname]] of container is "h1", "h2", "h3", "h4", "h5", or "h6", and end of line is true, let new container name be the default single-line container name.

19. This step and the next follow Firefox 5.0a2. IE9 and Chrome 13 dev act as though these two lines were not present (they clone the existing element). Opera 11.10 nests a <p> inside. Firefox is the most useful, assuming a definition list somehow winds up inside the content (like via formatBlock).

    Otherwise, if the [[localname]] of container is "dt" and end of line is true, let new container name be "dd".

20. Otherwise, if the [[localname]] of container is "dd" and end of line is true, let new container name be "dt".
21. Otherwise, let new container name be the [[localname]] of container.
22. Let new container be the result of calling [[createelement|new container name]] on the [[contextobject]].
23. Copy all attributes of container to new container.
24. If new container has an [[id]] attribute, unset it.
25. Insert new container into the [[parent]] of container immediately after container.
26. Let contained nodes be all [[nodes]] [[contained]] in new line range.

27. TODO: This blows up any ranges (other than the selection, which we reset), and can alter non-editable nodes, and maybe other bad stuff. May or may not be the best solution. The intermediate fragment is also possibly black-box detectable by DOM mutation events, but I like to pretend those don't exist.

    Let frag be the result of calling [[extractcontents]] on new line range.

28. Unset the [[id]] attribute (if any) of each [[element]] [[descendant]] of frag that is not in contained nodes.
29. Call [[appendchild|frag]] on new container.

30. Needed in case we have something like {{code|

    1. []foo

    }}, which becomes {{code|

    2. foo

    }}. In this case we want to add the [[br]] to the [[p]], not the [[li]]. Likewise for {{code|

    1. foo[]

    }}.

    While container's [[lastchild]] is a prohibited paragraph child, set container to its [[lastchild]].

31. While new container's [[lastchild]] is a prohibited paragraph child, set new container to its [[lastchild]].
32. If container has no visible [[children]], call [[createelement|"br"]] on the [[contextobject]], and append the result as the last [[child]] of container.

33. These two steps follow Firefox 5.0a2, Chrome 13 dev, and Opera 11.10. IE9 instead inserts an &nbsp; which magically does not appear in innerHTML. In all cases, the reason is that an empty block box in CSS will have zero height, so the user won't be able to put the selection cursor inside it.

    If new container has no visible [[children]], call [[createelement|"br"]] on the [[contextobject]], and append the result as the last [[child]] of new container.

34. Call [[selcollapse|new container, 0]] on the [[contextobject]]'s [[selection]].
35. Return true.

The insertText command

Action:

1. Chrome 14 dev does the deletion even if the value is empty. Of course, other browsers don't expose this as an execCommand(), so no one else has any defined behavior in this case at all, so I follow Chrome.

   IE9, Firefox 7.0a2, Chrome 14 dev, and Opera 11.50 all don't strip wrappers, except that as usual, Gecko does if you select the whole wrapper, like {<b>foo</b>}. Also, Chrome 14 dev seems to strip the wrapper and try recreating the style in cases like <b>[foo</b>bar], where it starts in a wrapper but ends after it; this doesn't always work so well, so I don't do it. Firefox 7.0a2 also has the deletion set overrides for indeterminate state commands, so if you run insertText on [foo<b>bar</b>baz] it will make the result bold.

   These things don't make any sense to me, so I don't do them. I set overrides based on the first editable text node in the range when deleting; preserve any wrappers at the start of the range; and restore the overrides in case preserving the wrappers isn't enough (like if they weren't set by deletion at all). This behavior seems to closely match IE9.

   Delete the selection, with strip wrappers false.

2. If the active range's [[startnode]] is neither editable nor an editing host, return true.
3. If value's [[strlen]] is greater than one:
   1. For each [[codeunit]] el in value, take the action for the insertText command, with value equal to el.
   2. Return true.
4. If value is the empty string, return true.

5. TODO: WebKit also does magic for tabs, wrapping them in a whitespace-preserving span. Should we?

   If value is a newline (U+00A0), take the action for the insertParagraph command and return true.

6. Let node and offset be the active range's [[startnode]] and [[bpoffset]].

7. Just to be tidy, add to an existing text node if there is one. Firefox 5.0a2 only adds to an existing one if the range is in a text node. IE9, Chrome 14 dev, and Opera 11.11 also add to an existing text node if the range is in an element adjacent to a text node. If there are two text nodes and it's in between, like foo{}bar, IE and Opera add to the first, Chrome adds to the second, although it probably doesn't matter in practice exactly which we choose.

   If node has a [[child]] whose [[index]] is offset − 1, and that [[child]] is a [[text]] node, set node to that [[child]], then set offset to node's [[length]].

8. If node has a [[child]] whose [[index]] is offset, and that [[child]] is a [[text]] node, set node to that [[child]], then set offset to zero.
9. Record current overrides, and let overrides be the result.
10. Call [[selcollapse|node, offset]] on the [[contextobject]]'s [[selection]].
11. Canonicalize whitespace at (node, offset).
12. Let (node, offset) be the active range's [[rangestart]].
13. If node is a [[text]] node:
    1. Call [[insertdata|offset, value]] on node.
    2. Call [[selcollapse|node, offset]] on the [[contextobject]]'s [[selection]].
    3. Call [[extend|node, offset + 1]] on the [[contextobject]]'s [[selection]].
14. Otherwise:

    1. If some text is inserted into <p><br></p> or similar, we no longer need the <br>.

       If node has only one [[child]], which is a collapsed line break, remove its [[child]] from it.

    2. Let text be the result of calling [[createtextnode|value]] on the [[contextobject]].
    3. Call [[insertnode|text]] on the active range.
    4. Call [[selcollapse|text, 0]] on the [[contextobject]]'s [[selection]].
    5. Call [[extend|text, 1]] on the [[contextobject]]'s [[selection]].
15. Restore states and values from overrides.
16. Canonicalize whitespace at the active range's [[rangestart]], with fix collapsed space false.
17. Canonicalize whitespace at the active range's [[rangeend]], with fix collapsed space false.
18. If value is a [[spacecharacter]], autolink the active range's [[rangestart]].
19. Call [[collapsetoend]] on the [[contextobject]]'s [[selection]].
20. Return true.

The insertUnorderedList command

Preserves overrides

See comments for insertOrderedList.

Action: Toggle lists with tag name "ul", then return true.

Indeterminate: True if the selection's list state is "mixed" or "mixed ul", false otherwise.

State: True if the selection's list state is "ul", false otherwise.

The justifyCenter command

Preserves overrides

Action: Justify the selection with alignment "center", then return true.

Indeterminate: Return false if the active range is null. Otherwise, block-extend the active range. Return true if among visible editable [[nodes]] that are [[contained]] in the result and have no [[children]], at least one has alignment value "center" and at least one does not. Otherwise return false.

State: Return false if the active range is null. Otherwise, block-extend the active range. Return true if there is at least one visible editable [[node]] that is [[contained]] in the result and has no [[children]], and all such [[nodes]] have alignment value "center". Otherwise return false.

Not bidi-safe, but it's a pretty marginal corner case where it fails. Firefox 6.0a2 behaves weirdly here: it keys off the start node of the active range, even if that's not contained. Thus {<div align=center>foo</div>} has value "left" and indeterminate false, which would suggest that the whole selection is aligned left, but that's not the case. Chrome 14 dev returns the state cast to a string, as usual. Opera 11.11 always returns the empty string.

Value: Return the empty string if the active range is null. Otherwise, block-extend the active range, and return the alignment value of the first visible editable [[node]] that is [[contained]] in the result and has no [[children]]. If there is no such [[node]], return "left".

The justifyFull command

Preserves overrides

Action: Justify the selection with alignment "justify", then return true.

Indeterminate: Return false if the active range is null. Otherwise, block-extend the active range. Return true if among visible editable [[nodes]] that are [[contained]] in the result and have no [[children]], at least one has alignment value "justify" and at least one does not. Otherwise return false.

State: Return false if the active range is null. Otherwise, block-extend the active range. Return true if there is at least one visible editable [[node]] that is [[contained]] in the result and has no [[children]], and all such [[nodes]] have alignment value "justify". Otherwise return false.

Value: Return the empty string if the active range is null. Otherwise, block-extend the active range, and return the alignment value of the first visible editable [[node]] that is [[contained]] in the result and has no [[children]]. If there is no such [[node]], return "left".

The justifyLeft command

Preserves overrides

Action: Justify the selection with alignment "left", then return true.

Indeterminate: Return false if the active range is null. Otherwise, block-extend the active range. Return true if among visible editable [[nodes]] that are [[contained]] in the result and have no [[children]], at least one has alignment value "left" and at least one does not. Otherwise return false.

State: Return false if the active range is null. Otherwise, block-extend the active range. Return true if there is at least one visible editable [[node]] that is [[contained]] in the result and has no [[children]], and all such [[nodes]] have alignment value "left". Otherwise return false.

Value: Return the empty string if the active range is null. Otherwise, block-extend the active range, and return the alignment value of the first visible editable [[node]] that is [[contained]] in the result and has no [[children]]. If there is no such [[node]], return "left".

The justifyRight command

Preserves overrides

Action: Justify the selection with alignment "right", then return true.

Indeterminate: Return false if the active range is null. Otherwise, block-extend the active range. Return true if among visible editable [[nodes]] that are [[contained]] in the result and have no [[children]], at least one has alignment value "right" and at least one does not. Otherwise return false.

State: Return false if the active range is null. Otherwise, block-extend the active range. Return true if there is at least one visible editable [[node]] that is [[contained]] in the result and has no [[children]], and all such [[nodes]] have alignment value "right". Otherwise return false.

Value: Return the empty string if the active range is null. Otherwise, block-extend the active range, and return the alignment value of the first visible editable [[node]] that is [[contained]] in the result and has no [[children]]. If there is no such [[node]], return "left".

The outdent command

Preserves overrides

Action:

1. Let items be a list of all [[li]]s that are [[inclusiveancestors]] of the active range's [[rangestart]] and/or [[rangeend]] [[node]].

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

   For each item in items, normalize sublists of item.

3. Block-extend the active range, and let new range be the result.
4. Let node list be a list of [[nodes]], initially empty.

5. This step is kind of weird. For regular outdenting, we start at the inside and outdent going out, so that we remove the innermost indentation, on the theory that that will produce the cleanest markup (remove the most nodes). For lists, we remove the outermost indentation, because it makes a difference whether we remove inner or outer indentation, and logically we want to remove outer. E.g.,

   <ol><li>foo</li><ul><li>bar</li></ul></ol>

   should become

   foo<ul><li>bar</li></ul>

   not

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

   But this is a bit weird and I'm wondering if it's really correct. TODO: Reexamine this.

   For each [[node]] node [[contained]] in new range, append node to node list if the last member of node list (if any) is not an [[ancestor]] of node; node is editable; and either node has no editable [[descendants]], or is an [[ol]] or [[ul]], or is an [[li]] whose [[parent]] is an [[ol]] or [[ul]].

6. While node list is not empty:
   1. While the first member of node list is an [[ol]] or [[ul]] or is not the [[child]] of an [[ol]] or [[ul]], outdent it and remove it from node list.
   2. If node list is empty, break from these substeps.
   3. Let sublist be a list of [[nodes]], initially empty.
   4. Remove the first member of node list and append it to sublist.
   5. While the first member of node list is the [[nextsibling]] of the last member of sublist, and the first member of node list is not an [[ol]] or [[ul]], remove the first member of node list and append it to sublist.
   6. Record the values of sublist, and let values be the result.
   7. Split the parent of sublist.
   8. Fix disallowed ancestors of each member of sublist.
   9. Restore the values from values.
7. Return true.

Miscellaneous commands

The copy command

IE9 supports copy/cut/paste with a security warning. Firefox reportedly only supports it if you set a pref. I didn't find info on other browsers, but in my tests it didn't do anything. I'm not going to try speccing it unless implementers are interested in working out the security problems and trying to get interop. It seems like as of June 2011, everyone just uses Flash for this. So it would be nice if we could work out a more secure standardized substitute.

Action: The user agent must either copy the current selection to the clipboard as though the user had requested it, or [[throw]] a [[SecurityError]] exception. This specification does not define exactly how the selection is to be copied to the clipboard, but the Clipboard API and events specification might be useful.

User agents should exercise caution in respecting this command, because sites could abuse it to confuse and annoy the user by overwriting the clipboard with extremely long, obscene, or otherwise objectionable content.

The idea is sites might catch the SECURITY_ERR and treat it differently from NOT_SUPPORTED_ERR, like encouraging users to reconfigure their browser. However, browsers might not want to encourage authors to tell users to reconfigure their browser insecurely.

User agents may choose not to support this command at all. If a user agent will only honor the command for some whitelisted sites depending on configuration, it may either [[throw]] a [[SecurityError]] exception for non-whitelisted sites, or it may act as though the command is unsupported on those sites.

The cut command

See comment for copy.

Action: The user agent must either copy the current selection to the clipboard and then delete it, as though the user had requested it, or [[throw]] a [[SecurityError]] exception. This specification does not define exactly how the selection is to be deleted or copied to the clipboard, but the Clipboard API and events specification might be useful.

User agents should exercise caution in respecting this command, because sites could abuse it to confuse and annoy the user by overwriting the clipboard with extremely long, obscene, or otherwise objectionable content.

User agents may choose not to support this command at all. If a user agent will only honor the command for some whitelisted sites depending on configuration, it may either [[throw]] a [[SecurityError]] exception for non-whitelisted sites, or it may act as though the command is unsupported on those sites.

The defaultParagraphSeparator command

This is a new feature, added by request in bug 15527. (Opera already had an o-defaultblock command that worked similarly.) If you are implementing this, please make sure to file any feedback as bugs. The spec is not finalized yet and can still be easily changed.

Action: Let value be converted to ASCII lowercase. If value is then equal to "p" or "div", set the [[contextobject]]'s default single-line container name to value, then return true. Otherwise, return false.

Value: Return the [[contextobject]]'s default single-line container name.

The paste command

See comment for copy.

Action: The user agent must either delete the selection and then paste the clipboard's contents to the current cursor position, as though the user had requested it, or [[throw]] a [[SecurityError]] exception. This specification does not define exactly how the clipboard is to be converted to HTML for pasting, but the Clipboard API and events specification might be useful.

User agents should exercise caution in respecting this command, because sites could abuse it to read private information from the clipboard.

User agents may choose not to support this command at all. If a user agent will only honor the command for some whitelisted sites depending on configuration, it may either [[throw]] a [[SecurityError]] exception for non-whitelisted sites, or it may act as though the command is unsupported on those sites.

The redo command

Action: As defined by the UndoManager specification.

The selectAll command

This is totally broken: if executed inside an editing host, it has to select the editing host contents, not the whole document. See bug.

Action:

1. TODO: Is this right even for framesets?

   Let target be the body element of the [[contextobject]].

   TODO: Is this right even for documents whose root element is not an HTML element?

   If target is null, let target be the [[contextobject]]'s documentElement.

2. If target is null, call [[getselection]] on the [[contextobject]], and call [[removeallranges]] on the result.
3. Otherwise, call [[getselection]] on the [[contextobject]], and call [[selectallchildren|target]] on the result.
4. Return true.

The styleWithCSS command

Action: If value is an ASCII case-insensitive match for the string "false", set the CSS styling flag to false. Otherwise, set the CSS styling flag to true. Either way, return true.

This follows Chrome 13 dev. Firefox 5.0a2 doesn't support queryCommandState() for styleWithCSS.

State: True if the CSS styling flag is true, otherwise false.

The undo command

Action: As defined by the UndoManager specification.

The useCSS command

Action: If value is an ASCII case-insensitive match for the string "false", set the CSS styling flag to true. Otherwise, set the CSS styling flag to false. Either way, return true.

Since the effect of this command is the opposite of what one would expect, user agents are encouraged to point authors to styleWithCSS when useCSS is used, such as by logging a warning to an error console.

No state is defined for this command, so queryCommandState("useCSS") must always return false. To query the CSS styling flag's current value, authors have to use the styleWithCSS command.

Additional requirements

It has been suggested that some things here need to be platform-dependent, not fully standardized. For now I'm standardizing them anyway, because the large majority of behavior should be platform-agnostic. If anyone has suggestions as to particular things that should be left up to platform behavior, please say so.

When the user instructs the user agent to insert a line break inside an editing host, such as by pressing the Enter key while the cursor is in an editable [[node]], the user agent must call execCommand("insertparagraph") on the relevant [[document]].

When the user instructs the user agent to insert a line break inside an editing host without breaking out of the current block, such as by pressing Shift-Enter or Option-Enter while the cursor is in an editable [[node]], the user agent must call execCommand("insertlinebreak") on the relevant [[document]].

When the user instructs the user agent to delete the previous character inside an editing host, such as by pressing the Backspace key while the cursor is in an editable [[node]], the user agent must call execCommand("delete") on the relevant [[document]].

When the user instructs the user agent to delete the next character inside an editing host, such as by pressing the Delete key while the cursor is in an editable [[node]], the user agent must call execCommand("forwarddelete") on the relevant [[document]].

When the user instructs the user agent to insert text inside an editing host, such as by typing on the keyboard while the cursor is in an editable [[node]], the user agent must call execCommand("inserttext", false, value) on the relevant [[document]], with value equal to the text the user provided. If the user inserts multiple characters at once or in quick succession, this specification does not define whether it is treated as one insertion or several consecutive insertions.

Bug 13938.

The user agent may allow the user to make other changes to editable content, such as causing Ctrl-B to call execCommand("bold"). Any such change must be accomplished by calling execCommand(), so that in particular, "beforeinput" and "input" events fire as appropriate. The command invoked should be one of the standard commands defined in this specification if possible, and otherwise must be a vendor-specific command.

Acknowledgements

This section is not normative.

Thanks to:

• Google and Mozilla, for funding this work
• Ian Hickson, for overseeing it initially
• Ian Hickson and Ms2ger, for starting the selection work
• Julie Parent, Ojan Vafai, Alex Russel, and Eric Seidel for their research on how browsers and other rich text editors behave in many common scenarios
• Ehsan Akhgari, Tab Atkins, Mathias Bynens, Tim Down, Markus Ernst, Daniel Glazman, Tali Gregor (née Fuss), Stig Halvorsen, Jeff Harris, Ian Hickson, Cameron Heavon-Jones, Anne van Kesteren, Alfonso Martínez de Lizarrondo, Glenn Maynard, Ms2ger, Ryosuke Niwa, Robert O'Callahan, Julie Parent, Simon Pieters, Michael A. Puls II, Rich Schwerdtfeger, Jonas Sicking, Henri Sivonen, Smylers, Hallvord R. M. Steen, Roland Steiner, Annie Sullivan, timeless, Ojan Vafai, Brett Zamir, and Boris Zbarsky for their feedback, participation, or other helpful contributions