--- a/editcommands.html Wed Jul 13 11:39:49 2011 -0600
+++ b/editcommands.html Wed Jul 13 12:10:21 2011 -0600
@@ -41,7 +41,7 @@
<h2 class="no-num no-toc" id=work-in-progress-—-last-update-13-july-2011>Work in Progress — Last Update 13 July 2011</h2>
<dl>
<dt>Editor
- <dd>Aryeh Gregor <ayg+spec@aryeh.name>
+ <dd>Aryeh Gregor <<a href=mailto:ayg@aryeh.name>ayg@aryeh.name</a>>
<dt>Version history
<dd><a href="http://aryeh.name/gitweb.cgi?p=editcommands">http://aryeh.name/gitweb.cgi?p=editcommands</a>
@@ -52,13 +52,14 @@
<h2 class=no-num id=status-of-this-document>Status of this Document</h2>
<p>This document is an early draft of a specification for HTML editing APIs,
-defining <code><a href=#execcommand()>execCommand()</a></code> and related functions. It will eventually
-be merged into the main <a href=http://www.whatwg.org/html>HTML</a>
-specification, replacing the <a href=http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#editing-apis>Editing
-APIs</a> section. Although this spec is still very incomplete and will likely
-be changed heavily before it's finished, feedback to <a href=http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org>the WHATWG list</a>
-is encouraged, particularly from implementers and particularly from authors who
-have experience using this feature.
+defining <code><a href=#execcommand()>execCommand()</a></code> and related functions. It largely replaces
+the <a href=http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#editing-apis>Editing
+APIs</a> section of the <a href=http://www.whatwg.org/html>HTML</a>
+specification. Feedback should preferably be sent to <a href=http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org>the WHATWG
+list</a>, or alternatively to <a href=http://lists.w3.org/Archives/Public/public-html/>public-html</a> for those
+who prefer the W3C. In either case, include the string "[editing]" somewhere
+in the subject, and CC <a href=mailto:ayg@aryeh.name>ayg@aryeh.name</a> (or any
+of my other e-mail addresses) to make sure I see it.
<h2 class=no-num id=table-of-contents>Table of contents</h2>
@@ -154,7 +155,10 @@
<p>Where the reasoning behind the specification is of interest, such as when
major preexisting rendering engines are known not to match it, the reasoning is
-included in HTML comments so as not to distract the reader.
+included in HTML comments so as not to distract the reader. If you have
+questions about why the specification says something, check for comments in the
+source first. They're sometimes longer than the specification text itself, and
+commonly record what the major browsers do and other essential information.
<p>The principles I've used for writing this specification so far are:
@@ -188,9 +192,9 @@
was actually modified.
<li>But if we are already changing around something's style, convert existing
- styles to the preferred format. For instance, we use <code class=external data-anolis-spec=html title="the b element"><a href=http://www.whatwg.org/html/#the-b-element>b</a></code> for bold, and
- convert <code class=external data-anolis-spec=html title="the strong element"><a href=http://www.whatwg.org/html/#the-strong-element>strong</a></code> and <<code class=external data-anolis-spec=html title="the span element"><a href=http://www.whatwg.org/html/#the-span-element>span</a></code> <code class=external data-anolis-spec=html title="the style attribute"><a href=http://www.whatwg.org/html/#the-style-attribute>style</a></code>="font-weight: bold"> if we
- happen to be modifying that node anyway.
+ styles to the preferred format. For instance, we use <code title=""><b></code> for bold (if the CSS styling flag is false), and convert
+ <code title=""><strong></code> and <code title=""><span style="font-weight:
+ bold"></code> if we happen to be modifying that node anyway.
<li>Try not to make the document less conforming than it originally was. If
we happen to make it more conforming, good, although we don't have to go out
@@ -198,8 +202,7 @@
conforming, generally because there's some clear use-case that requires it or
because it matches existing browsers behavior. (For instance, see the
styleWithCSS = false mode, and the fact that insertImage doesn't add an
- alt attribute, and how list-related commands can make list elements nested in
- one another directly without intervening <li>, etc.)
+ alt attribute, etc.)
<li>Keep the markup as concise as possible. (I've received feedback that
this is very important to authors.) Ideally, the markup should look as
@@ -219,23 +222,76 @@
<h2 id=issues><span class=secno>2 </span>Issues</h2>
-<p>This specification is very preliminary and is undergoing constant change.
-It should not be used for anything other than review, comment, and experimental
-implementations that you don't intend to inflict on unwitting users without
-their informed consent. It should definitely be used for review and comment,
-especially in the form of specific test-cases where the current spec produces
-bad results. As noted, feedback should be sent to <a href=http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org>the WHATWG
-list</a>.
+<p>This specification is mostly feature-complete. It's more or less fully
+implemented in JavaScript, and has been tested on a fairly significant amount
+of artificial input. It has not been tested on real-world sites that use
+execCommand(), and has not been thoroughly reviewed by anyone other than me.
+I'm close to calling it stable and ready for implementer feedback.
+
+<p>Significant known issues that I need feedback on, or otherwise am not
+planning to fix just yet:
<ul>
<li>Need to make CSS terminology more precise, about setting/unsetting CSS
properties. The intent is to modify the style attribute, CSSOM-style.
Likewise, CSS value comparisons need to be done after serializing both
- values, so "bold" == "700" and "red" == "#f00" and so on.
-
- <li>Also not sure about computed style. There are differences between
- "computed" and "used" and things like that, what do we actually want here?
-
+ values, so "bold" == "700" and "red" == "#f00" and so on. Suggestions
+ appreciated on how I should spec this.
+
+ <li>I use <a href=http://dev.w3.org/csswg/cssom/#resolved-value>resolved value</a> instead of computed or used or anything like that, just
+ because that's what my test implementation uses (via getComputedStyle). This
+ is not necessarily the best actual choice: if it should be something else,
+ please tell me.
+
+ <li><p>I haven't paid much attention to performance. The algorithms here
+ aren't performance-critical in most cases, but I might have accidentally
+ included some algorithms that are too slow anyway on large pages. Generally
+ I haven't worried about throwing nodes away and recreating them multiple
+ times or things like that, as long as it produces the correct result.
+
+ <p>If it would be useful to implementers for me to spend time and spec
+ complexity on avoiding some of the masses of useless operations that are
+ currently required, please say so. All intermediate DOM states are
+ black-box detectable via mutation events or whatever their replacement will
+ be, so implementers theoretically can't optimize most of this stuff too much
+ themselves, but in practice I doubt anyone will rely on the intermediate DOM
+ states much.
+
+ <li><code class=external data-anolis-spec=html title="the br element"><a href=http://www.whatwg.org/html/#the-br-element>br</a></code>s are a nightmare. I have tons of hacks all over the place which
+ are totally wrong, mostly to account for the fact that sometimes <code class=external data-anolis-spec=html title="the br element"><a href=http://www.whatwg.org/html/#the-br-element>br</a></code>s do
+ nothing and we need to treat that case magically. I don't know what a good
+ way is to fix this. At this point I've mostly gotten the evil concentrated
+ in the definitions "collapsed line break", "extraneous line break", and
+ "collapsed block prop", but there's lots of other special-case handling
+ scattered about. Feedback appreciated. How do browsers handle this?
+
+ <li>Where methods take a value, I've decided they should throw SYNTAX_ERR
+ instead of doing nothing if the value makes no sense. As a rule, this
+ doesn't match browsers. I think it's more useful to authors, however,
+ especially since in many cases, the command's effect isn't currently
+ interoperable anyway. I'll switch them back to doing nothing if implementers
+ think this is a problem.
+
+ <li>The CSS styling flag is an issue. Currently authors are forced to turn
+ it entirely on or entirely off. If it's on, it produces stuff like <code title=""><span style=font-weight:bold></code> instead of <code title=""><b></code>, while if it's off, it produces stuff like <code title=""><font color=red></code> instead of <code title=""><span
+ style=color:red></code>. The issue is that authors might want a mix, like
+ making the markup as concise as possible while still conforming, and they
+ can't do that. Changing the flag on a per-command basis doesn't help because
+ of things like the "restore the values" algorithm, which might create several
+ different types of style at once and has to use the same styling flag for all
+ of them. This was discussed back in March in <a href=http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-March/030714.html>this
+ thread</a>, along with a number of other things, but at that time I hadn't
+ written commands that change multiple styles at once, so it seemed feasible
+ to ask authors to switch styleWithCSS on or off on a per-command basis.
+
+ <li>I haven't defined the "undo" or "redo" commands yet. They look very
+ complicated to define precisely, and other people are working on them right
+ now.
+</ul>
+
+<p>Things I need to fix before announcing that the draft is basically complete:
+
+<ul>
<li>Some more thought needs to go into what happens to the selection when you
mutate the DOM. In some cases the results are pretty arbitrary. It might
make sense to do some kind of normalization.
@@ -247,12 +303,6 @@
editable, since that immediately means it has to descend from an element or
Document (and cannot be parentless itself).
- <li>I haven't paid much attention to performance. The algorithms here aren't
- performance-critical in most cases, but I might have accidentally included
- some algorithms that are too slow anyway on large pages. Generally I haven't
- worried about throwing nodes away and recreating them multiple times or
- things like that, as long as it produces the correct result.
-
<li>I need to pay more attention to invisible nodes. These will have no
visual effect, but they'll make many algorithms behave differently:
decomposing a range, block-extending, etc. Also, need to improve the
@@ -270,33 +320,12 @@
Previously the spec assumed <code class=external data-anolis-spec=html title="the br element"><a href=http://www.whatwg.org/html/#the-br-element>br</a></code> should separate lines, which is like Gecko
and sometimes WebKit, but I'm moving it to use <code class=external data-anolis-spec=html title="the p element"><a href=http://www.whatwg.org/html/#the-p-element>p</a></code> instead.
- <li><code class=external data-anolis-spec=html title="the br element"><a href=http://www.whatwg.org/html/#the-br-element>br</a></code>s are a nightmare. I have tons of hacks all over the place which
- are totally wrong, mostly to account for the fact that sometimes <code class=external data-anolis-spec=html title="the br element"><a href=http://www.whatwg.org/html/#the-br-element>br</a></code>s do
- nothing and we need to treat that case magically. I don't know what a good
- way is to fix this.
-
<li>Have to make sure that in all the places where we set a selection, it's
valid.
-
- <li>Where methods take a value, I've decided they should throw SYNTAX_ERR
- instead of doing nothing if the value makes no sense. As a rule, this
- doesn't match browsers. I think it's more useful to authors, however,
- especially since in many cases, the command's effect isn't currently
- interoperable anyway. I'll switch them back to doing nothing if implementers
- think this is a problem.
-
- <li>The CSS styling flag is an issue. Currently authors are forced to turn
- it entirely on or entirely off. If it's on, it produces stuff like <code title=""><span style=font-weight:bold></code> instead of <code title=""><b></code>, while if it's off, it produces stuff like <code title=""><font color=red></code> instead of <code title=""><span
- style=color:red></code>. The issue is that authors might want a mix, like
- making the markup as concise as possible while still conforming, and they
- can't do that. Changing the flag on a per-command basis doesn't help because
- of things like the "restore the values" algorithm, which might create several
- different types of style at once and has to use the same styling flag for all
- of them.
</ul>
<p class=XXX>A variety of other issues are also noted in the text, formatted
-like this.
+like this. Feedback would be appreciated on all of them.
<p>Things that would be useful to address for the future but aren't important
to fix right now are in comments prefixed with "TODO".
@@ -669,7 +698,7 @@
although it won't auto-close it. -->
<p>A <dfn id=block-node>block node</dfn> is either an <code class=external data-anolis-spec=domcore><a href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#element>Element</a></code> whose "display" property
-does not have <a href=http://www.w3.org/TR/CSS21/cascade.html#computed-value>computed value</a> "inline" or "inline-block" or "inline-table" or
+does not have <a href=http://dev.w3.org/csswg/cssom/#resolved-value>resolved value</a> "inline" or "inline-block" or "inline-table" or
"none", or a <code class=external data-anolis-spec=domcore><a href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#document>Document</a></code>, or a <code class=external data-anolis-spec=domcore><a href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#documentfragment>DocumentFragment</a></code>.
<p>An <dfn id=inline-node>inline node</dfn> is a <a class=external data-anolis-spec=domcore href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-node title=concept-node>node</a> that is not a <a href=#block-node>block
@@ -1327,14 +1356,14 @@
<li>If <var title="">command</var> is "backColor" or "hiliteColor":
<ol>
- <li>While the <a href=http://www.w3.org/TR/CSS21/cascade.html#computed-value>computed value</a> of "background-color" on <var title="">node</var> is
+ <li>While the <a href=http://dev.w3.org/csswg/cssom/#resolved-value>resolved value</a> of "background-color" on <var title="">node</var> is
any fully transparent value, and <var title="">node</var>'s <a class=external data-anolis-spec=domcore href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-tree-parent title=concept-tree-parent>parent</a> is an
<code class=external data-anolis-spec=domcore><a href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#element>Element</a></code>, set <var title="">node</var> to its <a class=external data-anolis-spec=domcore href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-tree-parent title=concept-tree-parent>parent</a>.
- <li>If the <a href=http://www.w3.org/TR/CSS21/cascade.html#computed-value>computed value</a> of "background-color" on <var title="">node</var> is
+ <li>If the <a href=http://dev.w3.org/csswg/cssom/#resolved-value>resolved value</a> of "background-color" on <var title="">node</var> is
a fully transparent value, return "rgb(255, 255, 255)".
- <li>Otherwise, return the <a href=http://www.w3.org/TR/CSS21/cascade.html#computed-value>computed value</a> of "background-color" for
+ <li>Otherwise, return the <a href=http://dev.w3.org/csswg/cssom/#resolved-value>resolved value</a> of "background-color" for
<var title="">node</var>.
</ol>
@@ -1352,14 +1381,14 @@
in fact behaves like that even for commands like bold. The spec follows
Chrome 14 dev, mainly because WebKit itself will produce spans with
vertical-align sub or super, and we want to handle them correctly. -->
- <li>If <var title="">node</var>'s "vertical-align" property computes to "sub", set
- <var title="">affected by subscript</var> to true.
-
- <li>Otherwise, if <var title="">node</var>'s "vertical-align" property computes to
- "super", set <var title="">affected by superscript</var> to true.
-
- <li>Otherwise, if <var title="">node</var>'s "vertical-align" property computes to
- some value other than "baseline", return the string "other".
+ <li>If <var title="">node</var>'s "vertical-align" property has <a href=http://dev.w3.org/csswg/cssom/#resolved-value>resolved value</a> "sub",
+ set <var title="">affected by subscript</var> to true.
+
+ <li>Otherwise, if <var title="">node</var>'s "vertical-align" property has
+ <a href=http://dev.w3.org/csswg/cssom/#resolved-value>resolved value</a> "super", set <var title="">affected by superscript</var> to true.
+
+ <li>Otherwise, if <var title="">node</var>'s "vertical-align" property has
+ <a href=http://dev.w3.org/csswg/cssom/#resolved-value>resolved value</a> other than "baseline", return the string "other".
<li>Set <var title="">node</var> to its <a class=external data-anolis-spec=domcore href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-tree-parent title=concept-tree-parent>parent</a>.
</ol>
@@ -1375,16 +1404,14 @@
</ol>
<li>If <var title="">command</var> is "strikethrough", and the "text-decoration"
- property of <var title="">node</var> or any of its <a class=external data-anolis-spec=domcore href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-tree-ancestor title=concept-tree-ancestor>ancestors</a> computes to
- a value containing "line-through", return "line-through". Otherwise, return
- null.
+ property of <var title="">node</var> or any of its <a class=external data-anolis-spec=domcore href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-tree-ancestor title=concept-tree-ancestor>ancestors</a> has <a href=http://dev.w3.org/csswg/cssom/#resolved-value>resolved value</a>
+ containing "line-through", return "line-through". Otherwise, return null.
<li>If <var title="">command</var> is "underline", and the "text-decoration"
- property of <var title="">node</var> or any of its <a class=external data-anolis-spec=domcore href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-tree-ancestor title=concept-tree-ancestor>ancestors</a> computes to
- a value containing "underline", return "underline". Otherwise, return
- null.
-
- <li>Return the <a href=http://www.w3.org/TR/CSS21/cascade.html#computed-value>computed value</a> for <var title="">node</var> of the <a href=#relevant-css-property>relevant CSS
+ property of <var title="">node</var> or any of its <a class=external data-anolis-spec=domcore href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-tree-ancestor title=concept-tree-ancestor>ancestors</a> has <a href=http://dev.w3.org/csswg/cssom/#resolved-value>resolved value</a>
+ containing "underline", return "underline". Otherwise, return null.
+
+ <li>Return the <a href=http://dev.w3.org/csswg/cssom/#resolved-value>resolved value</a> for <var title="">node</var> of the <a href=#relevant-css-property>relevant CSS
property</a> for <var title="">command</var>.
</ol>
@@ -1394,7 +1421,8 @@
<ol>
<li>If <var title="">command</var> is "backColor" or "hiliteColor" and the
- <code class=external data-anolis-spec=domcore><a href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#element>Element</a></code>'s display property does not compute to "inline", return null.
+ <code class=external data-anolis-spec=domcore><a href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#element>Element</a></code>'s display property does not have <a href=http://dev.w3.org/csswg/cssom/#resolved-value>resolved value</a> "inline", return
+ null.
<li>If <var title="">command</var> is "createLink" or "unlink":
@@ -2455,7 +2483,7 @@
Opera 11: Returns the literal value of font-family, except if it's inherited
from default values, when it returns the empty string.
-I'm just going to punt on this and say it should be the computed value of
+I'm just going to punt on this and say it should be the resolved value of
font-family. I'll leave CSSOM to decide what that means if there are no
applicable style rules. -->
@@ -2611,11 +2639,11 @@
<li>While <var title="">returned size</var> is less than 7:
<ol>
- <li>Let <var title="">lower bound</var> be the <a href=http://www.w3.org/TR/CSS21/cascade.html#computed-value>computed value</a> of "font-size" in pixels
+ <li>Let <var title="">lower bound</var> be the <a href=http://dev.w3.org/csswg/cssom/#resolved-value>resolved value</a> of "font-size" in pixels
of a <code class=external data-anolis-spec=html title=font><a href=http://www.whatwg.org/html/#font>font</a></code> element whose <code class=external data-anolis-spec=html title=dom-font-size><a href=http://www.whatwg.org/html/#dom-font-size>size</a></code> attribute is set to <var title="">returned
size</var>.
- <li>Let <var title="">upper bound</var> be the <a href=http://www.w3.org/TR/CSS21/cascade.html#computed-value>computed value</a> of "font-size" in pixels
+ <li>Let <var title="">upper bound</var> be the <a href=http://dev.w3.org/csswg/cssom/#resolved-value>resolved value</a> of "font-size" in pixels
of a <code class=external data-anolis-spec=html title=font><a href=http://www.whatwg.org/html/#font>font</a></code> element whose <code class=external data-anolis-spec=html title=dom-font-size><a href=http://www.whatwg.org/html/#dom-font-size>size</a></code> attribute is set to one plus
<var title="">returned size</var>.
@@ -3351,7 +3379,7 @@
-->
<ol>
<li>While <var title="">node</var> is neither null nor an <code class=external data-anolis-spec=domcore><a href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#element>Element</a></code>, or it is an
- <code class=external data-anolis-spec=domcore><a href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#element>Element</a></code> but its "display" property has <a href=http://www.w3.org/TR/CSS21/cascade.html#computed-value>computed value</a> "inline" or "none",
+ <code class=external data-anolis-spec=domcore><a href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#element>Element</a></code> but its "display" property has <a href=http://dev.w3.org/csswg/cssom/#resolved-value>resolved value</a> "inline" or "none",
set <var title="">node</var> to its <a class=external data-anolis-spec=domcore href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-tree-parent title=concept-tree-parent>parent</a>.
<li>If <var title="">node</var> is not an <code class=external data-anolis-spec=domcore><a href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#element>Element</a></code>, return "left".
@@ -3361,15 +3389,15 @@
anyway. (It will only happen if, e.g., everything up to and including the
html and body elements have display: inline or none.) -->
- <li>If <var title="">node</var>'s "text-align" property has <a href=http://www.w3.org/TR/CSS21/cascade.html#computed-value>computed value</a> "start",
+ <li>If <var title="">node</var>'s "text-align" property has <a href=http://dev.w3.org/csswg/cssom/#resolved-value>resolved value</a> "start",
return "left" if the <a class=external data-anolis-spec=html href=http://www.whatwg.org/html/#the-directionality title="the directionality">directionality</a> of <var title="">node</var> is "ltr", "right"
if it is "rtl".
- <li>If <var title="">node</var>'s "text-align" property has <a href=http://www.w3.org/TR/CSS21/cascade.html#computed-value>computed value</a> "end", return
+ <li>If <var title="">node</var>'s "text-align" property has <a href=http://dev.w3.org/csswg/cssom/#resolved-value>resolved value</a> "end", return
"right" if the <a class=external data-anolis-spec=html href=http://www.whatwg.org/html/#the-directionality title="the directionality">directionality</a> of <var title="">node</var> is "ltr", "left" if it
is "rtl".
- <li>If <var title="">node</var>'s "text-align" property has <a href=http://www.w3.org/TR/CSS21/cascade.html#computed-value>computed value</a> "center",
+ <li>If <var title="">node</var>'s "text-align" property has <a href=http://dev.w3.org/csswg/cssom/#resolved-value>resolved value</a> "center",
"justify", "left", or "right", return that value.
<li>Return "left".
@@ -4127,7 +4155,7 @@
-->
<li>Otherwise, if <var title="">start node</var> is a <code class=external data-anolis-spec=domcore><a href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#text>Text</a></code> node and its
- <a class=external data-anolis-spec=domcore href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-tree-parent title=concept-tree-parent>parent</a>'s <a href=http://www.w3.org/TR/CSS21/cascade.html#computed-value>computed value</a> for "white-space" is neither "pre" nor "pre-wrap"
+ <a class=external data-anolis-spec=domcore href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-tree-parent title=concept-tree-parent>parent</a>'s <a href=http://dev.w3.org/csswg/cssom/#resolved-value>resolved value</a> for "white-space" is neither "pre" nor "pre-wrap"
and <var title="">start offset</var> is not zero and the (<var title="">start offset</var>
− 1)st <a href=http://es5.github.com/#x8.4>element</a> of <var title="">start node</var>'s <code class=external data-anolis-spec=domcore title=dom-CharacterData-data><a href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-characterdata-data>data</a></code> is a space
(0x0020) or non-breaking space (0x00A0), subtract one from <var title="">start
@@ -4161,7 +4189,7 @@
-->
<li>Otherwise, if <var title="">end node</var> is a <code class=external data-anolis-spec=domcore><a href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#text>Text</a></code> node and its
- <a class=external data-anolis-spec=domcore href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-tree-parent title=concept-tree-parent>parent</a>'s <a href=http://www.w3.org/TR/CSS21/cascade.html#computed-value>computed value</a> for "white-space" is neither "pre" nor "pre-wrap"
+ <a class=external data-anolis-spec=domcore href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-tree-parent title=concept-tree-parent>parent</a>'s <a href=http://dev.w3.org/csswg/cssom/#resolved-value>resolved value</a> for "white-space" is neither "pre" nor "pre-wrap"
and <var title="">end offset</var> is not <var title="">end node</var>'s <a class=external data-anolis-spec=domrange href=http://html5.org/specs/dom-range.html#concept-node-length title=concept-node-length>length</a> and the
<var title="">end offset</var>th <a href=http://es5.github.com/#x8.4>element</a> of <var title="">end node</var>'s <code class=external data-anolis-spec=domcore title=dom-CharacterData-data><a href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-characterdata-data>data</a></code> is a
space (0x0020) or non-breaking space (0x00A0):
@@ -6755,9 +6783,9 @@
then set <var title="">offset</var> to zero.
<li>If <var title="">value</var> is a space (U+0020), and either <var title="">node</var> is an
- <code class=external data-anolis-spec=domcore><a href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#element>Element</a></code> whose <a href=http://www.w3.org/TR/CSS21/cascade.html#computed-value>computed value</a> for "white-space" is neither "pre" nor
+ <code class=external data-anolis-spec=domcore><a href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#element>Element</a></code> whose <a href=http://dev.w3.org/csswg/cssom/#resolved-value>resolved value</a> for "white-space" is neither "pre" nor
"pre-wrap" or <var title="">node</var> is not an <code class=external data-anolis-spec=domcore><a href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#element>Element</a></code> but its <a class=external data-anolis-spec=domcore href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-tree-parent title=concept-tree-parent>parent</a> is an
- <code class=external data-anolis-spec=domcore><a href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#element>Element</a></code> whose <a href=http://www.w3.org/TR/CSS21/cascade.html#computed-value>computed value</a> for "white-space" is neither "pre" nor
+ <code class=external data-anolis-spec=domcore><a href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#element>Element</a></code> whose <a href=http://dev.w3.org/csswg/cssom/#resolved-value>resolved value</a> for "white-space" is neither "pre" nor
"pre-wrap", set <var title="">value</var> to a non-breaking space (U+00A0).
<!-- This may change to a space when we canonicalize. -->
--- a/implementation.js Wed Jul 13 11:39:49 2011 -0600
+++ b/implementation.js Wed Jul 13 12:10:21 2011 -0600
@@ -722,7 +722,7 @@
}
// "A block node is either an Element whose "display" property does not have
-// computed value "inline" or "inline-block" or "inline-table" or "none", or a
+// resolved value "inline" or "inline-block" or "inline-table" or "none", or a
// Document, or a DocumentFragment."
function isBlockNode(node) {
return node
@@ -1764,7 +1764,7 @@
// "If command is "backColor" or "hiliteColor":"
if (command == "backcolor"
|| command == "hilitecolor") {
- // "While the computed value of "background-color" on node is any
+ // "While the resolved value of "background-color" on node is any
// fully transparent value, and node's parent is an Element, set
// node to its parent."
//
@@ -1777,7 +1777,7 @@
node = node.parentNode;
}
- // "If the computed value of "background-color" on node is a fully
+ // "If the resolved value of "background-color" on node is a fully
// transparent value, return "rgb(255, 255, 255)"."
if (getComputedStyle(node).backgroundColor == "rgba(0, 0, 0, 0)"
|| getComputedStyle(node).backgroundColor === ""
@@ -1785,7 +1785,7 @@
return "rgb(255, 255, 255)";
}
- // "Otherwise, return the computed value of "background-color" for
+ // "Otherwise, return the resolved value of "background-color" for
// node."
return getComputedStyle(node).backgroundColor;
}
@@ -1801,15 +1801,15 @@
while (isInlineNode(node)) {
var verticalAlign = getComputedStyle(node).verticalAlign;
- // "If node's "vertical-align" property computes to "sub", set
- // affected by subscript to true."
+ // "If node's "vertical-align" property has resolved value "sub",
+ // set affected by subscript to true."
if (verticalAlign == "sub") {
affectedBySubscript = true;
- // "Otherwise, if node's "vertical-align" property computes to
- // "super", set affected by superscript to true."
+ // "Otherwise, if node's "vertical-align" property has resolved
+ // value "super", set affected by superscript to true."
} else if (verticalAlign == "super") {
affectedBySuperscript = true;
- // "Otherwise, if node's "vertical-align" property computes to some
+ // "Otherwise, if node's "vertical-align" property has resolved
// value other than "baseline", return the string "other"."
} else if (verticalAlign != "baseline") {
return "other";
@@ -1840,7 +1840,7 @@
}
// "If command is "strikethrough", and the "text-decoration" property of
- // node or any of its ancestors computes to a value containing
+ // node or any of its ancestors has resolved value containing
// "line-through", return "line-through". Otherwise, return null."
if (command == "strikethrough") {
do {
@@ -1853,7 +1853,7 @@
}
// "If command is "underline", and the "text-decoration" property of node
- // or any of its ancestors computes to a value containing "underline",
+ // or any of its ancestors has resolved value containing "underline",
// return "underline". Otherwise, return null."
if (command == "underline") {
do {
@@ -1865,14 +1865,14 @@
return null;
}
- // "Return the computed value for node of the relevant CSS property for
+ // "Return the resolved value for node of the relevant CSS property for
// command."
return getComputedStyle(node)[commands[command].relevantCssProperty];
}
function getSpecifiedCommandValue(element, command) {
// "If command is "backColor" or "hiliteColor" and element's display
- // property does not compute to "inline", return null."
+ // property does not have resolved value "inline", return null."
if ((command == "backcolor" || command == "hilitecolor")
&& getComputedStyle(element).display != "inline") {
return null;
@@ -2798,7 +2798,7 @@
// "The effective command value of the active range's start node."
//
// Opera uses a different format, so let's be nice and support that for
- // the time being (since all this computed value stuff is underdefined
+ // the time being (since all this resolved value stuff is underdefined
// anyway).
var value = getEffectiveCommandValue(getActiveRange().startContainer, "backcolor");
if (/^#[0-9a-f]{6}$/.test(value)) {
@@ -3010,14 +3010,14 @@
// "While returned size is less than 7:"
while (returnedSize < 7) {
- // "Let lower bound be the computed value of "font-size" in pixels
+ // "Let lower bound be the resolved value of "font-size" in pixels
// of a font element whose size attribute is set to returned size."
var font = document.createElement("font");
font.size = returnedSize;
document.body.appendChild(font);
var lowerBound = parseInt(getComputedStyle(font).fontSize);
- // "Let upper bound be the computed value of "font-size" in pixels
+ // "Let upper bound be the resolved value of "font-size" in pixels
// of a font element whose size attribute is set to one plus
// returned size."
font.size = 1 + returnedSize;
@@ -3084,7 +3084,7 @@
// "The effective command value of the active range's start node."
//
// Opera uses a different format, so let's be nice and support that for
- // the time being (since all this computed value stuff is underdefined
+ // the time being (since all this resolved value stuff is underdefined
// anyway).
var value = getEffectiveCommandValue(getActiveRange().startContainer, "forecolor");
if (/^#[0-9a-f]{6}$/.test(value)) {
@@ -3138,7 +3138,7 @@
// "The effective command value of the active range's start node."
//
// Opera uses a different format, so let's be nice and support that for
- // the time being (since all this computed value stuff is underdefined
+ // the time being (since all this resolved value stuff is underdefined
// anyway).
var value = getEffectiveCommandValue(getActiveRange().startContainer, "hilitecolor");
if (/^#[0-9a-f]{6}$/.test(value)) {
@@ -3732,7 +3732,7 @@
function getAlignmentValue(node) {
// "While node is neither null nor an Element, or it is an Element but its
- // "display" property has computed value "inline" or "none", set node to
+ // "display" property has resolved value "inline" or "none", set node to
// its parent."
while ((node && node.nodeType != Node.ELEMENT_NODE)
|| (node.nodeType == Node.ELEMENT_NODE
@@ -3745,27 +3745,27 @@
return "left";
}
- var computedValue = getComputedStyle(node).textAlign
+ var resolvedValue = getComputedStyle(node).textAlign
// Hack around browser non-standardness
.replace(/^-(moz|webkit)-/, "")
.replace(/^auto$/, "start");
- // "If node's "text-align" property has computed value "start", return
+ // "If node's "text-align" property has resolved value "start", return
// "left" if the directionality of node is "ltr", "right" if it is "rtl"."
- if (computedValue == "start") {
+ if (resolvedValue == "start") {
return getDirectionality(node) == "ltr" ? "left" : "right";
}
- // "If node's "text-align" property has computed value "end", return
+ // "If node's "text-align" property has resolved value "end", return
// "right" if the directionality of node is "ltr", "left" if it is "rtl"."
- if (computedValue == "end") {
+ if (resolvedValue == "end") {
return getDirectionality(node) == "ltr" ? "right" : "left";
}
- // "If node's "text-align" property has computed value "center", "justify",
+ // "If node's "text-align" property has resolved value "center", "justify",
// "left", or "right", return that value."
- if (["center", "justify", "left", "right"].indexOf(computedValue) != -1) {
- return computedValue;
+ if (["center", "justify", "left", "right"].indexOf(resolvedValue) != -1) {
+ return resolvedValue;
}
// "Return "left"."
@@ -4693,7 +4693,7 @@
startOffset = getNodeIndex(startNode);
startNode = startNode.parentNode;
- // "Otherwise, if start node is a Text node and its parent's computed
+ // "Otherwise, if start node is a Text node and its parent's resolved
// value for "white-space" is neither "pre" nor "pre-wrap" and start
// offset is not zero and the (start offset − 1)st element of start
// node's data is a space (0x0020) or non-breaking space (0x00A0),
@@ -4739,7 +4739,7 @@
endOffset = 1 + getNodeIndex(endNode);
endNode = endNode.parentNode;
- // "Otherwise, if end node is a Text node and its parent's computed
+ // "Otherwise, if end node is a Text node and its parent's resolved
// value for "white-space" is neither "pre" nor "pre-wrap" and end
// offset is not end node's length and the end offsetth element of
// end node's data is a space (0x0020) or non-breaking space (0x00A0):"
@@ -6880,8 +6880,8 @@
}
// "If value is a space (U+0020), and either node is an Element whose
- // computed value for "white-space" is neither "pre" nor "pre-wrap" or
- // node is not an Element but its parent is an Element whose computed
+ // resolved value for "white-space" is neither "pre" nor "pre-wrap" or
+ // node is not an Element but its parent is an Element whose resolved
// value for "white-space" is neither "pre" nor "pre-wrap", set value
// to a non-breaking space (U+00A0)."
var refElement = node.nodeType == Node.ELEMENT_NODE ? node : node.parentNode;
--- a/preprocess Wed Jul 13 11:39:49 2011 -0600
+++ b/preprocess Wed Jul 13 12:10:21 2011 -0600
@@ -30,7 +30,6 @@
'collection': '<span data-anolis-spec=domcore title=concept-collection>collection</span>',
'contained': '<span data-anolis-spec=domrange>contained</span>',
'comment': '<code data-anolis-spec=domcore>Comment</code>',
- 'compval': '<a href=http://www.w3.org/TR/CSS21/cascade.html#computed-value>computed value</a>',
'contextobject': '<span data-anolis-spec=domrange>context object</span>',
'descendant': '<span data-anolis-spec=domcore title=concept-tree-descendant>descendant</span>',
'directionality': '<span data-anolis-spec=html title="the directionality">directionality</span>',
@@ -84,6 +83,7 @@
'rangeroot': '<span data-anolis-spec=domrange title=concept-range-root>root</span>',
'rangestart': '<span data-anolis-spec=domrange title=concept-range-start>start</span>',
'removeallranges': '<code data-anolis-spec=domrange title=dom-Selection-removeAllRanges>removeAllRanges()</code>',
+ 'resval': '<a href=http://dev.w3.org/csswg/cssom/#resolved-value>resolved value</a>',
's': '<code data-anolis-spec=html title="the s element">s</code>',
'selection': '<code data-anolis-spec=domrange>Selection</code>',
'sibling': '<span data-anolis-spec=domcore title=concept-tree-sibling>sibling</span>',
--- a/source.html Wed Jul 13 11:39:49 2011 -0600
+++ b/source.html Wed Jul 13 12:10:21 2011 -0600
@@ -43,7 +43,7 @@
<h2 class="no-num no-toc">Work in Progress — Last Update [DATE: 01 Jan 1901]</h2>
<dl>
<dt>Editor
- <dd>Aryeh Gregor <ayg+spec@aryeh.name>
+ <dd>Aryeh Gregor <<a href=mailto:ayg@aryeh.name>ayg@aryeh.name</a>>
<dt>Version history
<dd><a href=http://aryeh.name/gitweb.cgi?p=editcommands>http://aryeh.name/gitweb.cgi?p=editcommands</a>
@@ -54,15 +54,17 @@
<h2 class=no-num>Status of this Document</h2>
<!-- @{ -->
<p>This document is an early draft of a specification for HTML editing APIs,
-defining <code>execCommand()</code> and related functions. It will eventually
-be merged into the main <a href=http://www.whatwg.org/html>HTML</a>
-specification, replacing the <a
+defining <code>execCommand()</code> and related functions. It largely replaces
+the <a
href=http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#editing-apis>Editing
-APIs</a> section. Although this spec is still very incomplete and will likely
-be changed heavily before it's finished, feedback to <a
-href=http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org>the WHATWG list</a>
-is encouraged, particularly from implementers and particularly from authors who
-have experience using this feature.
+APIs</a> section of the <a href=http://www.whatwg.org/html>HTML</a>
+specification. Feedback should preferably be sent to <a
+href=http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org>the WHATWG
+list</a>, or alternatively to <a
+href=http://lists.w3.org/Archives/Public/public-html/>public-html</a> for those
+who prefer the W3C. In either case, include the string "[editing]" somewhere
+in the subject, and CC <a href=mailto:ayg@aryeh.name>ayg@aryeh.name</a> (or any
+of my other e-mail addresses) to make sure I see it.
<!-- @} -->
<h2 class=no-num>Table of contents</h2>
@@ -79,7 +81,10 @@
<p>Where the reasoning behind the specification is of interest, such as when
major preexisting rendering engines are known not to match it, the reasoning is
-included in HTML comments so as not to distract the reader.
+included in HTML comments so as not to distract the reader. If you have
+questions about why the specification says something, check for comments in the
+source first. They're sometimes longer than the specification text itself, and
+commonly record what the major browsers do and other essential information.
<p>The principles I've used for writing this specification so far are:
@@ -113,9 +118,10 @@
was actually modified.
<li>But if we are already changing around something's style, convert existing
- styles to the preferred format. For instance, we use [[b]] for bold, and
- convert [[strong]] and <[[span]] [[style]]="font-weight: bold"> if we
- happen to be modifying that node anyway.
+ styles to the preferred format. For instance, we use <code
+ title><b></code> for bold (if the CSS styling flag is false), and convert
+ <code title><strong></code> and <code title><span style="font-weight:
+ bold"></code> if we happen to be modifying that node anyway.
<li>Try not to make the document less conforming than it originally was. If
we happen to make it more conforming, good, although we don't have to go out
@@ -123,8 +129,7 @@
conforming, generally because there's some clear use-case that requires it or
because it matches existing browsers behavior. (For instance, see the
styleWithCSS = false mode, and the fact that insertImage doesn't add an
- alt attribute, and how list-related commands can make list elements nested in
- one another directly without intervening <li>, etc.)
+ alt attribute, etc.)
<li>Keep the markup as concise as possible. (I've received feedback that
this is very important to authors.) Ideally, the markup should look as
@@ -144,24 +149,80 @@
<h2>Issues</h2>
<!-- @{ -->
-<p>This specification is very preliminary and is undergoing constant change.
-It should not be used for anything other than review, comment, and experimental
-implementations that you don't intend to inflict on unwitting users without
-their informed consent. It should definitely be used for review and comment,
-especially in the form of specific test-cases where the current spec produces
-bad results. As noted, feedback should be sent to <a
-href=http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org>the WHATWG
-list</a>.
+<p>This specification is mostly feature-complete. It's more or less fully
+implemented in JavaScript, and has been tested on a fairly significant amount
+of artificial input. It has not been tested on real-world sites that use
+execCommand(), and has not been thoroughly reviewed by anyone other than me.
+I'm close to calling it stable and ready for implementer feedback.
+
+<p>Significant known issues that I need feedback on, or otherwise am not
+planning to fix just yet:
<ul>
<li>Need to make CSS terminology more precise, about setting/unsetting CSS
properties. The intent is to modify the style attribute, CSSOM-style.
Likewise, CSS value comparisons need to be done after serializing both
- values, so "bold" == "700" and "red" == "#f00" and so on.
-
- <li>Also not sure about computed style. There are differences between
- "computed" and "used" and things like that, what do we actually want here?
-
+ values, so "bold" == "700" and "red" == "#f00" and so on. Suggestions
+ appreciated on how I should spec this.
+
+ <li>I use [[resval]] instead of computed or used or anything like that, just
+ because that's what my test implementation uses (via getComputedStyle). This
+ is not necessarily the best actual choice: if it should be something else,
+ please tell me.
+
+ <li><p>I haven't paid much attention to performance. The algorithms here
+ aren't performance-critical in most cases, but I might have accidentally
+ included some algorithms that are too slow anyway on large pages. Generally
+ I haven't worried about throwing nodes away and recreating them multiple
+ times or things like that, as long as it produces the correct result.
+
+ <p>If it would be useful to implementers for me to spend time and spec
+ complexity on avoiding some of the masses of useless operations that are
+ currently required, please say so. All intermediate DOM states are
+ black-box detectable via mutation events or whatever their replacement will
+ be, so implementers theoretically can't optimize most of this stuff too much
+ themselves, but in practice I doubt anyone will rely on the intermediate DOM
+ states much.
+
+ <li>[[br]]s are a nightmare. I have tons of hacks all over the place which
+ are totally wrong, mostly to account for the fact that sometimes [[br]]s do
+ nothing and we need to treat that case magically. I don't know what a good
+ way is to fix this. At this point I've mostly gotten the evil concentrated
+ in the definitions "collapsed line break", "extraneous line break", and
+ "collapsed block prop", but there's lots of other special-case handling
+ scattered about. Feedback appreciated. How do browsers handle this?
+
+ <li>Where methods take a value, I've decided they should throw SYNTAX_ERR
+ instead of doing nothing if the value makes no sense. As a rule, this
+ doesn't match browsers. I think it's more useful to authors, however,
+ especially since in many cases, the command's effect isn't currently
+ interoperable anyway. I'll switch them back to doing nothing if implementers
+ think this is a problem.
+
+ <li>The CSS styling flag is an issue. Currently authors are forced to turn
+ it entirely on or entirely off. If it's on, it produces stuff like <code
+ title><span style=font-weight:bold></code> instead of <code
+ title><b></code>, while if it's off, it produces stuff like <code
+ title><font color=red></code> instead of <code title><span
+ style=color:red></code>. The issue is that authors might want a mix, like
+ making the markup as concise as possible while still conforming, and they
+ can't do that. Changing the flag on a per-command basis doesn't help because
+ of things like the "restore the values" algorithm, which might create several
+ different types of style at once and has to use the same styling flag for all
+ of them. This was discussed back in March in <a
+ href=http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-March/030714.html>this
+ thread</a>, along with a number of other things, but at that time I hadn't
+ written commands that change multiple styles at once, so it seemed feasible
+ to ask authors to switch styleWithCSS on or off on a per-command basis.
+
+ <li>I haven't defined the "undo" or "redo" commands yet. They look very
+ complicated to define precisely, and other people are working on them right
+ now.
+</ul>
+
+<p>Things I need to fix before announcing that the draft is basically complete:
+
+<ul>
<li>Some more thought needs to go into what happens to the selection when you
mutate the DOM. In some cases the results are pretty arbitrary. It might
make sense to do some kind of normalization.
@@ -173,12 +234,6 @@
editable, since that immediately means it has to descend from an element or
Document (and cannot be parentless itself).
- <li>I haven't paid much attention to performance. The algorithms here aren't
- performance-critical in most cases, but I might have accidentally included
- some algorithms that are too slow anyway on large pages. Generally I haven't
- worried about throwing nodes away and recreating them multiple times or
- things like that, as long as it produces the correct result.
-
<li>I need to pay more attention to invisible nodes. These will have no
visual effect, but they'll make many algorithms behave differently:
decomposing a range, block-extending, etc. Also, need to improve the
@@ -197,36 +252,12 @@
Previously the spec assumed [[br]] should separate lines, which is like Gecko
and sometimes WebKit, but I'm moving it to use [[p]] instead.
- <li>[[br]]s are a nightmare. I have tons of hacks all over the place which
- are totally wrong, mostly to account for the fact that sometimes [[br]]s do
- nothing and we need to treat that case magically. I don't know what a good
- way is to fix this.
-
<li>Have to make sure that in all the places where we set a selection, it's
valid.
-
- <li>Where methods take a value, I've decided they should throw SYNTAX_ERR
- instead of doing nothing if the value makes no sense. As a rule, this
- doesn't match browsers. I think it's more useful to authors, however,
- especially since in many cases, the command's effect isn't currently
- interoperable anyway. I'll switch them back to doing nothing if implementers
- think this is a problem.
-
- <li>The CSS styling flag is an issue. Currently authors are forced to turn
- it entirely on or entirely off. If it's on, it produces stuff like <code
- title><span style=font-weight:bold></code> instead of <code
- title><b></code>, while if it's off, it produces stuff like <code
- title><font color=red></code> instead of <code title><span
- style=color:red></code>. The issue is that authors might want a mix, like
- making the markup as concise as possible while still conforming, and they
- can't do that. Changing the flag on a per-command basis doesn't help because
- of things like the "restore the values" algorithm, which might create several
- different types of style at once and has to use the same styling flag for all
- of them.
</ul>
<p class=XXX>A variety of other issues are also noted in the text, formatted
-like this.
+like this. Feedback would be appreciated on all of them.
<p>Things that would be useful to address for the future but aren't important
to fix right now are in comments prefixed with "TODO".
@@ -616,7 +647,7 @@
although it won't auto-close it. -->
<p>A <dfn>block node</dfn> is either an [[element]] whose "display" property
-does not have [[compval]] "inline" or "inline-block" or "inline-table" or
+does not have [[resval]] "inline" or "inline-block" or "inline-table" or
"none", or a [[document]], or a [[documentfragment]].
<p>An <dfn>inline node</dfn> is a [[node]] that is not a <span>block
@@ -1283,14 +1314,14 @@
<li>If <var>command</var> is "backColor" or "hiliteColor":
<ol>
- <li>While the [[compval]] of "background-color" on <var>node</var> is
+ <li>While the [[resval]] of "background-color" on <var>node</var> is
any fully transparent value, and <var>node</var>'s [[parent]] is an
[[element]], set <var>node</var> to its [[parent]].
- <li>If the [[compval]] of "background-color" on <var>node</var> is
+ <li>If the [[resval]] of "background-color" on <var>node</var> is
a fully transparent value, return "rgb(255, 255, 255)".
- <li>Otherwise, return the [[compval]] of "background-color" for
+ <li>Otherwise, return the [[resval]] of "background-color" for
<var>node</var>.
</ol>
@@ -1308,14 +1339,14 @@
in fact behaves like that even for commands like bold. The spec follows
Chrome 14 dev, mainly because WebKit itself will produce spans with
vertical-align sub or super, and we want to handle them correctly. -->
- <li>If <var>node</var>'s "vertical-align" property computes to "sub", set
- <var>affected by subscript</var> to true.
-
- <li>Otherwise, if <var>node</var>'s "vertical-align" property computes to
- "super", set <var>affected by superscript</var> to true.
-
- <li>Otherwise, if <var>node</var>'s "vertical-align" property computes to
- some value other than "baseline", return the string "other".
+ <li>If <var>node</var>'s "vertical-align" property has [[resval]] "sub",
+ set <var>affected by subscript</var> to true.
+
+ <li>Otherwise, if <var>node</var>'s "vertical-align" property has
+ [[resval]] "super", set <var>affected by superscript</var> to true.
+
+ <li>Otherwise, if <var>node</var>'s "vertical-align" property has
+ [[resval]] other than "baseline", return the string "other".
<li>Set <var>node</var> to its [[parent]].
</ol>
@@ -1331,16 +1362,14 @@
</ol>
<li>If <var>command</var> is "strikethrough", and the "text-decoration"
- property of <var>node</var> or any of its [[ancestors]] computes to
- a value containing "line-through", return "line-through". Otherwise, return
- null.
+ property of <var>node</var> or any of its [[ancestors]] has [[resval]]
+ containing "line-through", return "line-through". Otherwise, return null.
<li>If <var>command</var> is "underline", and the "text-decoration"
- property of <var>node</var> or any of its [[ancestors]] computes to
- a value containing "underline", return "underline". Otherwise, return
- null.
-
- <li>Return the [[compval]] for <var>node</var> of the <span>relevant CSS
+ property of <var>node</var> or any of its [[ancestors]] has [[resval]]
+ containing "underline", return "underline". Otherwise, return null.
+
+ <li>Return the [[resval]] for <var>node</var> of the <span>relevant CSS
property</span> for <var>command</var>.
</ol>
@@ -1350,7 +1379,8 @@
<ol>
<li>If <var>command</var> is "backColor" or "hiliteColor" and the
- [[element]]'s display property does not compute to "inline", return null.
+ [[element]]'s display property does not have [[resval]] "inline", return
+ null.
<li>If <var>command</var> is "createLink" or "unlink":
@@ -2430,7 +2460,7 @@
Opera 11: Returns the literal value of font-family, except if it's inherited
from default values, when it returns the empty string.
-I'm just going to punt on this and say it should be the computed value of
+I'm just going to punt on this and say it should be the resolved value of
font-family. I'll leave CSSOM to decide what that means if there are no
applicable style rules. -->
@@ -2586,11 +2616,11 @@
<li>While <var>returned size</var> is less than 7:
<ol>
- <li>Let <var>lower bound</var> be the [[compval]] of "font-size" in pixels
+ <li>Let <var>lower bound</var> be the [[resval]] of "font-size" in pixels
of a [[font]] element whose [[fontsize]] attribute is set to <var>returned
size</var>.
- <li>Let <var>upper bound</var> be the [[compval]] of "font-size" in pixels
+ <li>Let <var>upper bound</var> be the [[resval]] of "font-size" in pixels
of a [[font]] element whose [[fontsize]] attribute is set to one plus
<var>returned size</var>.
@@ -3328,7 +3358,7 @@
-->
<ol>
<li>While <var>node</var> is neither null nor an [[element]], or it is an
- [[element]] but its "display" property has [[compval]] "inline" or "none",
+ [[element]] but its "display" property has [[resval]] "inline" or "none",
set <var>node</var> to its [[parent]].
<li>If <var>node</var> is not an [[element]], return "left".
@@ -3338,15 +3368,15 @@
anyway. (It will only happen if, e.g., everything up to and including the
html and body elements have display: inline or none.) -->
- <li>If <var>node</var>'s "text-align" property has [[compval]] "start",
+ <li>If <var>node</var>'s "text-align" property has [[resval]] "start",
return "left" if the [[directionality]] of <var>node</var> is "ltr", "right"
if it is "rtl".
- <li>If <var>node</var>'s "text-align" property has [[compval]] "end", return
+ <li>If <var>node</var>'s "text-align" property has [[resval]] "end", return
"right" if the [[directionality]] of <var>node</var> is "ltr", "left" if it
is "rtl".
- <li>If <var>node</var>'s "text-align" property has [[compval]] "center",
+ <li>If <var>node</var>'s "text-align" property has [[resval]] "center",
"justify", "left", or "right", return that value.
<li>Return "left".
@@ -4106,7 +4136,7 @@
-->
<li>Otherwise, if <var>start node</var> is a [[text]] node and its
- [[parent]]'s [[compval]] for "white-space" is neither "pre" nor "pre-wrap"
+ [[parent]]'s [[resval]] for "white-space" is neither "pre" nor "pre-wrap"
and <var>start offset</var> is not zero and the (<var>start offset</var>
− 1)st [[strel]] of <var>start node</var>'s [[cddata]] is a space
(0x0020) or non-breaking space (0x00A0), subtract one from <var>start
@@ -4140,7 +4170,7 @@
-->
<li>Otherwise, if <var>end node</var> is a [[text]] node and its
- [[parent]]'s [[compval]] for "white-space" is neither "pre" nor "pre-wrap"
+ [[parent]]'s [[resval]] for "white-space" is neither "pre" nor "pre-wrap"
and <var>end offset</var> is not <var>end node</var>'s [[length]] and the
<var>end offset</var>th [[strel]] of <var>end node</var>'s [[cddata]] is a
space (0x0020) or non-breaking space (0x00A0):
@@ -6748,9 +6778,9 @@
then set <var>offset</var> to zero.
<li>If <var>value</var> is a space (U+0020), and either <var>node</var> is an
- [[element]] whose [[compval]] for "white-space" is neither "pre" nor
+ [[element]] whose [[resval]] for "white-space" is neither "pre" nor
"pre-wrap" or <var>node</var> is not an [[element]] but its [[parent]] is an
- [[element]] whose [[compval]] for "white-space" is neither "pre" nor
+ [[element]] whose [[resval]] for "white-space" is neither "pre" nor
"pre-wrap", set <var>value</var> to a non-breaking space (U+00A0).
<!-- This may change to a space when we canonicalize. -->