Movatterモバイル変換

Properties of commands

This specification defines a number ofcommands, identified byASCII case-insensitive strings. Eachcommand can have several pieces of data associated with it:

• Action: What thecommand does when executed viaexecCommand(). Everycommand defined in this specification has anaction defined for it in the relevant section. For example,thebold command'saction generally makes the current selection bold, or removes bold if the selection is already bold. An editing toolbar might provide buttons that execute theaction for acommand if clicked, or a script might run anaction without user interaction to achieve some particular effect. Actions return either true or false, which can affect the return value ofexecCommand().
• Indeterminate: A boolean value returned byqueryCommandIndeterm(), depending on the current state of the document. Generally, acommand that has astate defined will beindeterminate if thestate is true for part but not all of the current selection, and acommand that has avalue defined will beindeterminate if different parts of the selection have differentvalues. An editing toolbar might display a button or control in a special way if thecommand isindeterminate, like showing a "bold" button as partially depressed, or leaving a font size selector blank instead of showing the font size of the current selection. As a rule, acommand can only beindeterminate if itsstate is false, supposing it has astate.
• State: A boolean value returned byqueryCommandState(), depending on the current state of the document. Thestate of acommand is true if it is already in effect, in some sense specific to thecommand. Mostcommands that have astate defined will take oppositeactions depending on whether thestate is true or false, such as making the selection bold if thestate is false and removing bold if thestate is true. Others will just have no effect if thestate is true, likethejustifyCenter command. Still others will have the same effect regardless, likethestyleWithCss command. An editing toolbar might display a button or control differently depending on thestate andindeterminacy of thecommand.
• Value: A string returned byqueryCommandValue(), depending on the current state of the document. Acommand usually has avalue instead of astate if the property it modifies can take more than two different values, liketheforeColor command. If thecommand isindeterminate, itsvalue is generally based on the start of the selection. Otherwise, in most cases thevalue holds true for the entire selection, but seethejustifyCenter command anditsthreecompanions for an exception. An editing toolbar might display thevalue of acommand as selected in a drop-down or filled in in a text box, if thecommand isn'tindeterminate.
• Relevant CSS property: This is defined for certaininline formatting commands, and is used in algorithms specific to those commands. It is an implementation detail, and is not exposed to authors. If acommand does not have arelevant CSS property specified, it defaults to null.

Supported commands

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

Somecommands will besupported in a given user agent, and some will not. Allcommands defined in this specification must besupported, except optionallythecopy command,thecut command, and/orthepaste command. Additionalvendor-specific commands can also besupported, but implementers must prefix anyvendor-specific command names with a vendor-specific string (e.g., "ms", "moz", "webkit", "opera").

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

Acommand that does absolutely nothing in a particular user agent, such thatexecCommand() never has any effect andqueryCommandEnabled() andqueryCommandIndeterm() andqueryCommandState() andqueryCommandValue() each return the same value all the time, must not besupported.

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

Authors can tell whether acommand issupported usingqueryCommandSupported().

Enabled commands

At any given time, asupported command can be eitherenabled or not. Authors can tell whether acommand is currentlyenabled usingqueryCommandEnabled().Commands that are notenabled do nothing, as described in the definitions of the various methods that invokecommands.

Amongcommands defined in this specification, those listed inMiscellaneous commands are alwaysenabled, except forthecut command andthepaste command. The othercommands defined here areenabled if theactive range is not null, its [=range/start node=] is eithereditable or an [=editing host=], theediting host of its [=range/start node=] is not anEditContext editing host, its [=range/end node=] is eithereditable or an [=editing host=], theediting host of its [=range/end node=] is not anEditContext editing host, and there is some [=editing host=] that is an [=tree/inclusive ancestor=] of both its [=range/start node=] and its [=range/end node=].

Assorted common algorithms

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

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

1. Letnode be the movednode,old parent andold index be the old [=tree/parent=] (which may be null) and [=tree/index=], andnew parent andnew index be the new [=tree/parent=] and [=tree/index=].

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

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

3. If a [=boundary point=]'snode isnew parent and its [=boundary point/offset=] is greater thannew index, add one to its [=boundary point/offset=].
4. If a [=boundary point=]'snode isold parent and its [=boundary point/offset=] isold index orold index + 1, set itsnode tonew parent and addnew index −old index to its [=boundary point/offset=].
5. If a [=boundary point=]'snode isold parent and its [=boundary point/offset=] is greater thanold index + 1, subtract one from its [=boundary point/offset=].

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

Toset the tag name of an {{Element}}element tonew name:

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

1. Ifelement is anHTML element with [=Element/local name=] equal tonew name, returnelement.
2. Ifelement's [=tree/parent=] is null, returnelement.
3. Letreplacement element be the result of callingcreateElement(new name) on the {{Node/ownerDocument}} ofelement.
4. Insertreplacement element intoelement's [=tree/parent=] immediately before element.
5. Copy all attributes ofelement toreplacement element, in order.
6. Whileelement has [=tree/children=], append the first [=tree/child=] ofelement as the last [=tree/child=] ofreplacement element,preserving ranges.
7. Removeelement from its [=tree/parent=].
8. Returnreplacement element.

Toremove extraneous line breaks before anodenode:

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

1. Letref be the {{Node/ previousSibling}} ofnode.
2. Ifref is null, abort these steps.
3. Whileref has [=tree/children=], setref to its {{Node/lastChild}}.
4. Whileref isinvisible but not anextraneous line break, andref does not equalnode's [=tree/parent=], setref to thenode before it in [=tree order=].
5. Ifref is aneditableextraneous line break, remove it from its [=tree/parent=].

Toremove extraneous line breaks at the end of anodenode:

1. Letref benode.
2. Whileref has [=tree/children=], setref to its {{Node/lastChild}}.
3. Whileref isinvisible but not anextraneous line break, andref does not equalnode, setref to thenode before it in [=tree order=].
4. Ifref is aneditableextraneous line break:

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

      Whileref's [=tree/parent=] iseditable andinvisible, setref to its [=tree/parent=].

   2. Removeref from its [=tree/parent=].

Toremove extraneous line breaks from anode, firstremove extraneous line breaks before it, thenremove extraneous line breaks at the end of it.

Wrapping a list of nodes

Towrap a listnode list of consecutive [=tree/sibling=]nodes, run the following algorithm. In addition tonode list, the algorithm accepts two inputs: an algorithmsibling criteria that accepts anode as input and outputs a boolean, and an algorithmnew parent instructions that accepts nothing as input and outputs anode or null. If not provided,sibling criteria returns false andnew parent instructions returns null.

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

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

   If every member ofnode list isinvisible, and none is a [^br^], return null and abort these steps.

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

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

   Ifnode list's last member is aninline node that's not a [^br^], andnode list's last member's {{Node/nextSibling}} is a [^br^], append that [^br^] tonode list.

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

   Whilenode list's first member's {{Node/previousSibling}} isinvisible, prepend it tonode list.

5. Whilenode list's last member's {{Node/nextSibling}} isinvisible, append it tonode list.
6. If the {{Node/previousSibling}} of the first member ofnode list iseditable and runningsibling criteria on it returns true, letnew parent be the {{Node/previousSibling}} of the first member ofnode list.
7. Otherwise, if the {{Node/ nextSibling}} of the last member ofnode list iseditable and runningsibling criteria on it returns true, letnew parent be the {{Node/nextSibling}} of the last member ofnode list.
8. Otherwise, runnew parent instructions, and letnew parent be the result.

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

   Ifnew parent is null, abort these steps and return null.

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

    Ifnew parent's [=tree/parent=] is null:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

11. Letoriginal parent be the [=tree/parent=] of the first member ofnode list.
12. Ifnew parent is before the first member ofnode list in [=tree order=]:
    1. Ifnew parent is not aninline node, but the last visible [=tree/child=] ofnew parent and the firstvisible member ofnode list are bothinline nodes, and the last [=tree/child=] ofnew parent is not a [^br^], callcreateElement("br") on the {{Node/ ownerDocument}} ofnew parent and append the result as the last [=tree/child=] ofnew parent.
    2. For eachnode innode list, appendnode as the last [=tree/child=] ofnew parent,preserving ranges.
13. Otherwise:
    1. Ifnew parent is not aninline node, but the first visible [=tree/child=] ofnew parent and the lastvisible member ofnode list are bothinline nodes, and the last member ofnode list is not a [^br^], callcreateElement("br") on the {{Node/ ownerDocument}} ofnew parent and insert the result as the first [=tree/child=] ofnew parent.
    2. For eachnode innode list,in reverse order, insertnode as the first [=tree/child=] ofnew parent,preserving ranges.

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

    Iforiginal parent iseditable and has no [=tree/children=], remove it from its [=tree/parent=].

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

    Ifnew parent's {{Node/nextSibling}} iseditable and runningsibling criteria on it returns true:

    1. Ifnew parent is not aninline node, butnew parent's last [=tree/child=] andnew parent's {{Node/nextSibling}}'s first [=tree/child=] are bothinline nodes, andnew parent's last [=tree/child=] is not a [^br^], callcreateElement("br") on the {{Node/ ownerDocument}} ofnew parent and append the result as the last [=tree/child=] ofnew parent.
    2. Whilenew parent's {{Node/nextSibling}} has [=tree/children=], append its first [=tree/child=] as the last [=tree/child=] ofnew parent,preserving ranges.
    3. Removenew parent's {{Node/nextSibling}} from its [=tree/parent=].
16. Remove extraneous line breaks fromnew parent.
17. Returnnew parent.

Allowed children

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

Anelement with inline contents is anHTML element whose [=Element/local name=] is aname of an element with inline contents.

Anode or stringchild is anallowed child of anode or stringparent if the following algorithm returns true:

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

1. Ifparent is "colgroup", "table", "tbody", "tfoot", "thead", "tr", or anHTML element with [=Element/local name=] equal to one of those, andchild is a {{Text}} node whose {{CharacterData/data}} does not consist solely ofspace characters, return false.

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

   Ifparent is "script", "style", "plaintext", or "xmp", or anHTML element with [=Element/local name=] equal to one of those, andchild is not a {{Text}} node, return false.

3. Ifchild is a [=document=], {{DocumentFragment}}, or {{DocumentType}}, return false.
4. Ifchild is anHTML element, setchild to the [=Element/local name=] ofchild.
5. Ifchild is not a string, return true.
6. Ifparent is anHTML element:

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

      Ifchild is "a", andparent or some [=tree/ancestor=] ofparent is an [^a^], return false.

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

      Ifchild is aprohibited paragraph child name andparent or some [=tree/ancestor=] ofparent is anelement with inline contents, return false.

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

      Ifchild is "h1", "h2", "h3", "h4", "h5", or "h6", andparent or some [=tree/ancestor=] ofparent is anHTML element with [=Element/local name=] "h1", "h2", "h3", "h4", "h5", or "h6", return false.

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

      Letparent be the [=Element/local name=] ofparent.

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

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

   Ifparent is on the left-hand side of an entry on the following list, then return true ifchild is listed on the right-hand side of that entry, and false otherwise.

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

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

    Ifchild is "dd" or "dt" andparent is not "dl", return false.

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

Inline formatting command definitions

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

Anodenode iseffectively contained in a [=range=]range ifrange is not {{AbstractRange/collapsed}}, and at least one of the following holds:

• node iscontained inrange.

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

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

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

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

  node has at least one [=tree/child=]; and all its [=tree/children=] areeffectively contained inrange; and eitherrange's [=range/start node=] is not a [=tree/descendant=] ofnode or is not a {{Text}} node orrange's [=range/start offset=] is zero; and eitherrange's [=range/end node=] is not a [=tree/descendant=] ofnode or is not a {{Text}} node orrange's [=range/end offset=] is its [=range/end node=]'s [=Node/length=].

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

Asimple modifiable element is anHTML element for which at least one of the following holds:

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

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

Aformattable node is aneditablevisiblenode that is either a {{Text}} node, an [^img^], or a [^br^].

Two quantities areequivalent values for acommand if either both are null, or both are strings and they're equal and thecommand does not define anyequivalent values, or both are strings and thecommand definesequivalent values and they match the definition.

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

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

If acommand hasinline command activated values defined but nothing else defines when it isindeterminate, it isindeterminate if amongformattable nodeseffectively contained in theactive range, there is at least one whoseeffective command value is one of the given values and at least one whoseeffective command value is not one of the given values.

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

If acommand hasinline command activated values defined, itsstate is true if either noformattable node iseffectively contained in theactive range, and theactive range's [=range/start node=]'seffective command value is one of the given values; or if there is at least oneformattable nodeeffectively contained in theactive range, and all of them have aneffective command value equal to one of the given values.

If a command is astandard inline value command, it isindeterminate if amongformattable nodes that areeffectively contained in theactive range, there are two that have distincteffective command values. Itsvalue is theeffective command value of the firstformattable node that iseffectively contained in theactive range; or if there is no such node, theeffective command value of theactive range's [=range/start node=]; or if that is null, the empty string.

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

Assorted inline formatting command algorithms

Theeffective command value of anodenode for a givencommand is returned by the following algorithm, which will return either a string or null:

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

1. If neithernode nor its [=tree/parent=] is an {{Element}}, return null.
2. Ifnode is not an {{Element}}, return theeffective command value of its [=tree/parent=] forcommand.
3. Ifcommand is "createLink" or "unlink":
   1. Whilenode is not null, and is not an [^a^] element that has an href attribute, setnode to its [=tree/parent=].
   2. Ifnode is null, return null.
   3. Return the [=Attr/value=] ofnode's href attribute.
4. Ifcommand is "backColor" or "hiliteColor":
   1. While theresolved value of "background-color" onnode is any fully transparent value, andnode's [=tree/parent=] is an {{Element}}, setnode to its [=tree/parent=].

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

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

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

      Return theresolved value of "background-color" fornode.

5. Ifcommand is "subscript" or "superscript":
   1. Letaffected by subscript andaffected by superscript be two boolean variables, both initially false.
   2. Whilenode is an inline node:

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

         Ifnode is a sub, setaffected by subscript to true.

      2. Otherwise, ifnode is a sup, setaffected by superscript to true.
      3. Setnode to its [=tree/parent=].
   3. Ifaffected by subscript andaffected by superscript are both true, return the string "mixed".
   4. Ifaffected by subscript is true, return "subscript".
   5. Ifaffected by superscript is true, return "superscript".
   6. Return null.
6. Ifcommand is "strikethrough", and the "text-decoration" property ofnode or any of its [=tree/ancestors=] hasresolved value containing "line-through", return "line-through". Otherwise, return null.
7. Ifcommand is "underline", and the "text-decoration" property ofnode or any of its [=tree/ancestors=] hasresolved value containing "underline", return "underline". Otherwise, return null.
8. Return theresolved value fornode of the relevant CSS property forcommand.

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

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

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

Torecord the values of a list ofnodesnode list:

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

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

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

   For eachnode innode list, for eachcommand in the list "subscript", "bold", "fontName", "fontSize", "foreColor", "hiliteColor", "italic", "strikethrough", and "underline" in that order:

   1. Letancestor equalnode.
   2. Ifancestor is not an {{Element}}, set it to its [=tree/parent=].
   3. Whileancestor is an {{Element}} and itsspecified command value forcommand is null, set it to its [=tree/parent=].
   4. Ifancestor is an {{Element}}, add (node,command,ancestor'sspecified command value forcommand) tovalues. Otherwise add (node,command, null) tovalues.
3. Returnvalues.

Torestore the values specified by a listvalues returned by therecord the values algorithm:

1. For each (node,command,value) triple invalues:
   1. Letancestor equalnode.
   2. Ifancestor is not an {{Element}}, set it to its [=tree/parent=].
   3. Whileancestor is an {{Element}} and itsspecified command value forcommand is null, set it to its [=tree/parent=].
   4. Ifvalue is null andancestor is an {{Element}}, push down values onnode forcommand, withnew value null.
   5. Otherwise, ifancestor is an {{Element}} and itsspecified command value forcommand is notequivalent tovalue, or ifancestor is not an {{Element}} andvalue is not null,force the value of command tovalue onnode.

Clearing an element's value

Toclear the value of an {{Element}}element:

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

1. Letcommand be the currentcommand.
2. Ifelement is noteditable, return the empty list.

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

   Ifelement'sspecified command value forcommand is null, return the empty list.

4. Ifelement is asimple modifiable element:
   1. Letchildren be the [=tree/children=] ofelement.
   2. For eachchild inchildren, insertchild intoelement's [=tree/parent=] immediately beforeelement,preserving ranges.
   3. Removeelement from its [=tree/parent=].
   4. Returnchildren.
5. Ifcommand is "strikethrough", andelement has a style attribute that sets "text-decoration" to some value containing "line-through", delete "line-through" from the value.
6. Ifcommand is "underline", and element has a style attribute that sets "text-decoration" to some value containing "underline", delete "underline" from the value.
7. If therelevant CSS property forcommand is not null, unset that property ofelement.
8. Ifelement is a [^font^] element:
   1. Ifcommand is "foreColor", unsetelement's color attribute, if set.
   2. Ifcommand is "fontName", unsetelement's face attribute, if set.
   3. Ifcommand is "fontSize", unsetelement's size attribute, if set.
9. Ifelement is an [^a^] element andcommand is "createLink" or "unlink", unset the href property ofelement.

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

    Ifelement'sspecified command value forcommand is null, return the empty list.

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

Pushing down values

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

Topush down values to anodenode, given a new valuenew value:

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

1. Letcommand be the currentcommand.

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

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

3. If theeffective command value ofcommand isloosely equivalent to new value onnode, abort this algorithm.
4. Letcurrent ancestor benode's [=tree/parent=].
5. Letancestor list be a list ofnodes, initially empty.
6. Whilecurrent ancestor is aneditable {{Element}} and theeffective command value ofcommand is notloosely equivalent tonew value on it, appendcurrent ancestor toancestor list, then setcurrent ancestor to its [=tree/parent=].
7. Ifancestor list is empty, abort this algorithm.
8. Letpropagated value be thespecified command value ofcommand on the last member ofancestor list.

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

   Ifpropagated value is null and is not equal tonew value, abort this algorithm.

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

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

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

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

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

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

    If theeffective command value ofcommand is notloosely equivalent tonew value on the [=tree/parent=] of the last member ofancestor list, andnew value is not null, abort this algorithm.

11. Whileancestor list is not empty:
    1. Letcurrent ancestor be the last member ofancestor list.
    2. Remove the last member fromancestor list.
    3. If thespecified command value ofcurrent ancestor forcommand is not null, setpropagated value to that value.
    4. Letchildren be the [=tree/children=] ofcurrent ancestor.
    5. If thespecified command value ofcurrent ancestor forcommand is not null,clear the value ofcurrent ancestor.
    6. For everychild inchildren:
       1. Ifchild isnode, continue with the nextchild.

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

          Ifchild is an {{Element}} whosespecified command value forcommand is neither null norequivalent topropagated value, continue with the nextchild.

       3. Ifchild is the last member ofancestor list, continue with the nextchild.
       4. Force the value ofchild, withcommand as in this algorithm andnew value equal topropagated value.

Forcing the value of a node

Toforce the value of anodenode tonew value:

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

1. Letcommand be the currentcommand.
2. Ifnode's [=tree/parent=] is null, abort this algorithm.
3. Ifnew value is null, abort this algorithm.
4. Ifnode is anallowed child of "span":

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

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

      Reorder modifiable descendants ofnode's {{Node/ previousSibling}}.

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

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

      Wrap the one-node list consisting ofnode, withsibling criteria returning true for asimple modifiable element whosespecified command value isequivalent tonew value and whoseeffective command value isloosely equivalent tonew value and false otherwise, and withnew parent instructions returning null.

5. Bug 13996.

   Ifnode isinvisible, abort this algorithm.

6. If theeffective command value ofcommand isloosely equivalent to new value onnode, abort this algorithm.
7. Ifnode is not anallowed child of "span":
   1. Letchildren be all [=tree/children=] ofnode, omitting any that are {{Element}}s whosespecified command value forcommand is neither null norequivalent tonew value.

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

      Force the value of eachnode inchildren, withcommand andnew value as in this invocation of the algorithm.

   3. Abort this algorithm.
8. If theeffective command value ofcommand isloosely equivalent to new value onnode, abort this algorithm.
9. Letnew parent be null.
10. If theCSS styling flag is false:
    1. Ifcommand is "bold" andnew value is "bold", letnew parent be the result of callingcreateElement("b") on the {{Node/ownerDocument}} ofnode.
    2. Ifcommand is "italic" and new value is "italic", letnew parent be the result of callingcreateElement("i") on the {{Node/ownerDocument}} ofnode.

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

       Ifcommand is "strikethrough" andnew value is "line-through", letnew parent be the result of callingcreateElement("s") on the {{Node/ ownerDocument}} ofnode.

    4. Ifcommand is "underline" andnew value is "underline", letnew parent be the result of callingcreateElement("u") on the {{Node/ownerDocument}} ofnode.

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

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

       1. Letnew parent be the result of callingcreateElement("font") on the {{Node/ ownerDocument}} ofnode.
       2. Set the color attribute ofnew parent to the result of applying the rules for serializing simple color values tonew value (interpreted as a simple color).
    6. Ifcommand is "fontName", letnew parent be the result of callingcreateElement("font") on the {{Node/ownerDocument}} ofnode, then set the face attribute ofnew parent tonew value.
11. Ifcommand is "createLink" or "unlink":
    1. Letnew parent be the result of callingcreateElement("a") on the {{Node/ownerDocument}} ofnode.
    2. Set the href attribute ofnew parent tonew value.

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

       Letancestor benode's [=tree/parent=].

    4. Whileancestor is not null:

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

          Ifancestor is an [^a^],set the tag name ofancestor to "span", and letancestor be the result.

       2. Setancestor to its [=tree/parent=].

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

    Ifcommand is "fontSize"; andnew value is one of "x-small", "small", "medium", "large", "x-large", "xx-large", or "xxx-large"; and either theCSS styling flag is false, ornew value is "xxx-large": letnew parent be the result of callingcreateElement("font") on the {{Node/ownerDocument}} ofnode, then set the size attribute ofnew parent to the number from the following table based onnew value:

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

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

    Ifcommand is "subscript" or "superscript" andnew value is "subscript", letnew parent be the result of callingcreateElement("sub") on the {{Node/ownerDocument}} ofnode.

14. Ifcommand is "subscript" or "superscript" andnew value is "superscript", letnew parent be the result of callingcreateElement("sup") on the {{Node/ownerDocument}} ofnode.
15. Ifnew parent is null, letnew parent be the result of callingcreateElement("span") on the {{Node/ownerDocument}} ofnode.

16. This preserves boundary points correctly, as usual.

    Insertnew parent innode's [=tree/parent=] beforenode.

17. If theeffective command value ofcommand fornew parent is notloosely equivalent to new value, and therelevant CSS property forcommand is not null, set that CSS property ofnew parent tonew value (if the new value would be valid).

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

18. Ifcommand is "strikethrough", andnew value is "line-through", and theeffective command value of "strikethrough" fornew parent is not "line-through", set the "text-decoration" property ofnew parent to "line-through".
19. Ifcommand is "underline", and new value is "underline", and theeffective command value of "underline" fornew parent is not "underline", set the "text-decoration" property ofnew parent to "underline".
20. Appendnode tonew parent as its last [=tree/child=],preserving ranges.
21. Ifnode is an {{Element}} and theeffective command value ofcommand fornode is notloosely equivalent tonew value:
    1. Insertnode into the [=tree/parent=] ofnew parent beforenew parent,preserving ranges.
    2. Removenew parent from its [=tree/parent=].
    3. Letchildren be all [=tree/children=] ofnode, omitting any that are {{Element}}s whosespecified command value forcommand is neither null norequivalent tonew value.
    4. Force the value of eachnode inchildren, withcommand andnew value as in this invocation of the algorithm.

Toreorder modifiable descendants of anodenode, given acommandcommand and a valuenew value:

1. Letcandidate equalnode.
2. Whilecandidate is amodifiable element, andcandidate has exactly one [=tree/child=], and that [=tree/child=] is also amodifiable element, andcandidate is not asimple modifiable element orcandidate'sspecified command value forcommand is notequivalent tonew value, setcandidate to its [=tree/child=].
3. Ifcandidate isnode, or is not asimple modifiable element, or itsspecified command value is notequivalent tonew value, or itseffective command value is notloosely equivalent to new value, abort these steps.
4. Whilecandidate has [=tree/children=], insert the first [=tree/child=] ofcandidate intocandidate's [=tree/parent=] immediately beforecandidate,preserving ranges.

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

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

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

   it thus becomes

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

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

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

   which is reasonable.

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

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

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

   Insertcandidate intonode's [=tree/parent=] immediately afternode.

6. Append thenode as the last [=tree/child=] ofcandidate,preserving ranges.

Setting the selection's value

Toset the selection's value tonew value:

foobar baz,

foobar baz.

foobar baz,

1. Letcommand be the currentcommand.

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

   If there is noformattable nodeeffectively contained in theactive range:

   1. Ifcommand hasinline command activated values, set thestate override to true ifnew value is among them and false if it's not.
   2. Ifcommand is "subscript", unset thestate override for "superscript".
   3. Ifcommand is "superscript", unset thestate override for "subscript".
   4. Ifnew value is null, unset thevalue override (if any).
   5. Otherwise, ifcommand is "createLink" or it has avalue specified, set thevalue override tonew value.
   6. Abort these steps.

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

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

4. If theactive range's [=range/end node=] is aneditable {{Text}} node, and its [=range/end offset=] is neither zero nor its [=range/end node=]'s [=Node/length=], callsplitText() on theactive range's [=range/end node=], with argument equal to theactive range's [=range/end offset=].
5. Letelement list be all editable {{Element}}seffectively contained in theactive range.
6. For eachelement inelement list,clear the value ofelement.

7. We skip non-editable nodes.

   IE9

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

   Firefox 4.0

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

   Chrome 12 dev

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

   Opera 11.00

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

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

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

   Letnode list be alleditablenodeseffectively contained in theactive range.

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

   For eachnode innode list:

   1. Push down values onnode.

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

      Ifnode is anallowed child of "span",force the value ofnode.

ThebackColor command

This command must not beenabled if theediting host is in theplaintext-only state.

For historical reasons, backColor and hiliteColor behave identically.

Action:

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

Standard inline value command

Relevant CSS property: "background-color"

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

Thebold command

This command must not beenabled if theediting host is in theplaintext-only state.

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

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

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

Relevant CSS property: "font-weight"

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

ThecreateLink command

This command must not beenabled if theediting host is in theplaintext-only state.

Action:

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

   Ifvalue is the empty string, return false.

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

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

   Chrome 10 dev produces:

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

   Firefox 4b11 produces (roughly):

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

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

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

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

   For eacheditable [^a^] element that has an href attribute and is an [=tree/ancestor=] of somenodeeffectively contained in theactive range, set that [^a^] element's href attribute tovalue.

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

ThefontName command

This command must not beenabled if theediting host is in theplaintext-only state.

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

Standard inline value command

Relevant CSS property: "font-family"

ThefontSize command

This command must not beenabled if theediting host is in theplaintext-only state.

Action:

1. Strip leading and trailing whitespace fromvalue.
2. Ifvalue is not a valid floating point number, and would not be a valid floating point number if a single leading "+" character were stripped, return false.
3. If the first character ofvalue is "+", delete the character and letmode be "relative-plus".
4. Otherwise, if the first character ofvalue is "-", delete the character and letmode be "relative-minus".
5. Otherwise, letmode be "absolute".
6. Apply the rules for parsing non-negative integers tovalue, and letnumber be the result.
7. Ifmode is "relative-plus", add three tonumber.
8. Ifmode is "relative-minus", negatenumber, then add three to it.
9. Ifnumber is less than one, letnumber equal 1.
10. Ifnumber is greater than seven, letnumber equal 7.
11. Setvalue to the string here corresponding tonumber:

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

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

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

Indeterminate: True if amongformattable nodes that areeffectively contained in theactive range, there are two that have distincteffective command values. Otherwise false.

Value:

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

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

   Letpixel size be theeffective command value of the firstformattable node that iseffectively contained in theactive range, or if there is no such node, theeffective command value of theactive range's [=range/start node=], in either case interpreted as a number of pixels.

3. Return thelegacy font size forpixel size.

Relevant CSS property: "font-size"

Thelegacy font size for an integerpixel size is returned by the following algorithm:

1. Letreturned size be 1.
2. Whilereturned size is less than 7:
   1. Letlower bound be theresolved value of "font-size" in pixels of a [^font^] element whose size attribute is set toreturned size.
   2. Letupper bound be theresolved value of "font-size" in pixels of a [^font^] element whose size attribute is set to one plusreturned size.
   3. Letaverage be the average ofupper bound andlower bound.
   4. Ifpixel size is less than average, return the one-code unit string consisting of the digitreturned size.
   5. Add one toreturned size.
3. Return "7".

TheforeColor command

This command must not beenabled if theediting host is in theplaintext-only state.

                        IE10PP2       Firefox 7.0a2            Chrome 14 dev            Opera 11.50blue                    blue          blue                     #0000ff                  #0000fff                       #f            -                        -                        #f00000#f                      #f            -                        -                        #f0000000f                     #00f          -                        #0000ff                  #00000f#00f                    #00f          rgb(0, 0, 255)           #0000ff                  #00000f0000ff                  #0000ff       -                        #0000ff                  #0000ff#0000ff                 #0000ff       rgb(0, 0, 255)           #0000ff                  #0000ff000000fff               #0000ff       -                        -                        -#000000fff              #0000ff       -                        -                        -rgb(0, 0, 255)          rgb(0,0,255)  rgb(0, 0, 255)           #0000ff                  #00b000rgb(0%, 0%, 100%)       rgb(0,0,255)  rgb(0, 0, 255)           #0000ff                  #00b000rgb( 0 ,0 ,255)         rgb(0,0,255)  rgb(0, 0, 255)           #0000ff                  #00b000rgba(0, 0, 255, 0.0)    #ba0000       rgba(0, 0, 255, 0)       rgba(0, 0, 255, 0)       #00ba00rgb(15, -10, 375)       rgb(15,0,255) rgb(15, 0, 255)          #0f00ff                  #00b015rgba(0, 0, 0, 1)        #ba0010       rgb(0, 0, 0)             -                        #00ba00rgba(255, 255, 255, 1)  #000055       rgb(255, 255, 255)       #ffffff                  #00ba02rgba(0, 0, 255, 0.5)    #ba0000       rgba(0, 0, 255, 0.5)     rgba(0, 0, 255, 0.5)     #00ba00hsl(240, 100%, 50%)     #000150       rgb(0, 0, 255)           #0000ff                  #000024cornsilk                cornsilk      cornsilk                 #fff8dc                  #fff8dcpotato quiche           #0000c0       -                        -                        #000a00transparent             transparent   -                        rgba(0, 0, 0, 0)         #00a000currentColor            #c0e000       currentcolor             rgba(0, 0, 0, 0)         #c000e0

Action:

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

   Ifvalue 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.

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

3. Set the selection's value tovalue.
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.

ThehiliteColor command

This command must not beenabled if theediting host is in theplaintext-only state.

For historical reasons, backColor and hiliteColor behave identically.

Action:

1. Ifvalue 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.

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

3. Set the selection's value tovalue.
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.

Theitalic command

This command must not beenabled if theediting host is in theplaintext-only state.

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

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

Relevant CSS property: "font-style"

TheremoveFormat command

This command must not beenabled if theediting host is in theplaintext-only state.

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

Action:

1. Letelements to remove be a list of everyremoveFormat candidateeffectively contained in theactive range.
2. For eachelement inelements to remove:
   1. Whileelement has [=tree/children=], insert the first [=tree/child=] ofelement into the [=tree/parent=] ofelement immediately beforeelement,preserving ranges.
   2. Removeelement from its [=tree/parent=].

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

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

4. If theactive range's [=range/end node=] is aneditable {{Text}} node, and its [=range/end offset=] is neither zero nor its [=range/end node=]'s [=Node/length=], callsplitText() on theactive range's [=range/end node=], with argument equal to theactive range's [=range/end offset=].
5. Letnode list consist of alleditable nodeseffectively contained in theactive 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 eachnode innode list, whilenode's [=tree/parent=] is aremoveFormat candidatein the same editing host asnode,split the parent of the one-node list consisting ofnode.

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, withcommand as given.

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

Thestrikethrough command

This command must not beenabled if theediting host is in theplaintext-only state.

TODO: See underline TODO.

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

Inline command activated values: "line-through"

Thesubscript command

This command must not beenabled if theediting host is in theplaintext-only state.

Action:

1. CallqueryCommandState("subscript"), and letstate be the result.
2. Set the selection's value to null.
3. Ifstate is false,set the selection's value to "subscript".
4. Return true.

Indeterminate: True if either amongformattable nodes that areeffectively contained in theactive range, there is at least one witheffective command value "subscript" and at least one with some othereffective command value; or if there is someformattable nodeeffectively contained in theactive range witheffective 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"

Thesuperscript command

This command must not beenabled if theediting host is in theplaintext-only state.

Action:

1. CallqueryCommandState("superscript"), and letstate be the result.
2. Set the selection's value to null.
3. Ifstate is false,set the selection's value to "superscript".
4. Return true.

Indeterminate: True if either amongformattable nodes that areeffectively contained in theactive range, there is at least one witheffective command value "superscript" and at least one with some othereffective command value; or if there is someformattable nodeeffectively contained in theactive range witheffective command value "mixed". Otherwise false.

Inline command activated values: "superscript"

Theunderline command

This command must not beenabled if theediting host is in theplaintext-only state.

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

Inline command activated values: "underline"

Theunlink command

This command must not beenabled if theediting host is in theplaintext-only state.

Action:

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

Block formatting command definitions

Anindentation 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 . 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.

Asimple indentation element is anindentation 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 ofmodifiable element andsimple modifiable element.

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

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

Asingle-line container is either anon-list single-line container, or anHTML element with [=Element/local name=] "li", "dt", or "dd".

Theblock node of anodenode is either ablock node or null, as returned by the following algorithm:

1. Whilenode is aninline node, setnode to its [=tree/parent=].
2. Returnnode.

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

If acommandpreserves overrides, then before taking itsaction, the user agent mustrecord current overrides. After taking theaction, if theactive range is {{AbstractRange/collapsed}}, it mustrestore states and values from the recorded list.

All block commands preserve overrides excepttheinsertText 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.

Tofix disallowed ancestors ofnode:

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. Ifnode is noteditable, 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.

   Ifnode is not anallowed child of any of its [=tree/ancestors=]in the same editing host:

   1. Ifnode is a [^dd^] or [^dt^],wrap the one-node list consisting ofnode, withsibling criteria returning true for any [^dl^] with noattributes and false otherwise, andnew parent instructions returning the result of callingcreateElement("dl") on thecontext object. Then abort these steps.

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

      If "p" is not anallowed child of theediting host ofnode, abort these steps.

   3. Ifnode is not aprohibited paragraph child, abort these steps.
   4. Set the tag name ofnode to thedefault single-line container name, and letnode be the result.

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

      Fix disallowed ancestors ofnode.

   6. Letchildren benode's [=tree/children=].
   7. For eachchild inchildren, ifchild is aprohibited paragraph child:
      1. Record the values of the one-node list consisting ofchild, and letvalues be the result.
      2. Split the parent of the one-node list consisting ofchild.
      3. Restore the values fromvalues.
   8. Abort these steps.
3. Record the values of the one-node list consisting ofnode, and letvalues be the result.
4. Whilenode is not anallowed child of its [=tree/parent=],split the parent of the one-node list consisting ofnode.
5. Restore the values fromvalues.

<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>

Tonormalize sublists in anodeitem:

1. Ifitem is not an [^li^] or it is noteditable or its [=tree/parent=] is noteditable, abort these steps.
2. Letnew item be null.
3. Whileitem has an [^ol^] or [^ul^] [=tree/child=]:
   1. Letchild be the last [=tree/child=] ofitem.
   2. Ifchild is an [^ol^] or [^ul^], ornew item is null andchild is a {{Text}} node whose {{CharacterData/ data}} consists of zero of morespace characters:
      1. Setnew item to null.
      2. Insertchild into the [=tree/parent=] ofitem immediately followingitem,preserving ranges.
   3. Otherwise:
      1. Ifnew item is null, letnew item be the result of callingcreateElement("li") on the {{Node/ ownerDocument}} ofitem, then insertnew item into the [=tree/parent=] ofitem immediately afteritem.
      2. Insertchild intonew item as its first [=tree/child=],preserving ranges.

Theselection's list state is returned by the following algorithm:

1. If theactive range is null, return "none".
2. Block-extend theactive range, and letnew range be the result.
3. Letnode list be a list ofnodes, initially empty.
4. For eachnode contained innew range, appendnode tonode list if the last member ofnode list (if any) is not an [=tree/ancestor=] ofnode;node iseditable;node is not anindentation element; andnode is either an [^ol^] or [^ul^], or the [=tree/child=] of an [^ol^] or [^ul^], or anallowed child of "li".
5. Ifnode 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 ofnode list is either an [^ol^] or the [=tree/child=] of an [^ol^] or the [=tree/child=] of an [^li^] [=tree/child=] of an [^ol^], and none is a [^ul^] or an [=tree/ancestor=] of a [^ul^], return "ol".

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

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

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

Thealignment value of anodenode 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. Whilenode is neither null nor an {{Element}}, or it is an {{Element}} but its "display" property hasresolved value "inline" or "none", setnode to its [=tree/parent=].

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

   Ifnode is not an {{Element}}, return "left".

3. Ifnode's "text-align" property hasresolved value "start", return "left" if thedirectionality ofnode is "ltr", "right" if it is "rtl".
4. Ifnode's "text-align" property hasresolved value "end", return "right" if thedirectionality ofnode is "ltr", "left" if it is "rtl".
5. Ifnode's "text-align" property hasresolved value "center", "justify", "left", or "right", return that value.
6. Return "left".

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

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

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

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

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

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

1. While (node,offset)'sprevious equivalent point is not null, set (node,offset) to itsprevious equivalent point.
2. Return (node,offset).

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

1. While (node,offset)'snext equivalent point is not null, set (node,offset) to itsnext equivalent point.
2. Return (node,offset).

Block-extending a range

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

A [=boundary point=] (node,offset) is ablock end point if eithernode's [=tree/parent=] is null andoffset isnode's [=Node/length=]; ornode has a [=tree/child=] with [=tree/index=]offset, and that [=tree/child=] is avisibleblock node.

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

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

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

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

   Whilestart offset is zero andstart node's [=tree/parent=] is not null, setstart offset tostart node's [=tree/index=], then setstart node to its [=tree/parent=].

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

Anodenodefollows a line break if the following algorithm returns true:

1. Letoffset be zero.
2. While (node,offset) is not ablock boundary point:
   1. Ifnode has avisible [=tree/child=] with [=tree/index=]offset minus one, return false.
   2. Ifoffset is zero ornode has no [=tree/children=], setoffset tonode's [=tree/index=], then setnode to its [=tree/parent=].
   3. Otherwise, setnode to its [=tree/child=] with [=tree/index=]offset minus one, then setoffset tonode's [=Node/length=].
3. Return true.

Anodenodeprecedes a line break if the following algorithm returns true:

1. Letoffset benode's [=Node/length=].
2. While (node,offset) is not ablock boundary point:
   1. Ifnode has avisible [=tree/child=] with [=tree/index=]offset, return false.
   2. Ifoffset isnode's [=Node/length=] ornode has no [=tree/children=], setoffset to one plusnode's [=tree/index=], then setnode to its [=tree/parent=].
   3. Otherwise, setnode to its [=tree/child=] with [=tree/index=]offset and setoffset to zero.
3. Return true.

Recording and restoring overrides

Torecord current overrides:

1. Letoverrides 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 avalue override for "createLink", add ("createLink",value override for "createLink") tooverrides.

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 eachcommand in the list "bold", "italic", "strikethrough", "subscript", "superscript", "underline", in order: if there is astate override forcommand, add (command,command'sstate override) tooverrides.

4. For eachcommand in the list "fontName", "fontSize", "foreColor", "hiliteColor", in order: if there is avalue override forcommand, add (command,command'svalue override) tooverrides.
5. Returnoverrides.

Torecord current states and values:

1. Letoverrides be a list of (string, string or boolean) ordered pairs, initially empty.
2. Letnode be the firstformattable nodeeffectively contained in theactive range, or null if there is none.
3. Ifnode is null, returnoverrides.
4. Add ("createLink",node'seffective command value for "createLink") tooverrides.

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

   For eachcommand in the list "bold", "italic", "strikethrough", "subscript", "superscript", "underline", in order: ifnode'seffective command value forcommand is one of itsinline command activated values, add (command, true) tooverrides, and otherwise add (command, false) tooverrides.

6. For eachcommand in the list "fontName", "foreColor", "hiliteColor", in order: add (command,command'svalue) tooverrides.

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

   Add ("fontSize",node'seffective command value for "fontSize") tooverrides.

   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. Returnoverrides.

Torestore states and values specified by a listoverrides returned by therecord current overrides orrecord current states and values algorithm:

1. Letnode be the firstformattable nodeeffectively contained in theactive range, or null if there is none.
2. Ifnode is not null, then for each (command,override) pair inoverrides, in order:
   1. Ifoverride is a boolean, andqueryCommandState(command) returns something different fromoverride, take theaction forcommand, withvalue equal to the empty string.
   2. Otherwise, ifoverride is a string, andcommand is neither "createLink" nor "fontSize", andqueryCommandValue(command) returns something notequivalent tooverride, take theaction forcommand, withvalue equal tooverride.

   3. This special case is needed becausecreateLink has no value.

      Otherwise, ifoverride is a string; andcommand is "createLink"; and either there is avalue override for "createLink" that is not equal tooverride, or there is novalue override for "createLink" andnode'seffective command value for "createLink" is not equal tooverride: take theaction for "createLink", withvalue equal tooverride.

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

      Otherwise, ifoverride is a string; andcommand is "fontSize"; and either there is avalue override for "fontSize" that is not equal tooverride, or there is novalue override for "fontSize" andnode'seffective command value for "fontSize" is notloosely equivalent tooverride:

      1. Convertoverride to an integer number of pixels, and setoverride to thelegacy font size for the result.
      2. Take theaction for "fontSize", withvalue equal tooverride.
   5. Otherwise, continue this loop from the beginning.

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

      Setnode to the firstformattable nodeeffectively contained in theactive range, if there is one.

3. Otherwise, for each (command, override) pair inoverrides, in order:
   1. Ifoverride is a boolean, set thestate override forcommand tooverride.
   2. Ifoverride is a string, set thevalue override forcommand tooverride.

Deleting the selection

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

Todelete the selection, given ablock merging flag that defaults to true, astrip wrappers flag that defaults to true, and a stringdirection that defaults to "forward":

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

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

   1. Ifdirection is "forward", callcollapseToStart() on thecontext object'sselection.
   2. Otherwise, callcollapseToEnd() on thecontext object'sselection.
   3. Abort these steps.
7. Ifstart node is a {{Text}} node andstart offset is 0, setstart offset to the [=tree/index=] ofstart node, then setstart node to its [=tree/parent=].
8. Ifend node is a {{Text}} node andend offset is its [=Node/length=], setend offset to one plus the [=tree/index=] ofend node, then setend node to its [=tree/parent=].

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

9. Callcollapse(start node,start offset) on thecontext object'sselection.
10. Callextend(end node,end offset) on thecontext object'sselection.

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

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

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

12. Letstart block be theactive range's [=range/start node=].
13. Whilestart block's [=tree/parent=] isin the same editing host andstart block is aninline node, setstart block to its [=tree/parent=].

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

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

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

    Ifstart block is neither ablock node nor an [=editing host=], or "span" is not anallowed child ofstart block, orstart block is a [^td^] or [^th^], setstart block to null.

15. Letend block be the active range's [=range/end node=].
16. Whileend block's [=tree/parent=] isin the same editing host andend block is aninline node, setend block to its [=tree/parent=].
17. Ifend block is neither ablock node nor an [=editing host=], or "span" is not anallowed child ofend block, orend block is a [^td^] or [^th^], setend block to null.

18. Later on we'll restoreoverrides. 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 letoverrides 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.

    Ifstart node andend node are the same, andstart node is aneditable {{Text}} node:

    1. CalldeleteData(start offset,end offset −start offset) onstart node.
    2. Canonicalize whitespace at (start node,start offset), withfix collapsed space false.
    3. Ifdirection is "forward", callcollapseToStart() on thecontext object'sselection.
    4. Otherwise, callcollapseToEnd() on thecontext object'sselection.

    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 fromoverrides.

    6. Abort these steps.
22. Ifstart node is aneditable {{Text}} node, call deleteData() on it, withstart offset as the first argument and ([=Node/length=] ofstart node −start offset) as the second argument.
23. Letnode list be a list ofnodes, 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 eachnodecontained in theactive range, appendnode tonode list if the last member ofnode list (if any) is not an [=tree/ancestor=] ofnode;node iseditable; andnode is not a [^thead^], [^tbody^], [^tfoot^], [^tr^], [^th^], or [^td^].

25. For eachnode innode list:
    1. Letparent be the [=tree/parent=] ofnode.
    2. Removenode fromparent.

    3. Do this before stripping wrappers: seebug 13831.

       If theblock node ofparent has novisible [=tree/children=], andparent iseditable or an [=editing host=], callcreateElement("br") on thecontext object and append the result as the last [=tree/child=] ofparent.

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

       Ifstrip wrappers is true orparent is not an [=tree/inclusive ancestor=] ofstart node, whileparent is aneditableinline node with [=Node/length=] 0, letgrandparent be the [=tree/parent=] ofparent, then removeparent fromgrandparent, then setparent tograndparent.

       Even ifstrip wrappers is false, we still want to strip wrappers that aren't [=tree/inclusive ancestors=] ofstart 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. Ifend node is aneditable {{Text}} node, call deleteData(0,end offset) on it.
27. Canonicalize whitespace at theactive range's [=range/start=], withfix collapsed space false.
28. Canonicalize whitespace at theactive range's [=range/end=], withfix collapsed space false.

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

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

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

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

    or

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

    where one descends from the other.

30. Ifblock merging is false, or start block orend block is null, orstart block is notin the same editing host asend block, orstart block andend block are the same:
    1. Ifdirection is "forward", callcollapseToStart() on thecontext object'sselection.
    2. Otherwise, callcollapseToEnd() on thecontext object'sselection.
    3. Restore states and values fromoverrides.
    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.

    Ifstart block has one [=tree/child=], which is acollapsed block prop, remove its [=tree/child=] from it.

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

    Ifstart block is an [=tree/ancestor=] ofend block:

    1. Letreference node beend block.
    2. Whilereference node is not a [=tree/child=] ofstart block, setreference node to its [=tree/parent=].
    3. Callcollapse() on thecontext object'sselection, with first argumentstart block and second argument the [=tree/index=] ofreference node.
    4. Ifend block has no [=tree/children=]:
       1. Whileend block iseditable and is the only [=tree/child=] of its [=tree/parent=] and is not a [=tree/child=] ofstart block, letparent equalend block, then removeend block fromparent, then setend block toparent.
       2. Ifend block is editable and is not aninline node, and its {{Node/ previousSibling}} and {{Node/ nextSibling}} are bothinline nodes, callcreateElement("br") on thecontext object and insert it intoend block's [=tree/parent=] immediately afterend block.
       3. Ifend block is editable, remove it from its [=tree/parent=].
       4. Restore states and values fromoverrides.
       5. Abort these steps.
    5. Ifend block's {{Node/firstChild}} is not aninline node,restore states and values fromrecord, then abort these steps.
    6. Letchildren be a list of nodes, initially empty.
    7. Append the first [=tree/child=] ofend block tochildren.
    8. Whilechildren's last member is not a [^br^], andchildren's last member's {{Node/nextSibling}} is aninline node, appendchildren's last member's {{Node/nextSibling}} tochildren.
    9. Record the values ofchildren, and letvalues be the result.
    10. Whilechildren's first member's [=tree/parent=] is notstart block,split the parent ofchildren.
    11. Ifchildren's first member's {{Node/ previousSibling}} is aneditable [^br^], remove that [^br^] from its [=tree/parent=].

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

    Otherwise, ifstart block is a [=tree/descendant=] ofend block:

    1. Callcollapse() on thecontext object'sselection, with first argumentstart block and second argumentstart block's [=Node/length=].
    2. Letreference node bestart block.
    3. Whilereference node is not a [=tree/child=] ofend block, setreference node to its [=tree/parent=].
    4. Ifreference node's {{Node/nextSibling}} is aninline node andstart block's {{Node/lastChild}} is a [^br^], removestart block's {{Node/lastChild}} from it.
    5. Letnodes to move be a list ofnodes, initially empty.
    6. Ifreference node's {{Node/nextSibling}} is neither null nor ablock node, append it tonodes to move.
    7. Whilenodes to move is nonempty and its last member isn't a [^br^] and its last member's {{Node/nextSibling}} is neither null nor a block node, append its last member's {{Node/nextSibling}} tonodes to move.
    8. Record the values ofnodes to move, and letvalues be the result.
    9. For eachnode innodes to move, appendnode as the last [=tree/child=] ofstart 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. Callcollapse() on thecontext object'sselection, with first argumentstart block and second argumentstart block's [=Node/length=].
    2. Ifend block's {{Node/firstChild}} is aninline node andstart block's {{Node/lastChild}} is a [^br^], removestart block's {{Node/lastChild}} from it.
    3. Record the values ofend block's [=tree/children=], and letvalues be the result.
    4. Whileend block has [=tree/children=], append the first [=tree/child=] ofend block tostart block, preserving ranges.
    5. Whileend block has no [=tree/children=], letparent be the [=tree/parent=] ofend block, then removeend block fromparent, then setend block toparent.

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

36. Letancestor bestart block.
37. Whileancestor has an [=tree/inclusive ancestor=] [^ol^]in the same editing host whose {{Node/ nextSibling}} is also an [^ol^]in the same editing host, or an [=tree/inclusive ancestor=] [^ul^]in the same editing host whose {{Node/ nextSibling}} is also a [^ul^]in the same editing host:
    1. Whileancestor and its {{Node/nextSibling}} are not both [^ol^]sin the same editing host, and are also not both [^ul^]sin the same editing host, setancestor to its [=tree/parent=].
    2. Whileancestor's {{Node/nextSibling}} has [=tree/children=], appendancestor's {{Node/nextSibling}}'s {{Node/firstChild}} as the last [=tree/child=] ofancestor,preserving ranges.
    3. Removeancestor's {{Node/nextSibling}} from its [=tree/parent=].
38. Restore the values fromvalues.
39. Ifstart block has no [=tree/children=], callcreateElement("br") on thecontext object and append the result as the last [=tree/child=] ofstart block.
40. Remove extraneous line breaks at the end ofstart block.
41. Restore states and values fromoverrides.

Splitting a node list's parent

Tosplit the parent of a listnode list of consecutive [=tree/sibling=]nodes:

1. Letoriginal parent be the [=tree/parent=] of the first member ofnode list.
2. Iforiginal parent is noteditable or its [=tree/parent=] is null, do nothing and abort these steps.
3. If the first [=tree/child=] oforiginal parent is innode list,remove extraneous line breaks beforeoriginal parent.
4. If the first [=tree/child=] oforiginal parent is innode list, and original parentfollows a line break, setfollows line break to true. Otherwise, setfollows line break to false.
5. If the last [=tree/child=] oforiginal parent is innode list, andoriginal parentprecedes a line break, setprecedes line break to true. Otherwise, setprecedes line break to false.

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

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

   it becomes

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

   instead of

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

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

   If the first [=tree/child=] oforiginal parent is not innode list, but its last [=tree/child=] is:

   1. For eachnode innode list,in reverse order, insertnode into the [=tree/parent=] oforiginal parent immediately afteroriginal parent,preserving ranges.
   2. Ifprecedes line break is true, and the last member ofnode list does notprecede a line break, callcreateElement("br") on thecontext object and insert the result immediately after the last member ofnode list.
   3. Remove extraneous line breaks at the end oforiginal parent.
   4. Abort these steps.
7. If the first [=tree/child=] oforiginal parent is not innode list:
   1. Letcloned parent be the result of callingcloneNode(false) onoriginal parent.
   2. Iforiginal parent has an id attribute, unset it.
   3. Insertcloned parent into the [=tree/parent=] oforiginal parent immediately beforeoriginal parent.
   4. While the {{Node/ previousSibling}} of the first member ofnode list is not null, append the first [=tree/child=] oforiginal parent as the last [=tree/child=] ofcloned 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 eachnode innode list, insertnode into the [=tree/parent=] oforiginal parent immediately beforeoriginal parent,preserving ranges.

9. Iffollows line break is true, and the first member ofnode list does notfollow a line break, callcreateElement("br") on thecontext object and insert the result immediately before the first member ofnode list.
10. If the last member ofnode list is aninline node other than a [^br^], and the first [=tree/child=] oforiginal parent is a [^br^], andoriginal parent is not aninline node, remove the first [=tree/child=] oforiginal parent fromoriginal parent.
11. Iforiginal parent has no [=tree/children=]:
    1. Removeoriginal parent from its [=tree/parent=].
    2. Ifprecedes line break is true, and the last member ofnode list does notprecede a line break, callcreateElement("br") on thecontext object and insert the result immediately after the last member ofnode list.
12. Otherwise,remove extraneous line breaks beforeoriginal 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.

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

To remove anodenode whilepreserving its descendants,split the parent ofnode's [=tree/children=] if it has any. If it has no [=tree/children=], instead remove it from its [=tree/parent=].

Canonical space sequences

See long comment beforeinsertText.

Thecanonical space sequence of lengthn, with boolean flagsnon-breaking start andnon-breaking end, is returned by the following algorithm:

1. Ifn is zero, return the empty string.
2. Ifn is one and bothnon-breaking start andnon-breaking end are false, return a single space (U+0020).
3. Ifn is one, return a single non-breaking space (U+00A0).
4. Letbuffer be the empty string.
5. Ifnon-breaking start is true, letrepeated pair be U+00A0 U+0020. Otherwise, let it be U+0020 U+00A0.
6. Whilen is greater than three, appendrepeated pair tobuffer and subtract two fromn.
7. Ifn is three, append a three-code unit string tobuffer depending onnon-breaking start andnon-breaking end:

   non-breaking start andnon-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 andnon-breaking end both true

   U+00A0 U+0020 U+00A0

8. Otherwise, append a two-code unit string tobuffer depending onnon-breaking start andnon-breaking end:

   non-breaking start andnon-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 andnon-breaking end both true

   U+00A0 U+00A0

9. Returnbuffer.

Tocanonicalize whitespace at (node,offset), given an optional boolean argumentfix collapsed space that defaults to true:

1. Ifnode is neithereditable nor anediting host, abort these steps.
2. Letstart node equalnode and letstart offset equaloffset.

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

   Repeat the following steps:

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

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

      Otherwise, ifstart offset is zero andstart node does notfollow a line break andstart node's [=tree/parent=] isin the same editing host, setstart offset tostart node's [=tree/index=], then setstart node to its [=tree/parent=].

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

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

   Letend node equalstart node andend offset equalstart offset.

5. Letlength equal zero.

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

   Letcollapse spaces be true ifstart offset is zero andstart nodefollows a line break, otherwise false.

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

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

      Otherwise, ifend offset isend node's [=Node/length=] andend node does notprecede a line break andend node's [=tree/parent=] isin the same editing host, setend offset to one plusend node's [=tree/index=], then setend node to its [=tree/parent=].

   3. Otherwise, ifend node is a {{Text}} node and its [=tree/parent=]'sresolved value for "white-space" is neither "pre" nor "pre-wrap" andend offset is notend node's [=Node/length=] and theend offsetthcode unit ofend node's {{CharacterData/ data}} is a space (0x0020) or non-breaking space (0x00A0):
      1. Iffix collapsed space is true, andcollapse spaces is true, and theend offsetthcode unit ofend node's {{CharacterData/ data}} is a space (0x0020): calldeleteData(end offset, 1) onend node, then continue this loop from the beginning.
      2. Setcollapse spaces to true if theend offsetthcode unit ofend node's {{CharacterData/ data}} is a space (0x0020), false otherwise.
      3. Add one toend offset.
      4. Add one tolength.
   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).

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

   1. Ifend node has a [=tree/child=]in the same editing host with [=tree/index=]end offset − 1, setend node to that [=tree/child=], then setend offset toend node's [=Node/length=].
   2. Otherwise, ifend offset is zero andend node's [=tree/parent=] isin the same editing host, setend offset toend node's [=tree/index=], then setend node to its [=tree/parent=].
   3. Otherwise, ifend node is a {{Text}} node and its [=tree/parent=]'sresolved value for "white-space" is neither "pre" nor "pre-wrap" andend offset isend node's [=Node/length=] and the lastcode unit ofend node's {{CharacterData/ data}} is a space (0x0020) andend nodeprecedes a line break:
      1. Subtract one fromend offset.
      2. Subtract one fromlength.
      3. CalldeleteData(end offset, 1) onend node.
   4. Otherwise, break from this loop.

9. Finally we replace with the canonical sequence.

   Letreplacement whitespace be thecanonical space sequence of lengthlength.non-breaking start is true ifstart offset is zero andstart nodefollows a line break, and false otherwise.non-breaking end is true ifend offset isend node's {{CharacterData/length}} andend nodeprecedes a line break, and false otherwise.

10. While (start node,start offset) is [=boundary point/before=] (end node,end offset):
    1. Ifstart node has a [=tree/child=] with [=tree/index=]start offset, setstart node to that [=tree/child=], then setstart offset to zero.
    2. Otherwise, ifstart node is not a {{Text}} node or ifstart offset isstart node's [=Node/length=], setstart offset to one plusstart node's [=tree/index=], then setstart node to its [=tree/parent=].
    3. Otherwise:
       1. Remove the firstcode unit fromreplacement whitespace, and letelement be thatcode unit.
       2. Ifelement is not the same as thestart offsetthcode unit ofstart node's {{CharacterData/ data}}:

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

             Call insertData(start offset,element) onstart node.

          2. Call deleteData(start offset + 1, 1) onstart node.
       3. Add one tostart 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>

Toindent a listnode list of consecutive [=tree/sibling=]nodes:

1. Ifnode list is empty, do nothing and abort these steps.
2. Letfirst node be the first member ofnode list.
3. Iffirst node's [=tree/parent=] is an [^ol^] or [^ul^]:
   1. Lettag be the [=Element/local name=] of the [=tree/parent=] offirst 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 fileda bug on HTML5.

      Wrapnode list, withsibling criteria returning true for anHTML element with [=Element/local name=]tag and false otherwise, andnew parent instructions returning the result of callingcreateElement(tag) on the {{Node/ ownerDocument}} offirst 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> 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.

   Wrapnode list, withsibling criteria returning true for asimple indentation element and false otherwise, andnew parent instructions returning the result of callingcreateElement("blockquote") on the {{Node/ownerDocument}} offirst node. Letnew parent be the result.

5. Fix disallowed ancestors ofnew parent.

Tooutdent anodenode:

1. Ifnode is noteditable, 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.

   Ifnode is asimple indentation element, removenode,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.).

   Ifnode is anindentation element:

   1. Unset the dir attribute ofnode, if any.
   2. Unset the margin, padding, and border CSS properties ofnode.
   3. Set the tag name ofnode 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.

   Letcurrent ancestor benode's [=tree/parent=].

5. Letancestor list be a list ofnodes, initially empty.
6. Whilecurrent ancestor is aneditable {{Element}} that is neither asimple indentation element nor an [^ol^] nor a [^ul^], appendcurrent ancestor toancestor list and then setcurrent ancestor to its [=tree/parent=].
7. Ifcurrent ancestor is not aneditablesimple indentation element:
   1. Letcurrent ancestor benode's [=tree/parent=].
   2. Letancestor list be the empty list.
   3. Whilecurrent ancestor is aneditable {{Element}} that is neither anindentation element nor an [^ol^] nor a [^ul^], appendcurrent ancestor toancestor list and then setcurrent ancestor to its [=tree/parent=].

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

   Ifnode is an [^ol^] or [^ul^] andcurrent ancestor is not aneditableindentation element:

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

   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 (seeHTML bug 13128).

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

   4. Otherwise:
      1. Record the values ofnode's [=tree/children=], and letvalues be the result.
      2. Removenode,preserving its descendants.
      3. Restore the values fromvalues.
   5. Fix disallowed ancestors of each member ofchildren.
   6. Abort these steps.
9. Ifcurrent ancestor is not aneditableindentation element, abort these steps.

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

    Appendcurrent ancestor toancestor list.

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

    Letoriginal ancestor becurrent ancestor.

12. Whileancestor list is not empty:
    1. Letcurrent ancestor be the last member ofancestor list.
    2. Remove the last member fromancestor list.
    3. Lettarget be the [=tree/child=] ofcurrent ancestor that is equal to eithernode or the last member ofancestor list.
    4. Iftarget is aninline node that is not a [^br^], and its {{Node/nextSibling}} is a [^br^], removetarget's {{Node/nextSibling}} from its [=tree/parent=].
    5. Letpreceding siblings be the [=tree/precedings=] [=tree/siblings=] oftarget, and letfollowing siblings be the [=tree/followings=] [=tree/siblings=] oftarget.
    6. Indentpreceding siblings.
    7. Indentfollowing siblings.
13. Outdentoriginal ancestor.

Toggling lists

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

Totoggle lists, given a stringtag name (either "ol" or "ul"):

1. Letmode be "disable" if theselection's list state istag name, and "enable" otherwise.
2. Letother tag name be "ol" if tag name is "ul", and "ul" iftag name is "ol".
3. Letitems be a list of all [^li^]s that are [=tree/inclusive ancestors=] of theactive range's [=range/start=] and/or [=range/end=]node.

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

   For eachitem initems,normalize sublists ofitem.

5. Block-extend theactive range, and letnew range be the result.
6. Ifmode is "enable", then let lists to convert consist of everyeditableHTML element with [=Element/local name=]other tag name that iscontained innew range, and for everylist inlists 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.

      Iflist's {{Node/ previousSibling}} or {{Node/nextSibling}} is aneditableHTML element with [=Element/local name=]tag name:

      1. Letchildren belist's [=tree/children=].
      2. Record the values ofchildren, and letvalues be the result.
      3. Split the parent ofchildren.
      4. Wrapchildren, withsibling criteria returning true for anHTML element with [=Element/local name=]tag name and false otherwise.
      5. Restore the values fromvalues.
   2. Otherwise,set the tag name oflist totag name.
7. Letnode list be a list ofnodes, 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 eachnodenodecontained innew range, ifnode iseditable; the last member ofnode list (if any) is not an [=tree/ancestor=] ofnode;node is not anindentation element; and eithernode is an [^ol^] or [^ul^], or its [=tree/parent=] is an [^ol^] or [^ul^], or it is anallowed child of "li"; then appendnode tonode 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>

   Ifmode is "enable", remove fromnode list any [^ol^] or [^ul^] whose [=tree/parent=] is not also an [^ol^] or [^ul^].

10. Ifmode is "disable", then whilenode list is not empty:
    1. Letsublist be an empty list ofnodes.
    2. Remove the first member fromnode list and append it tosublist.
    3. If the first member ofsublist is anHTML element with [=Element/local name=]tag name,outdent it and continue this loop from the beginning.
    4. Whilenode list is not empty, and the first member ofnode list is the {{Node/nextSibling}} of the last member ofsublist and is not anHTML element with [=Element/local name=]tag name, remove the first member fromnode list and append it tosublist.
    5. Record the values ofsublist, and letvalues be the result.
    6. Split the parent ofsublist.
    7. Fix disallowed ancestors of each member ofsublist.
    8. Restore the values fromvalues.
11. Otherwise, whilenode list is not empty:
    1. Letsublist be an empty list ofnodes.

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

       While eithersublist is empty, ornode list is not empty and its first member is the {{Node/nextSibling}} ofsublist'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>.

          Ifnode list's first member is a [^p^] or [^div^],set the tag name ofnode list's first member to "li", and append the result tosublist. Remove the first member fromnode list.

       2. Otherwise, if the first member ofnode list is an [^li^] or [^ol^] or [^ul^], remove it fromnode list and append it to sublist.
       3. Otherwise:
          1. Letnodes to wrap be a list ofnodes, initially empty.
          2. Whilenodes to wrap is empty, ornode list is not empty and its first member is the {{Node/ nextSibling}} ofnodes to wrap's last member and the first member ofnode list is aninline node and the last member ofnodes to wrap is aninline node other than a [^br^], remove the first member fromnode list and append it tonodes to wrap.
          3. Wrapnodes to wrap, withnew parent instructions returning the result of calling createElement("li") on thecontext object. Append the result tosublist.

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

       Ifsublist's first member's [=tree/parent=] is anHTML element with [=Element/local name=]tag name, or if every member ofsublist is an [^ol^] or [^ul^], continue this loop from the beginning.

    4. Ifsublist's first member's [=tree/parent=] is anHTML element with [=Element/local name=]other tag name:
       1. Record the values ofsublist, and letvalues be the result.
       2. Split the parent ofsublist.
       3. Wrapsublist, withsibling criteria returning true for anHTML element with [=Element/local name=]tag name and false otherwise, andnew parent instructions returning the result of callingcreateElement(tag name) on thecontext object.
       4. Restore the values fromvalues.
       5. Continue this loop from the beginning.
    5. Wrapsublist, withsibling criteria returning true for anHTML element with [=Element/local name=]tag name and false otherwise, andnew 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 innew 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.

          Ifsublist's first member's [=tree/parent=] is not aneditablesimple indentation element, orsublist's first member's [=tree/parent=]'s {{Node/ previousSibling}} is not aneditableHTML element with [=Element/local name=]tag name, callcreateElement(tag name) on thecontext object and return the result.

       2. Letlist besublist's first member's [=tree/parent=]'s {{Node/ previousSibling}}.
       3. Normalize sublists oflist's {{Node/ lastChild}}.
       4. Iflist's {{Node/ lastChild}} is not aneditable HTML element with [=Element/local name=]tag name, callcreateElement(tag name) on thecontext object, and append the result as the last [=tree/child=] oflist.
       5. Return the last [=tree/child=] oflist.
    6. Fix disallowed ancestors of the previous step's result.

Justifying the selection

This is theaction for the fourjustify* commands. It's pretty straightforward, with no notable gotchas or special cases. It works more or less like a stripped-down version ofset 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.)

Tojustify the selection to a stringalignment (either "center", "justify", "left", or "right"):

1. Block-extend theactive range, and letnew range be the result.

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

   Letelement list be a list of alleditable {{Element}}scontained innew range that either has an attribute in theHTML namespace whose [=Attr/local name=] is "align", or has a style attribute that sets "text-align", or is a center.

3. For eachelement inelement list:
   1. Ifelement has an attribute in theHTML namespace whose [=Attr/local name=] is "align", remove that attribute.
   2. Unset the CSS property "text-align" onelement, if it's set by a style attribute.
   3. Ifelement is a [^div^] or [^span^] or center with no attributes, remove it,preserving its descendants.
   4. Ifelement is a center with one or more attributes,set the tag name ofelement 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 theactive range, and letnew range be the result.

5. Letnode list be a list ofnodes, 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 eachnodenodecontained innew range, appendnode tonode list if the last member ofnode list (if any) is not an [=tree/ancestor=] ofnode;node iseditable;node is anallowed child of "div"; andnode'salignment value is notalignment.

7. Whilenode list is not empty:
   1. Letsublist be a list of nodes, initially empty.
   2. Remove the first member ofnode list and append it tosublist.
   3. Whilenode list is not empty, and the first member ofnode list is the {{Node/nextSibling}} of the last member ofsublist, remove the first member ofnode list and append it tosublist.

   4. Wrapsublist.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 [=Attr/value=] is anASCII case-insensitive match foralignment.
      • A style attribute which sets exactly one CSS property (including unrecognized or invalid attributes), which is "text-align", which is set toalignment.

      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 callcreateElement("div") on thecontext object, then set its CSS property "text-align" toalignment 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 runthecreateLink command on it.

Anautolinkable 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 thescheme pattern fromRFC 3986 section 3.1 followed by the literal string://, or the literal stringmailto:; 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 thanspace characters; 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" or> will prevent autolinking, and a trailing$%'/\ is included in the link.

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

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

Toautolink (node,end offset):

1. While (node,end offset)'sprevious equivalent point is not null, set it to itsprevious equivalent point.
2. Ifnode is not a {{Text}} node, or has an [^a^] [=tree/ancestor=], do nothing and abort these steps.
3. Letsearch be the largest substring ofnode's {{CharacterData/ data}} whose end isend offset and that contains nospace characters.
4. If some substring ofsearch is anautolinkable URL:
   1. While there is no substring ofnode's {{CharacterData/ data}} ending atend offset that is anautolinkable URL, decrementend offset.
   2. Letstart offset be the start index of the longest substring ofnode's {{CharacterData/ data}} that is anautolinkable URL ending at end offset.
   3. Lethref be the substring ofnode's {{CharacterData/data}} starting atstart offset and ending atend offset.
5. Otherwise, if some substring ofsearch is a valid e-mail address:
   1. While there is no substring ofnode's {{CharacterData/ data}} ending atend offset that is a valid e-mail address, decrementend offset.
   2. Letstart offset be the start index of the longest substring ofnode's {{CharacterData/ data}} that is a valid e-mail address ending atend offset.
   3. Lethref be "mailto:" concatenated with the substring ofnode's {{CharacterData/data}} starting atstart offset and ending atend offset.
6. Otherwise, do nothing and abort these steps.
7. Letoriginal range be theactive range.
8. Create a new [=range=] with [=range/start=] (node,start offset) and [=range/end=] (node,end offset), and set thecontext object'sselection's [=range=] to it.
9. Take theaction for "createLink", withvalue equal tohref.
10. Set thecontext object'sselection's [=range=] tooriginal range.

Thedelete command

Preserves overrides

For all the deletions here, Firefox 7.0a2 will remove wrapper elements like <b> only if they're selected, like {<b>foo</b>}. IE9, Chrome 14 dev, and Opera 11.50 will all remove them even if only their contents are selected, like <b>[foo]</b>. Gecko's behavior in the latter case leaves things like <b>{}</b> in the DOM, which is unhelpful, so I don't.

Action:

1. If theactive range is not {{AbstractRange/collapsed}},delete the selection and return true.

2. Needed so that if there are multiple consecutive spaces we backspace over all at once.

   Canonicalize whitespace at theactive range's [=range/start=].

3. Letnode andoffset be theactive range's [=range/start=]node and [=boundary point/offset=].

4. First go up as high as possible within the current block, then drill down to the lowest possible level, in the hopes that we'll wind up at the end of a text node, or maybe in a br or hr.

   Repeat the following steps:

   1. If there's an invisible node somewhere, Firefox 5.0a2 removes that node and then stops, so each backspace removes one invisible node. All others remove the invisible node and then continue on looking for something visible to remove. The spec follows the latter behavior, since it makes more sense to the user. Of course, the definition of "invisible node" is not necessarily anything like the spec's.

      Ifoffset is zero andnode's {{Node/ previousSibling}} is aneditableinvisiblenode, removenode's {{Node/ previousSibling}} from its [=tree/parent=].

   2. Otherwise, ifnode has a [=tree/child=] with [=tree/index=]offset − 1 and that [=tree/child=] is aneditableinvisiblenode, remove that [=tree/child=] fromnode, then subtract one fromoffset.
   3. Otherwise, ifoffset is zero andnode is aninline node, or ifnode is aninvisiblenode, setoffset to the [=tree/index=] ofnode, then setnode to its [=tree/parent=].

   4. When backspacing a link, Firefox 7.0a2, Chrome 14 dev, Opera 11.50, and OpenOffice.org 3.2.1 Ubuntu have no special behavior. IE9 and Word 2007 remove the link instead of deleting its last character. The latter behavior seems more useful and intuitive.

      Otherwise, ifnode has a [=tree/child=] with [=tree/index=]offset − 1 and that [=tree/child=] is aneditable [^a^], remove that [=tree/child=] fromnode,preserving its descendants. Then return true.

   5. Otherwise, ifnode has a [=tree/child=] with [=tree/index=]offset − 1 and that [=tree/child=] is not ablock node or a [^br^] or an [^img^], setnode to that [=tree/child=], then setoffset to the [=Node/length=] ofnode.
   6. Otherwise, break from this loop.

5. At this point, node cannot be an invisible node. There are three cases:

   1. offset is zero and node is a block node. Then we'll usually merge with the previous block if one exists.
   2. offset is not zero,node is not a block node, andnode does not have a child with indexoffset − 1. The only way this is possible is if node has a length greater than zero but no children, which implies it's a text or comment or PI. Comments and PIs are invisible nodes, so it must be a text node. We delete the previous character.
   3. offset is not zero, and the child ofnode with indexoffset − 1 is a block node or a br or an img. Then we'll usually merge theoffsetth child ofnode with the last descendant of theoffset − 1st.

   Unlike forwardDelete, there's no special case for diacritics. This means backspacing will just delete the last combining diacritic typed, or the whole character if it's precomposed. This matches everything I tested (IE9, Firefox 7.0a2, Chrome 14 dev, etc.).

   Ifnode is a {{Text}} node andoffset is not zero, or ifnode is ablock node that has a [=tree/child=] with [=tree/index=]offset − 1 and that [=tree/child=] is a [^br^] or [^hr^] or [^img^]:

   1. Callcollapse(node,offset) on thecontext object'sselection.
   2. Callextend(node,offset − 1) on thecontext object'sselection.
   3. Delete the selection.
   4. Return true.

6. At the time of this writing, this should be impossible. Just being safe.

   Ifnode is aninline node, return true.

7. If we're at the beginning of a list, we want to outdent the first list item. This doesn't actually match anyone or anything. Word 2007 and OpenOffice.org 3.2.1 Ubuntu just remove the list marker, which is weird and doesn't map well to HTML. Browsers tend to just merge with the preceding block, which isn't expected.

   Ifnode is an [^li^] or [^dt^] or [^dd^] and is the first [=tree/child=] of its [=tree/parent=], andoffset is zero:

   1. Letitems be a list of all [^li^]s that are [=tree/ancestors=] ofnode.
   2. Normalize sublists of eachitem initems.
   3. Record the values of the one-node list consisting ofnode, and letvalues be the result.
   4. Split the parent of the one-node list consisting ofnode.
   5. Restore the values fromvalues.

   6. 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.

      Ifnode is a [^dd^] or [^dt^], and it is not anallowed child of any of its [=tree/ancestors=]in the same editing host,set the tag name ofnode to thedefault single-line container name and letnode be the result.

   7. Fix disallowed ancestors ofnode.
   8. Return true.

8. By this point, we're almost certainly going to merge something, and the only question is what.

   Letstart node equalnode and letstart offset equaloffset.

9. Repeat the following steps:
   1. Ifstart offset is zero, setstart offset to the [=tree/index=] ofstart node and then setstart node to its [=tree/parent=].
   2. Otherwise, ifstart node has aneditableinvisible [=tree/child=] with [=tree/index=]start offset minus one, remove it fromstart node and subtract one fromstart offset.
   3. Otherwise, break from this loop.

10. At the beginning of an indented block, outdent it, similar to a list item. Browsers don't do this, word processors do. Note: this copy-pastes from the outdent command action.

    Ifoffset is zero, andnode has aneditable [=tree/inclusive ancestor=]in the same editing host that's anindentation element:

    1. Block-extend the [=range=] whose [=range/start=] and [=range/end=] are both (node, 0), and letnew range be the result.
    2. Letnode list be a list of nodes, initially empty.
    3. For each nodecurrent nodecontained innew range, appendcurrent node tonode list if the last member ofnode list (if any) is not an [=tree/ancestor=] ofcurrent node, andcurrent node iseditable but has noeditable [=tree/descendants=].
    4. Outdent eachnode innode list.
    5. Return true.

11. This is to avoid stripping a line break from

    foo<br><br><table><tr><td>[]bar</table>

    and similarly for <hr>. We should just do nothing here.

    If the [=tree/child=] ofstart node with [=tree/index=]start offset is a [^table^], return true.

12. If you try backspacing into a table, select it. This doesn't match any browser; it matches the recommendation of the "behavior when typing in contentEditable elements" document. The idea is that then you can delete it with a second backspace.

    Ifstart node has a [=tree/child=] with [=tree/index=]start offset − 1, and that [=tree/child=] is a [^table^]:

    1. Callcollapse(start node,start offset − 1) on thecontext object'sselection.
    2. Callextend(start node,start offset) on thecontext object'sselection.
    3. Return true.

13. Special case:

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

    and likewise for <hr>. But with <img> we merge like in other cases:

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

    Browsers don't do this consistently. Firefox 5.0a2 doesn't seem to do it at all.

    Ifoffset is zero; and either the [=tree/child=] ofstart node with [=tree/index=]start offset minus one is an [^hr^], or the [=tree/child=] is a [^br^] whose {{Node/previousSibling}} is either a [^br^] or not aninline node:

    1. Callcollapse(start node,start offset − 1) on thecontext object'sselection.
    2. Callextend(start node,start offset) on thecontext object'sselection.
    3. Delete the selection.
    4. Callcollapse(node,offset) on theselection.
    5. Return true.

14. If you try backspacing out of a list item, merge it with the previous item, but add a line break. Then you have to backspace again if you really want them to be on the same line. This matches Word 2007 and OpenOffice.org 3.2.1 Ubuntu, and also matches "behavior when typing in contentEditable elements", but does not match any browser.

    Note that this behavior is quite different from what happens if you actually select the linebreak in between the two lines. In that case, the blocks are merged as normal.

    Also note that hitting backspace twice will merge with the previous item. This matches OO.org, but Word will outdent the item on subsequent backspaces. Word's behavior doesn't fit well with the way lists work in HTML, and we probably don't want it.

    If the [=tree/child=] ofstart node with [=tree/index=]start offset is an [^li^] or [^dt^] or [^dd^], and that [=tree/child=]'s {{Node/firstChild}} is aninline node, andstart offset is not zero:

    1. Letprevious item be the [=tree/child=] ofstart node with [=tree/index=]start offset minus one.

    2. If the last child is already a br, we only need to append one extra br. Otherwise we need to append two, since the first will do nothing.

       Ifprevious item's {{Node/lastChild}} is aninline node other than a [^br^], callcreateElement("br") on thecontext object and append the result as the last [=tree/child=] ofprevious item.

    3. Ifprevious item's {{Node/lastChild}} is aninline node, callcreateElement("br") on thecontext object and append the result as the last [=tree/child=] ofprevious item.

15. When merging adjacent list items, make sure we only merge the items themselves, not any block children. We want<li><p>foo<li><p>[]bar to become<li><p>foo<p>[]bar, not<li><p>foo<br>[]bar or<li><p>foo[]bar. To do the deletion, we need to wipe out the current selection, so we save it as a range. Saving it as a node/offset pair isn't enough, because it might be invalid after we do the deletion. A range will update according to the range mutation rules.

    Ifstart node's [=tree/child=] with [=tree/index=]start offset is an [^li^] or [^dt^] or [^dd^], and that [=tree/child=]'s {{Node/previousSibling}} is also an [^li^] or [^dt^] or [^dd^]:

    1. CallcloneRange() on theactive range, and letoriginal range be the result.
    2. Setstart node to its [=tree/child=] with [=tree/index=]start offset − 1.
    3. Setstart offset tostart node's [=Node/length=].
    4. Setnode tostart node's {{Node/nextSibling}}.
    5. Callcollapse(start node,start offset) on thecontext object'sselection.
    6. Callextend(node, 0) on thecontext object'sselection.
    7. Delete the selection.
    8. CallremoveAllRanges() on thecontext object'sselection.
    9. CalladdRange(original range) on thecontext object'sselection.
    10. Return true.

16. General block-merging case.

    Whilestart node has a [=tree/child=] with [=tree/index=]start offset minus one:

    1. Ifstart node's [=tree/child=] with [=tree/index=]start offset minus one iseditable andinvisible, remove it fromstart node, then subtract one fromstart offset.
    2. Otherwise, setstart node to its [=tree/child=] with [=tree/index=]start offset minus one, then setstart offset to the [=Node/length=] ofstart node.
17. Callcollapse(start node,start offset) on thecontext object'sselection.
18. Callextend(node,offset) on thecontext object'sselection.
19. Delete the selection, withdirection "backward".
20. Return true.

TheformatBlock command

This command lets you change what block element particular lines are wrapped in. It will convert an existing wrapper if one exists, and otherwise will create a new one.

Aformattable block name is "address", "dd", "div", "dt", "h1", "h2", "h3", "h4", "h5", "h6", "p", or "pre".

Preserves overrides

Action:

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

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

2. Letvalue beconverted 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.

   Ifvalue is not aformattable block name, return false.

4. Block-extend theactive range, and letnew range be the result.
5. Letnode list be an empty list ofnodes.
6. For eachnodenodecontained innew range, appendnode tonode list if it iseditable, the last member oforiginal node list (if any) is not an [=tree/ancestor=] ofnode,node is either anon-list single-line container or anallowed child of "p" or a [^dd^] or [^dt^], andnode is not the [=tree/ancestor=] of aprohibited paragraph child.
7. Record the values ofnode list, and letvalues 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 eachnode innode list, whilenode is the [=tree/descendant=] of aneditableHTML elementin the same editing host, whose [=Element/local name=] is aformattable block name, and which is not the [=tree/ancestor=] of aprohibited paragraph child,split the parent of the one-node list consisting ofnode.

9. Restore the values fromvalues.

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.

    Whilenode list is not empty:

    1. If the first member ofnode list is asingle-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.

          Letsublist be the [=tree/children=] of the first member ofnode list.

       2. Record the values ofsublist, and letvalues be the result.
       3. Remove the first member ofnode list from its [=tree/parent=],preserving its descendants.
       4. Restore the values fromvalues.
       5. Remove the first member fromnode list.
    2. Otherwise:
       1. Letsublist be an empty list ofnodes.
       2. Remove the first member ofnode list and append it tosublist.
       3. Whilenode list is not empty, and the first member ofnode list is the {{Node/ nextSibling}} of the last member ofsublist, and the first member ofnode list is not asingle-line container, and the last member ofsublist is not a [^br^], remove the first member ofnode list and append it tosublist.
    3. Wrapsublist. Ifvalue is "div" or "p",sibling criteria returns false; otherwise it returns true for anHTML element with [=Element/local name=]value and no attributes, and false otherwise.New parent instructions return the result of runningcreateElement(value) on thecontext object. Thenfix 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 theactive range is null, return the empty string.
2. Block-extend theactive range, and letnew range be the result.
3. Letnode list be allvisibleeditablenodes that are contained innew range and have no [=tree/children=].
4. Ifnode list is empty, return false.
5. Lettype be null.
6. For eachnode innode list:
   1. Whilenode's [=tree/parent=] iseditable andin the same editing host asnode, andnode is not anHTML element whose [=Element/local name=] is aformattable block name, setnode to its [=tree/parent=].
   2. Letcurrent type be the empty string.
   3. Ifnode is aneditableHTML element whose [=Element/local name=] is aformattable block name, andnode is not the [=tree/ancestor=] of aprohibited paragraph child, setcurrent type to node's [=Element/local name=].
   4. Iftype is null, settype tocurrent type.
   5. Otherwise, iftype does not equalcurrent type, return true.
7. Return false.

Value:

1. If theactive range is null, return the empty string.
2. Block-extend theactive range, and letnew range be the result.
3. Letnode be the firstvisibleeditablenode that iscontained innew range and has no [=tree/children=]. If there is no suchnode, 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>.

   Whilenode's [=tree/parent=] iseditable andin the same editing host asnode, andnode is not anHTML element whose [=Element/local name=] is aformattable block name, setnode to its [=tree/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.

   Ifnode is aneditableHTML element whose [=Element/local name=] is aformattable block name, andnode is not the [=tree/ancestor=] of aprohibited paragraph child, returnnode's [=Element/local name=],converted to ASCII lowercase.

6. Return the empty string.

TheforwardDelete command

This is the same as hitting the delete key (seeAdditional requirements). It behaves much the same asthedelete 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 theactive range is not {{AbstractRange/collapsed}},delete the selection and return true.
2. Canonicalize whitespace at theactive range's [=range/start=].
3. Letnode andoffset be theactive range's [=range/start=]node and [=boundary point/offset=].
4. Repeat the following steps:
   1. Ifoffset is the [=Node/length=] ofnode andnode's {{Node/nextSibling}} is aneditableinvisible node, removenode's {{Node/nextSibling}} from its [=tree/parent=].
   2. Otherwise, ifnode has a [=tree/child=] with [=tree/index=]offset and that [=tree/child=] is aneditableinvisiblenode, remove that [=tree/child=] fromnode.
   3. Otherwise, ifoffset is the [=Node/length=] ofnode andnode is aninline node, or ifnode isinvisible, setoffset to one plus the [=tree/index=] ofnode, then setnode to its [=tree/parent=].

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

      Otherwise, ifnode has a [=tree/child=] with [=tree/index=]offset and that [=tree/child=] is neither ablock node nor a [^br^] nor an [^img^] nor acollapsed block prop, setnode to that [=tree/child=], then setoffset to zero.

   5. Otherwise, break from this loop.
5. Ifnode is a {{Text}} node and offset is notnode's [=Node/length=]:
   1. Letend offset beoffset 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.

      Whileend offset is notnode's [=Node/length=] and theend offsetthcode unit ofnode's {{CharacterData/ data}} has general category M when interpreted as a Unicode code point, add one toend offset.

   3. Callcollapse(node,offset) on thecontext object'sselection.
   4. Callextend(node,end offset) on thecontext object'sselection.
   5. Delete the selection.
   6. Return true.
6. Ifnode is aninline node, return true.
7. Ifnode has a [=tree/child=] with [=tree/index=]offset and that [=tree/child=] is a [^br^] or [^hr^] or [^img^], but is not acollapsed block prop:
   1. Callcollapse(node,offset) on thecontext object'sselection.
   2. Callextend(node,offset + 1) on thecontext object'sselection.
   3. Delete the selection.
   4. Return true.

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

   Letend node equalnode and letend offset equaloffset.

9. Ifend node has a [=tree/child=] with [=tree/index=]end offset, and that [=tree/child=] is acollapsed block prop, add one toend offset.
10. Repeat the following steps:
    1. Ifend offset is the [=Node/length=] ofend node, setend offset to one plus the [=tree/index=] ofend node and then setend node to its [=tree/parent=].
    2. Otherwise, ifend node has aneditableinvisible [=tree/child=] with [=tree/index=]end offset, remove it fromend node.
    3. Otherwise, break from this loop.

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

    If the [=tree/child=] ofend node with [=tree/index=]end offset minus one is a [^table^], return true.

12. If the [=tree/child=] ofend node with [=tree/index=]end offset is a [^table^]:
    1. Callcollapse(end node,end offset) on thecontext object'sselection.
    2. Callextend(end node,end offset + 1) on thecontext object'sselection.
    3. Return true.

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

    Ifoffset is the [=Node/length=] ofnode, and the [=tree/child=] ofend node with [=tree/index=]end offset is an [^hr^] or [^br^]:

    1. Callcollapse(end node,end offset) on thecontext object'sselection.
    2. Callextend(end node,end offset + 1) on thecontext object'sselection.
    3. Delete the selection.
    4. Callcollapse(node,offset) on theselection.
    5. Return true.

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

    Whileend node has a [=tree/child=] with [=tree/index=]end offset:

    1. Ifend node's [=tree/child=] with [=tree/index=]end offset iseditable andinvisible, remove it fromend node.
    2. Otherwise, setend node to its [=tree/child=] with [=tree/index=]end offset and setend offset to zero.
15. Callcollapse(node,offset) on thecontext object'sselection.
16. Callextend(end node,end offset) on thecontext object'sselection.
17. Delete the selection.

Theindent command

This command must not beenabled if theediting host is in theplaintext-only state.

Preserves overrides

Action:

1. Letitems be a list of all [^li^]s that are [=tree/inclusive ancestors=] of theactive range's [=range/start=] and/or [=range/end=]node.

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

   For eachitem initems,normalize sublists ofitem.

3. Block-extend theactive range, and letnew range be the result.
4. Letnode list be a list ofnodes, initially empty.
5. For eachnodenodecontained innew range, ifnode iseditable and is anallowed child of "div" or "ol" and if the last member ofnode list (if any) is not an [=tree/ancestor=] ofnode, appendnode tonode 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 firstvisible member ofnode list is an [^li^] whose [=tree/parent=] is an [^ol^] or [^ul^]:

   1. Letsibling benode list's firstvisible member's {{Node/ previousSibling}}.
   2. Whilesibling isinvisible, setsibling to its {{Node/ previousSibling}}.
   3. Ifsibling is an [^li^],normalize sublists ofsibling.
7. Whilenode list is not empty:
   1. Letsublist be a list of nodes, initially empty.
   2. Remove the first member ofnode list and append it tosublist.
   3. While the first member ofnode list is the {{Node/nextSibling}} of the last member ofsublist, remove the first member ofnode list and append it tosublist.
   4. Indentsublist.

TheinsertHorizontalRule command

This command must not beenabled if theediting host is in theplaintext-only state.

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. Letstart node,start offset,end node, andend offset be theactive range's [=range/start=] and [=range/end=]nodes and [=boundary point/offsets=].
2. Whilestart offset is 0 andstart node's [=tree/parent=] is not null, set start offset tostart node's [=tree/index=], then setstart node to its [=tree/parent=].
3. Whileend offset isend node's [=Node/length=], andend node's [=tree/parent=] is not null, setend offset to one plusend node's [=tree/index=], then setend node to its [=tree/parent=].
4. Callcollapse(start node,start offset) on thecontext object'sselection.
5. Callextend(end node,end offset) on thecontext object'sselection.
6. Delete the selection, withblock merging false.
7. If theactive range's [=range/start node=] is neithereditable 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 theactive range's [=range/start node=] is a {{Text}} node and its [=range/start offset=] is zero, callcollapse() on thecontext object'sselection, with first argument theactive range's [=range/start node=]'s [=tree/parent=] and second argument theactive range's [=range/start node=]'s [=tree/index=].

9. If theactive range's [=range/start node=] is a {{Text}} node and its [=range/start offset=] is the [=Node/length=] of its [=range/start node=], callcollapse() on thecontext object'sselection, with first argument theactive range's [=range/start node=]'s [=tree/parent=], and the second argument one plus theactive range's [=range/start node=]'s [=tree/index=].
10. Lethr be the result of callingcreateElement("hr") on thecontext object.
11. RuninsertNode(hr) on theactive 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 ofhr.

13. Runcollapse() on thecontext object'sselection, with first argumenthr's [=tree/parent=] and the second argument equal to one plushr's [=tree/index=].
14. Return true.

TheinsertHTML command

Preserves overrides

Action:

1. Setvalue to the result of invoking get trusted types compliant string withTrustedHTML,this'srelevant global object,value, "Document execCommand", and "script".

2. 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.

3. If theactive range's [=range/start node=] is neithereditable nor an [=editing host=], return true.

4. 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.

   Letfrag be the result of calling createContextualFragment(value) on theactive range.

5. Letlast child be the {{Node/lastChild}} offrag.

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

   Iflast child is null, return true.

7. Letdescendants be all [=tree/descendants=] offrag.

8. 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 theactive range's [=range/start node=] is ablock node:

   1. Letcollapsed block props be alleditablecollapsed block prop [=tree/children=] of theactive range's [=range/start node=] that have [=tree/index=] greater than or equal to theactive range's [=range/start offset=].
   2. For eachnode incollapsed block props, removenode from its [=tree/parent=].

9. 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.

   CallinsertNode(frag) on theactive range.

10. 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 theactive range's [=range/start node=] is ablock node with novisible [=tree/children=], callcreateElement("br") on thecontext object and append the result as the last child of theactive range's [=range/start node=].

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

    Callcollapse() on thecontext object'sselection, withlast child's [=tree/parent=] as the first argument and one plus its [=tree/index=] as the second.

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

    Fix disallowed ancestors of each member ofdescendants.

13. Return true.

TheinsertImage command

This command must not beenabled if theediting host is in theplaintext-only state.

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.

   Ifvalue 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, withstrip wrappers false.

3. Letrange be theactive range.
4. If theactive range's [=range/start node=] is neithereditable nor an [=editing host=], return true.

5. Same logic as with insertHTML.

   Ifrange's [=range/start node=] is ablock node whose sole [=tree/child=] is a [^br^], and its [=range/start offset=] is 0, remove its [=range/start node=]'s [=tree/child=] from it.

6. Letimg be the result of callingcreateElement("img") on thecontext object.

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

   RunsetAttribute("src",value) onimg.

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()).

   RuninsertNode(img) onrange.

   An image could be inserted inside a link, with either this command or insertHTML. On Chrome 51 dev, inserting an image (with insertImage or insertHTML) inside a link will remove the parent link. Firefox 48 allows this nesting.

9. Letselection be the result of callinggetSelection() on thecontext object.
10. Runcollapse() onselection, with first argument equal to the [=tree/parent=] ofimg and the second argument equal to one plus the [=tree/index=] ofimg.
11. Return true.

TheinsertLineBreak command

This is the same as hitting Shift-Enter or such (seeAdditional 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, withstrip wrappers false.

2. If theactive range's [=range/start node=] is neithereditable nor an [=editing host=], return true.

3. script, xmp, table, . . .

   If theactive range's [=range/start node=] is an {{Element}}, and "br" is not anallowed child of it, return true.

4. If theactive range's [=range/start node=] is not an {{Element}}, and "br" is not anallowed child of theactive range's [=range/start node=]'s [=tree/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 theactive range's [=range/start node=] is a {{Text}} node and its [=range/start offset=] is zero, callcollapse() on thecontext object'sselection, with first argument equal to theactive range's [=range/start node=]'s [=tree/parent=] and second argument equal to theactive range's [=range/start node=]'s [=tree/index=].

6. If theactive range's [=range/start node=] is a {{Text}} node and its [=range/start offset=] is the [=Node/length=] of its [=range/start node=], callcollapse() on thecontext object'sselection, with first argument equal to theactive range's [=range/start node=]'s [=tree/parent=] and second argument equal to one plus theactive range's [=range/start node=]'s [=tree/index=].
7. Letbr be the result of callingcreateElement("br") on thecontext object.
8. CallinsertNode(br) on theactive range.
9. Callcollapse() on thecontext object'sselection, withbr's [=tree/parent=] as the first argument and one plusbr's [=tree/index=] as the second argument.
10. Ifbr is acollapsed line break, callcreateElement("br") on thecontext object and letextra br be the result, then callinsertNode(extra br) on theactive range.
11. Return true.

TheinsertOrderedList command

This command must not beenabled if theediting host is in theplaintext-only state.

Preserves overrides

Action:Toggle lists withtag 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 theselection'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 theselection's list state is "ol", false otherwise.

TheinsertParagraph command

Preserves overrides

Action:

1. Delete the selection.
2. If theactive range's [=range/start node=] is neithereditable nor an [=editing host=], return true.
3. Letnode andoffset be theactive range's [=range/start=]node and [=boundary point/offset=].
4. Ifnode is a {{Text}} node, andoffset is neither 0 nor the [=Node/length=] ofnode, callsplitText(offset) onnode.
5. Ifnode is a {{Text}} node and offset is its [=Node/length=], setoffset to one plus the [=tree/index=] ofnode, then setnode to its [=tree/parent=].
6. Ifnode is a {{Text}} or {{Comment}} node, setoffset to the [=tree/index=] ofnode, then setnode to its [=tree/parent=].
7. Callcollapse(node,offset) on thecontext object'sselection.
8. Letcontainer equalnode.
9. Whilecontainer is not asingle-line container, andcontainer's [=tree/parent=] iseditable andin the same editing host asnode, setcontainer to its [=tree/parent=].

10. Bug 13841.

    Ifcontainer is aneditablesingle-line containerin the same editing host asnode, and its [=Element/local name=] is "p" or "div":

    1. Letouter container equal container.
    2. Whileouter container is not a [^dd^] or [^dt^] or [^li^], andouter container's [=tree/parent=] iseditable, setouter container to its [=tree/parent=].
    3. Ifouter container is a [^dd^] or [^dt^] or [^li^], setcontainer toouter container.

11. We add the default wrapper in this case.

    Ifcontainer is noteditable or notin the same editing host asnode or is not asingle-line container:

    1. Lettag be thedefault single-line container name.
    2. Block-extend theactive range, and letnew range be the result.
    3. Letnode list be a list of nodes, initially empty.
    4. Append tonode list the first node in [=tree order=] that iscontained innew range and is anallowed child of "p", if any.
    5. Ifnode 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>.

          Iftag is not anallowed child of theactive range's [=range/start node=], return true.

       2. Setcontainer to the result of callingcreateElement(tag) on thecontext object.
       3. CallinsertNode(container) on theactive range.
       4. CallcreateElement("br") on thecontext object, and append the result as the last [=tree/child=] ofcontainer.
       5. Callcollapse(container, 0) on thecontext object'sselection.
       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 {{Node/nextSibling}} of the last member ofnode list is not null and is anallowed child of "p", append it tonode list.

    7. Wrapnode list, withsibling criteria returning false andnew parent instructions returning the result of callingcreateElement(tag) on thecontext object. Setcontainer 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.

    Ifcontainer's [=Element/local name=] is "address", "listing", or "pre":

    1. Letbr be the result of callingcreateElement("br") on thecontext object.
    2. CallinsertNode(br) on theactive range.
    3. Callcollapse(node,offset + 1) on thecontext object'sselection.

    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.

       Ifbr is the last [=tree/descendant=] ofcontainer, letbr be the result of callingcreateElement("br") on thecontext object, then callinsertNode(br) on theactive range.

    5. Return true.

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

    Ifcontainer's [=Element/local name=] is "li", "dt", or "dd"; and either it has no [=tree/children=] or it has a single [=tree/child=] and that [=tree/child=] is a [^br^]:

    1. Split the parent of the one-node list consisting ofcontainer.
    2. Ifcontainer has no [=tree/children=], callcreateElement("br") on thecontext object and append the result as the last [=tree/child=] ofcontainer.

    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.

       Ifcontainer is a [^dd^] or [^dt^], and it is not anallowed child of any of its [=tree/ancestors=]in the same editing host,set the tag name ofcontainer to thedefault single-line container name and letcontainer be the result.

    4. Fix disallowed ancestors ofcontainer.
    5. Return true.
14. Letnew line range be a new [=range=] whose [=range/start=] is the same as theactive range's, and whose [=range/end=] is (container, [=Node/length=] ofcontainer).

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.

    Whilenew line range's [=range/start offset=] is zero and its [=range/start node=] is not aprohibited paragraph child, set its [=range/start=] to ([=tree/parent=] of [=range/start node=], [=tree/index=] of [=range/start node=]).

16. Whilenew line range's [=range/start offset=] is the [=Node/length=] of its [=range/start node=] and its [=range/start node=] is not a prohibited paragraph child, set its [=range/start=] to ([=tree/parent=] of [=range/start node=], 1 + [=tree/index=] of [=range/start node=]).
17. Letend of line be true ifnew line rangecontains 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 [=Element/local name=] ofcontainer is "h1", "h2", "h3", "h4", "h5", or "h6", andend of line is true, letnew container name be thedefault 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 [=Element/local name=] ofcontainer is "dt" andend of line is true, letnew container name be "dd".

20. Otherwise, if the [=Element/local name=] ofcontainer is "dd" andend of line is true, letnew container name be "dt".
21. Otherwise, letnew container name be the [=Element/local name=] ofcontainer.
22. Letnew container be the result of callingcreateElement(new container name) on thecontext object.
23. Copy all attributes ofcontainer tonew container.
24. Ifnew container has an id attribute, unset it.
25. Insertnew container into the [=tree/parent=] ofcontainer immediately aftercontainer.
26. Letcontained nodes be allnodescontained innew 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.

    Letfrag be the result of callingextractContents() onnew line range.

28. Unset the id attribute (if any) of each {{Element}} [=tree/descendant=] offrag that is not incontained nodes.
29. CallappendChild(frag) onnew container.

30. Needed in case we have something like<ol><li><p>[]foo</ol>, which becomes<ol><li><p><li><p>foo</ol>. In this case we want to add the [^br^] to the [^p^], not the [^li^]. Likewise for<ol><li><p>foo[]</ol>.

    Whilecontainer's {{Node/lastChild}} is aprohibited paragraph child, setcontainer to its {{Node/lastChild}}.

31. Whilenew container'slastChild is aprohibited paragraph child, setnew container to its {{Node/lastChild}}.
32. Ifcontainer has novisible [=tree/children=], callcreateElement("br") on thecontext object, and append the result as the last [=tree/child=] ofcontainer.

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.

    Ifnew container has novisible [=tree/children=], callcreateElement("br") on thecontext object, and append the result as the last [=tree/child=] ofnew container.

34. Callcollapse(new container, 0) on thecontext object'sselection.
35. Return true.

TheinsertText 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, withstrip wrappers false.

2. If theactive range's [=range/start node=] is neithereditable nor an [=editing host=], return true.
3. Ifvalue'slength is greater than one:
   1. For eachcode unitel invalue, take theaction fortheinsertText command, withvalue equal toel.
   2. Return true.
4. Ifvalue is the empty string, return true.

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

   Ifvalue is a newline (U+000A), take theaction fortheinsertParagraph command and return true.

6. Letnode andoffset be theactive range's [=range/start node=] and [=boundary point/offset=].

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.

   Ifnode has a [=tree/child=] whose [=tree/index=] isoffset − 1, and that [=tree/child=] is a {{Text}} node, setnode to that [=tree/child=], then setoffset tonode's [=Node/length=].

8. Ifnode has a [=tree/child=] whose [=tree/index=] isoffset, and that [=tree/child=] is a {{Text}} node, setnode to that [=tree/child=], then setoffset to zero.
9. Record current overrides, and letoverrides be the result.
10. Callcollapse(node,offset) on thecontext object'sselection.
11. Canonicalize whitespace at (node,offset).
12. Let (node,offset) be theactive range's [=range/start=].
13. Ifnode is a {{Text}} node:
    1. CallinsertData(offset,value) onnode.
    2. Callcollapse(node,offset) on thecontext object'sselection.
    3. Callextend(node,offset + 1) on thecontext object'sselection.
14. Otherwise:

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

       Ifnode has only one [=tree/child=], which is acollapsed line break, remove its [=tree/child=] from it.

    2. Lettext be the result of callingcreateTextNode(value) on thecontext object.
    3. CallinsertNode(text) on theactive range.
    4. Callcollapse(text, 0) on thecontext object'sselection.
    5. Callextend(text, 1) on thecontext object'sselection.
15. Restore states and values fromoverrides.
16. Canonicalize whitespace at theactive range's [=range/start=], withfix collapsed space false.
17. Canonicalize whitespace at theactive range's [=range/end=], withfix collapsed space false.
18. Ifvalue is aspace character,autolink theactive range's [=range/start=].
19. CallcollapseToEnd() on thecontext object'sselection.
20. Return true.

TheinsertUnorderedList command

This command must not beenabled if theediting host is in theplaintext-only state.

Preserves overrides

See comments forinsertOrderedList.

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

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

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

ThejustifyCenter command

This command must not beenabled if theediting host is in theplaintext-only state.

Preserves overrides

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

Indeterminate: Return false if theactive range is null. Otherwise,block-extend theactive range. Return true if amongvisibleeditablenodes that arecontained in the result and have no [=tree/children=], at least one hasalignment value "center" and at least one does not. Otherwise return false.

State: Return false if theactive range is null. Otherwise,block-extend theactive range. Return true if there is at least onevisibleeditablenode that iscontained in the result and has no [=tree/children=], and all suchnodes havealignment 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 theactive range is null. Otherwise,block-extend theactive range, and return thealignment value of the firstvisibleeditablenode that iscontained in the result and has no [=tree/children=]. If there is no suchnode, return "left".

ThejustifyFull command

This command must not beenabled if theediting host is in theplaintext-only state.

Preserves overrides

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

Indeterminate: Return false if theactive range is null. Otherwise,block-extend theactive range. Return true if amongvisibleeditablenodes that arecontained in the result and have no [=tree/children=], at least one hasalignment value "justify" and at least one does not. Otherwise return false.

State: Return false if theactive range is null. Otherwise,block-extend theactive range. Return true if there is at least onevisibleeditablenode that iscontained in the result and has no [=tree/children=], and all suchnodes havealignment value "justify". Otherwise return false.

Value: Return the empty string if theactive range is null. Otherwise,block-extend theactive range, and return thealignment value of the firstvisibleeditablenode that iscontained in the result and has no [=tree/children=]. If there is no suchnode, return "left".

ThejustifyLeft command

This command must not beenabled if theediting host is in theplaintext-only state.

Preserves overrides

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

Indeterminate: Return false if theactive range is null. Otherwise,block-extend theactive range. Return true if amongvisibleeditablenodes that arecontained in the result and have no [=tree/children=], at least one hasalignment value "left" and at least one does not. Otherwise return false.

State: Return false if theactive range is null. Otherwise,block-extend theactive range. Return true if there is at least onevisibleeditablenode that iscontained in the result and has no [=tree/children=], and all suchnodes havealignment value "left". Otherwise return false.

Value: Return the empty string if theactive range is null. Otherwise,block-extend theactive range, and return thealignment value of the firstvisibleeditablenode that iscontained in the result and has no [=tree/children=]. If there is no suchnode, return "left".

ThejustifyRight command

This command must not beenabled if theediting host is in theplaintext-only state.

Preserves overrides

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