Make some changes to non-normative text
authorAryeh Gregor <AryehGregor+gitcommit@gmail.com>
Wed, 23 Mar 2011 11:59:33 -0600
changeset 25 c9c544b49fcd
parent 24 dfe1df743d5c
child 26 4dead548b9d6
Make some changes to non-normative text
editcommands.html
source.html
--- 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-&mdash;-last-update-21-march-2011>Work in Progress &mdash; Last Update 21 March 2011</h2>
+<h2 class="no-num no-toc" id=work-in-progress-&mdash;-last-update-23-march-2011>Work in Progress &mdash; Last Update 23 March 2011</h2>
 <dl>
  <dt>Editor
  <dd>Aryeh Gregor &lt;ayg+spec@aryeh.name&gt;
@@ -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&nbsp;&ndash;
-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&nbsp;&ndash;
-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