--- a/editcommands.html Sun May 08 11:36:05 2011 -0600
+++ b/editcommands.html Sun May 08 11:52:58 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-5-may-2011>Work in Progress — Last Update 5 May 2011</h2>
+<h2 class="no-num no-toc" id=work-in-progress-—-last-update-8-may-2011>Work in Progress — Last Update 8 May 2011</h2>
<dl>
<dt>Editor
<dd>Aryeh Gregor <ayg+spec@aryeh.name>
@@ -603,6 +603,25 @@
<h2 id=normalizing-sublists-of-a-list-item><span class=secno>5 </span>Normalizing sublists of a list item</h2>
<p>When a user agent is to <dfn id=normalize-sublists>normalize sublists</dfn> in an <code class=external data-anolis-spec=html title="the li element"><a href=http://www.whatwg.org/html/#the-li-element>li</a></code>
<var title="">item</var>, it must run the following steps:
+<!--
+This algorithm implies that we don't support a sublist in the middle of an
+item, only at the end. For instance,
+
+ <li>foo<ol>...</ol>bar</li>
+
+gets transformed to
+
+ <li>foo</li><ol>...</ol><li>bar</li>
+
+which in particular creates an extra list marker for "bar". This is okay; we
+don't need to expose all of HTML's markup abilities through execCommand().
+Similarly, the superscript and subscript commands don't allow nesting. I
+didn't see any way to get a sublist in the middle of an item in Word 2007 or in
+OpenOffice.org 3.2.1 Ubuntu package, nor in any browser using just
+execCommand(), so it should be no big problem if we require that such nesting
+not occur. (Existing browsers behave weirdly and inconsistently when
+confronted with this kind of nesting.)
+-->
<ol>
<li>If <var title="">item</var> is not <a href=#editable>editable</a> or 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 not
@@ -1928,6 +1947,11 @@
(IE, Firefox CSS). The latter approach is only possible by adding extra markup
and complexity, so for now we'll take the easy way out and go with just
indenting on both sides.
+
+
+This reasoning doesn't discuss lists. For research on lists, see the comment
+for insertOrderedList. List handling is more complicated and I wound up
+differing from all browsers in lots of ways.
-->
<dd><strong>Action</strong>:
--- a/source.html Sun May 08 11:36:05 2011 -0600
+++ b/source.html Sun May 08 11:52:58 2011 -0600
@@ -597,6 +597,25 @@
<h2>Normalizing sublists of a list item</h2>
<p>When a user agent is to <dfn>normalize sublists</dfn> in an [[li]]
<var>item</var>, it must run the following steps:
+<!--
+This algorithm implies that we don't support a sublist in the middle of an
+item, only at the end. For instance,
+
+ <li>foo<ol>...</ol>bar</li>
+
+gets transformed to
+
+ <li>foo</li><ol>...</ol><li>bar</li>
+
+which in particular creates an extra list marker for "bar". This is okay; we
+don't need to expose all of HTML's markup abilities through execCommand().
+Similarly, the superscript and subscript commands don't allow nesting. I
+didn't see any way to get a sublist in the middle of an item in Word 2007 or in
+OpenOffice.org 3.2.1 Ubuntu package, nor in any browser using just
+execCommand(), so it should be no big problem if we require that such nesting
+not occur. (Existing browsers behave weirdly and inconsistently when
+confronted with this kind of nesting.)
+-->
<ol>
<li>If <var>item</var> is not <span>editable</span> or its [[parent]] is not
@@ -1947,6 +1966,11 @@
(IE, Firefox CSS). The latter approach is only possible by adding extra markup
and complexity, so for now we'll take the easy way out and go with just
indenting on both sides.
+
+
+This reasoning doesn't discuss lists. For research on lists, see the comment
+for insertOrderedList. List handling is more complicated and I wound up
+differing from all browsers in lots of ways.
-->
<dd><strong>Action</strong>: