--- a/editcommands.html Tue Mar 22 17:51:27 2011 -0600
+++ b/editcommands.html Wed Mar 23 11:59:33 2011 -0600
@@ -27,7 +27,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-21-march-2011>Work in Progress — Last Update 21 March 2011</h2>
+<h2 class="no-num no-toc" id=work-in-progress-—-last-update-23-march-2011>Work in Progress — Last Update 23 March 2011</h2>
<dl>
<dt>Editor
<dd>Aryeh Gregor <ayg+spec@aryeh.name>
@@ -45,7 +45,8 @@
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.
+is encouraged, particularly from implementers and particularly from authors who
+have experience using this feature.
<h2 class=no-num id=table-of-contents>Table of contents</h2>
@@ -168,6 +169,9 @@
editable, making sure not to break out of contenteditable regions, etc.
</ul>
+<p class=XXX>A variety of other issues are also noted in the text, formatted
+like this.
+
<h2 id=definitions><span class=secno>3 </span>Definitions</h2>
@@ -1160,35 +1164,39 @@
value</var> "underline".
<div class=XXX>
-<p>This can change the color of underlines if it pushes them down.
-The right way to fix this is probably to require text-decoration-color –
-granted it won't work in old (or current) browsers, but the only other way
-would be to turn something like
-
-</p><xmp><u><span style="color: red" id=x>
-foo
-bar
-baz
-</span></u></xmp>
-
-<p>into something like
+<p>There are a few problems with underline, because underlines in CSS are
+horrible:
-</p><xmp><span style="color: red" id=x><u style="color: black"><span style="color:
-red">
-foo
-</span></u>bar<u style="color: black"><span style="color: red">
-baz
-</span></u></span></xmp>
+<ul>
+ <li>Pushing down underlines can change their color, since the color of an
+ underline follows the color of the element where it's declared instead of the
+ text it's drawn under. This could be fixed by adding a special case for this
+ condition and inserting extra color rules, such as by setting a color on the
+ underlining element and then having another element inside it that resets the
+ color. Horrible, but . . .
-<p>which is totally not worth it for a corner case. Instead we could do
+ <li>Pushing down underlines can change their thickness in some rendering
+ engines, like Gecko (but not WebKit as of March 2011). This could be worked
+ around similarly to the previous.
-</p><xmp><span style="color: red" id=x><u style="text-decoration-color: black">
-foo
-</u>bar<u style="text-decoration-color: black">
-baz
-</u></span></xmp>
+ <li>The preceding two points can't be avoided, because the only way to remove
+ underlines in CSS is to push down styles (unlike most other things where you
+ could override it).
-<p>although that's not a whole lot better . . .
+ <li>But more generally, from a user's perspective, color and thickness of
+ underlines is going to be more or less random if they're applying them to
+ text with varying size or color. If they underline a bunch of text all at
+ once, it will all get the same color/thickness, probably. But if they
+ underline letter-by-letter, it probably will vary. But sometimes when they
+ underline a bunch of text at once it will also vary, if the algorithm decides
+ to create multiple elements for whatever reason (like an intervening
+ unwrappable element). This is unlikely to match user expectations.
+</ul>
+
+<p>For now I'm just going to ignore the issue, since any attempt to fix it
+would be a pretty ugly hack unless someone fixes up how CSS underlines work,
+and I have bigger fish to fry. But it's something to think about in the
+future.
</div>
<dd><p><strong>State</strong>: True if every <a href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#text><code class=external data-anolis-spec=domcore>Text</code></a> node that is
--- a/source.html Tue Mar 22 17:51:27 2011 -0600
+++ b/source.html Wed Mar 23 11:59:33 2011 -0600
@@ -48,7 +48,8 @@
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.
+is encouraged, particularly from implementers and particularly from authors who
+have experience using this feature.
<h2 class=no-num>Table of contents</h2>
@@ -156,6 +157,9 @@
editable, making sure not to break out of contenteditable regions, etc.
</ul>
+<p class=XXX>A variety of other issues are also noted in the text, formatted
+like this.
+
<h2>Definitions</h2>
@@ -1172,35 +1176,39 @@
value</var> "underline".
<div class=XXX>
-<p>This can change the color of underlines if it pushes them down.
-The right way to fix this is probably to require text-decoration-color –
-granted it won't work in old (or current) browsers, but the only other way
-would be to turn something like
-
-<xmp><u><span style="color: red" id=x>
-foo
-bar
-baz
-</span></u></xmp>
-
-<p>into something like
+<p>There are a few problems with underline, because underlines in CSS are
+horrible:
-<xmp><span style="color: red" id=x><u style="color: black"><span style="color:
-red">
-foo
-</span></u>bar<u style="color: black"><span style="color: red">
-baz
-</span></u></span></xmp>
+<ul>
+ <li>Pushing down underlines can change their color, since the color of an
+ underline follows the color of the element where it's declared instead of the
+ text it's drawn under. This could be fixed by adding a special case for this
+ condition and inserting extra color rules, such as by setting a color on the
+ underlining element and then having another element inside it that resets the
+ color. Horrible, but . . .
-<p>which is totally not worth it for a corner case. Instead we could do
+ <li>Pushing down underlines can change their thickness in some rendering
+ engines, like Gecko (but not WebKit as of March 2011). This could be worked
+ around similarly to the previous.
-<xmp><span style="color: red" id=x><u style="text-decoration-color: black">
-foo
-</u>bar<u style="text-decoration-color: black">
-baz
-</u></span></xmp>
+ <li>The preceding two points can't be avoided, because the only way to remove
+ underlines in CSS is to push down styles (unlike most other things where you
+ could override it).
-<p>although that's not a whole lot better . . .
+ <li>But more generally, from a user's perspective, color and thickness of
+ underlines is going to be more or less random if they're applying them to
+ text with varying size or color. If they underline a bunch of text all at
+ once, it will all get the same color/thickness, probably. But if they
+ underline letter-by-letter, it probably will vary. But sometimes when they
+ underline a bunch of text at once it will also vary, if the algorithm decides
+ to create multiple elements for whatever reason (like an intervening
+ unwrappable element). This is unlikely to match user expectations.
+</ul>
+
+<p>For now I'm just going to ignore the issue, since any attempt to fix it
+would be a pretty ugly hack unless someone fixes up how CSS underlines work,
+and I have bigger fish to fry. But it's something to think about in the
+future.
</div>
<dd><p><strong>State</strong>: True if every [[text]] node that is