--- a/editcommands.html Tue Jul 05 11:09:10 2011 -0600
+++ b/editcommands.html Tue Jul 05 11:15:28 2011 -0600
@@ -38,7 +38,7 @@
<body class=draft>
<div class=head id=head>
<h1>HTML Editing Commands</h1>
-<h2 class="no-num no-toc" id=work-in-progress-—-last-update-29-june-2011>Work in Progress — Last Update 29 June 2011</h2>
+<h2 class="no-num no-toc" id=work-in-progress-—-last-update-5-july-2011>Work in Progress — Last Update 5 July 2011</h2>
<dl>
<dt>Editor
<dd>Aryeh Gregor <ayg+spec@aryeh.name>
@@ -1611,6 +1611,8 @@
<!-- 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. -->
+ <p class=XXX>Replace the following steps with "set the tag name".
+
<li>Let <var title="">new element</var> be a new <a href=#html-element>HTML element</a> with
<a class=external data-anolis-spec=domcore href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-element-local-name title=concept-element-local-name>local name</a> "span", with the same attributes and <code class=external data-anolis-spec=domcore title=dom-Node-ownerDocument><a href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-node-ownerdocument>ownerDocument</a></code> as
<var title="">element</var>.
@@ -1697,11 +1699,35 @@
<li>If <var title="">propagated value</var> is null and is not equal to <var title="">new
value</var>, abort this algorithm.
- <!-- 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
+ <!--
+ 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". -->
+ 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).
+ -->
<li>If the <a href=#effective-value>effective value</a> of <var title="">command</var> is not
<var title="">new value</var> on the <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> of the last member of <var title="">ancestor
list</var>, and <var title="">new value</var> is not null, abort this algorithm.
@@ -2085,6 +2111,10 @@
as desired.
</div>
+<p class=XXX>Consider porting this algorithm to operate on runs of consecutive
+siblings instead of individual nodes. We might be able to make some parts
+smarter, and also might be able to make it more efficient.
+
<ol>
<li>Let <var title="">command</var> be the current <a href=#command>command</a>.
@@ -2857,6 +2887,9 @@
<p class=XXX>Has all the same problems as <a href=#the-underline-command>the <code title="">underline</code> command</a>.
+<p class=XXX>Should we treat ins/del the same as u/s? Currently they're
+unremovable.
+
<p><a href=#indeterminate>Indeterminate</a>: True if among <a href=#editable>editable</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>
nodes that are <a href=#effectively-contained>effectively contained</a> in the <a href=#active-range>active
range</a>, there is at least one with <a href=#effective-value>effective value</a>
@@ -3003,6 +3036,9 @@
may be.
</div>
+<p class=XXX>Should we treat ins/del the same as u/s? Currently they're
+unremovable.
+
<p><a href=#indeterminate>Indeterminate</a>: True if among <a href=#editable>editable</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>
nodes that are <a href=#effectively-contained>effectively contained</a> in the <a href=#active-range>active
range</a>, there is at least one with <a href=#effective-value>effective value</a>
--- a/source.html Tue Jul 05 11:09:10 2011 -0600
+++ b/source.html Tue Jul 05 11:15:28 2011 -0600
@@ -1571,6 +1571,8 @@
<!-- 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. -->
+ <p class=XXX>Replace the following steps with "set the tag name".
+
<li>Let <var>new element</var> be a new <span>HTML element</span> with
[[localname]] "span", with the same attributes and [[ownerdocument]] as
<var>element</var>.
@@ -1657,11 +1659,35 @@
<li>If <var>propagated value</var> is null and is not equal to <var>new
value</var>, abort this algorithm.
- <!-- 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
+ <!--
+ 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". -->
+ 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).
+ -->
<li>If the <span>effective value</span> of <var>command</var> is not
<var>new value</var> on the [[parent]] of the last member of <var>ancestor
list</var>, and <var>new value</var> is not null, abort this algorithm.
@@ -2064,6 +2090,10 @@
as desired.
</div>
+<p class=XXX>Consider porting this algorithm to operate on runs of consecutive
+siblings instead of individual nodes. We might be able to make some parts
+smarter, and also might be able to make it more efficient.
+
<ol>
<li>Let <var>command</var> be the current <span>command</span>.
@@ -2837,6 +2867,9 @@
<p class=XXX>Has all the same problems as <span>the <code
title>underline</code> command</span>.
+<p class=XXX>Should we treat ins/del the same as u/s? Currently they're
+unremovable.
+
<p><span>Indeterminate</span>: True if among <span>editable</span> [[text]]
nodes that are <span>effectively contained</span> in the <span>active
range</span>, there is at least one with <span>effective value</span>
@@ -2985,6 +3018,9 @@
may be.
</div>
+<p class=XXX>Should we treat ins/del the same as u/s? Currently they're
+unremovable.
+
<p><span>Indeterminate</span>: True if among <span>editable</span> [[text]]
nodes that are <span>effectively contained</span> in the <span>active
range</span>, there is at least one with <span>effective value</span>