--- a/editcommands.html	Wed Jul 13 11:34:18 2011 -0600
+++ b/editcommands.html	Wed Jul 13 11:39:49 2011 -0600
@@ -2943,7 +2943,7 @@
 selection's value</a> to "line-through", otherwise <a href="#set-the-selection's-value">set the selection's
 value</a> to null.
 
-<!-- Has all the same problems as underline. -->
+<!-- TODO: See underline TODO. -->
 
 <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
@@ -3032,12 +3032,13 @@
 selection's value</a> to "underline", otherwise <a href="#set-the-selection's-value">set the selection's
 value</a> to null.
 
-<div class=XXX>
-<p>There are a lot of problems with underline color and thickness, because
-text-decoration in CSS is horrible:
-
-<ul>
-  <li>Pushing down underlines can change their color, since the color of an
+<!--
+TODO: There are a lot of problems with underline color and thickness, because
+text-decoration in CSS is horrible.  These aren't prohibitive for normal use
+and existing browsers don't handle them either, so fixing these problems or
+working around them can be put off for now.
+
+* 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
@@ -3046,40 +3047,35 @@
   text-decoration-color property in the CSS 3 Text draft could come in handy
   here, in which case we'd degrade pretty gracefully in legacy UAs.
 
-  <li>Underline thickness depends on font-size in all rendering engines but
-  WebKit, so pushing them down creates thickness problems as well as color
-  problems.  Working around this is a similar story to the previous, except we
-  have no text-decoration-width property yet (see <a href=http://lists.w3.org/Archives/Public/www-style/2011Mar/0593.html>feedback
-  to www-style</a>).
-
-  <li>The preceding two points can't be avoided, because the only way to remove
+* Underline thickness depends on font-size in all rendering engines but WebKit,
+  so pushing them down creates thickness problems as well as color problems.
+  Working around this is a similar story to the previous, except we have no
+  text-decoration-width property yet (see
+  http://lists.w3.org/Archives/Public/www-style/2011Mar/0593.html).
+
+* 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).  Recent (February 2011) CSS 3 Text drafts have added
   support for a "text-decoration-line: cancel-underline" property, but we can
   only use that if there's no other possibility, since it won't work in legacy
   browsers.  (Although we should use it once there's no other possibility.)
 
-  <li>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 node).  This is unlikely to match user expectations.  There's
-  not much we can do about this without entirely revamping text-decoration, so
-  we'll have to live with it.
-
-  <li>Currently we don't treat non-underline text-decorations properly, because
-  we have no way to set (or cancel) underlines independently of other
-  text-decorations from within CSS.  I've sent <a href=http://lists.w3.org/Archives/Public/www-style/2011Mar/0591.html>feedback
-  to www-style</a>.
-</ul>
-
-<p>I'll revisit some of these issues when I get feedback on www-style, either
-using the newly-specced features or working around their absence as the case
-may be.
-</div>
+* 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 node).
+  This is unlikely to match user expectations.  There's not much we can do
+  about this without entirely revamping text-decoration, so we'll have to live
+  with it.
+
+* Currently we don't treat non-underline text-decorations properly, because we
+  have no way to set (or cancel) underlines independently of other
+  text-decorations from within CSS.  I've sent feedback to www-style:
+  http://lists.w3.org/Archives/Public/www-style/2011Mar/0591.html.
+-->
 
 <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

--- a/source.html	Wed Jul 13 11:34:18 2011 -0600
+++ b/source.html	Wed Jul 13 11:39:49 2011 -0600
@@ -2918,7 +2918,7 @@
 selection's value</span> to "line-through", otherwise <span>set the selection's
 value</span> to null.
 
-<!-- Has all the same problems as underline. -->
+<!-- TODO: See underline TODO. -->
 
 <p><span>Indeterminate</span>: True if among <span>editable</span> [[text]]
 nodes that are <span>effectively contained</span> in the <span>active
@@ -3007,12 +3007,13 @@
 selection's value</span> to "underline", otherwise <span>set the selection's
 value</span> to null.
 
-<div class=XXX>
-<p>There are a lot of problems with underline color and thickness, because
-text-decoration in CSS is horrible:
-
-<ul>
-  <li>Pushing down underlines can change their color, since the color of an
+<!--
+TODO: There are a lot of problems with underline color and thickness, because
+text-decoration in CSS is horrible.  These aren't prohibitive for normal use
+and existing browsers don't handle them either, so fixing these problems or
+working around them can be put off for now.
+
+* 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
@@ -3021,42 +3022,35 @@
   text-decoration-color property in the CSS 3 Text draft could come in handy
   here, in which case we'd degrade pretty gracefully in legacy UAs.
 
-  <li>Underline thickness depends on font-size in all rendering engines but
-  WebKit, so pushing them down creates thickness problems as well as color
-  problems.  Working around this is a similar story to the previous, except we
-  have no text-decoration-width property yet (see <a
-  href="http://lists.w3.org/Archives/Public/www-style/2011Mar/0593.html">feedback
-  to www-style</a>).
-
-  <li>The preceding two points can't be avoided, because the only way to remove
+* Underline thickness depends on font-size in all rendering engines but WebKit,
+  so pushing them down creates thickness problems as well as color problems.
+  Working around this is a similar story to the previous, except we have no
+  text-decoration-width property yet (see
+  http://lists.w3.org/Archives/Public/www-style/2011Mar/0593.html).
+
+* 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).  Recent (February 2011) CSS 3 Text drafts have added
   support for a "text-decoration-line: cancel-underline" property, but we can
   only use that if there's no other possibility, since it won't work in legacy
   browsers.  (Although we should use it once there's no other possibility.)
 
-  <li>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 node).  This is unlikely to match user expectations.  There's
-  not much we can do about this without entirely revamping text-decoration, so
-  we'll have to live with it.
-
-  <li>Currently we don't treat non-underline text-decorations properly, because
-  we have no way to set (or cancel) underlines independently of other
-  text-decorations from within CSS.  I've sent <a
-  href="http://lists.w3.org/Archives/Public/www-style/2011Mar/0591.html">feedback
-  to www-style</a>.
-</ul>
-
-<p>I'll revisit some of these issues when I get feedback on www-style, either
-using the newly-specced features or working around their absence as the case
-may be.
-</div>
+* 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 node).
+  This is unlikely to match user expectations.  There's not much we can do
+  about this without entirely revamping text-decoration, so we'll have to live
+  with it.
+
+* Currently we don't treat non-underline text-decorations properly, because we
+  have no way to set (or cancel) underlines independently of other
+  text-decorations from within CSS.  I've sent feedback to www-style:
+  http://lists.w3.org/Archives/Public/www-style/2011Mar/0591.html.
+-->
 
 <p><span>Indeterminate</span>: True if among <span>editable</span> [[text]]
 nodes that are <span>effectively contained</span> in the <span>active