Update some todos/comments
authorAryeh Gregor <AryehGregor+gitcommit@gmail.com>
Sun, 29 May 2011 15:26:38 -0600
changeset 187 06eb622b8eb3
parent 186 da049543cff1
child 188 6b89f193790b
Update some todos/comments
editcommands.html
source.html
--- a/editcommands.html	Sun May 29 15:19:36 2011 -0600
+++ b/editcommands.html	Sun May 29 15:26:38 2011 -0600
@@ -245,14 +245,17 @@
   selection is collapsed.  Needs investigation.
 
   <li>What should be used as a line separator?  See <a href=http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-May/031577.html>lengthy
-  discussion</a>.  I see no strong arguments in favor of any of the three
-  existing behaviors, so I'm weakly in favor of following the plurality, namely
-  IE/Opera's behavior of using <code class=external data-anolis-spec=html title="the p element"><a href=http://www.whatwg.org/html/#the-p-element>p</a></code>.  This affects not only what happens when
-  the user hits Enter, but also what happens when we need to separate lines for
-  other reasons (e.g., outdenting a list).  We likely want switches to allow
-  authors to control this behavior, like Gecko's insertBrOnReturn and Opera's
-  opera-defaultblock.  Currently the spec assumes <code class=external data-anolis-spec=html title="the br element"><a href=http://www.whatwg.org/html/#the-br-element>br</a></code> should separate lines,
-  which is like Gecko and sometimes WebKit.
+  discussion</a>.  This affects not only what happens when the user hits Enter,
+  but also what happens when we need to separate lines for other reasons (e.g.,
+  outdenting a list).  We likely want switches to allow authors to control this
+  behavior, like Gecko's insertBrOnReturn and Opera's opera-defaultblock.
+  Previously the spec assumed <code class=external data-anolis-spec=html title="the br element"><a href=http://www.whatwg.org/html/#the-br-element>br</a></code> should separate lines, which is like Gecko
+  and sometimes WebKit, but I'm moving it to use <code class=external data-anolis-spec=html title="the p element"><a href=http://www.whatwg.org/html/#the-p-element>p</a></code> instead.
+
+  <li><code class=external data-anolis-spec=html title="the br element"><a href=http://www.whatwg.org/html/#the-br-element>br</a></code>s are a nightmare.  I have tons of hacks all over the place which
+  are totally wrong, mostly to account for the fact that sometimes <code class=external data-anolis-spec=html title="the br element"><a href=http://www.whatwg.org/html/#the-br-element>br</a></code>s do
+  nothing and we need to treat that case magically.  I don't know what a good
+  way is to fix this.
 </ul>
 
 <p class=XXX>A variety of other issues are also noted in the text, formatted
@@ -4145,9 +4148,12 @@
 execCommand("formatBlock", false, "p"), which is not really useful.  IE9
 actually just overwrites the selection with an empty paragraph element, which
 seems not very useful either.  Chrome 13 dev and Opera 11.10 behave basically
-the same as if the user hit the Return key.  This later behavior seems much
+the same as if the user hit the Return key.  This latter behavior seems much
 more useful, even though it's horribly misnamed, so it's what I'll spec.
 
+(Actually, Opera doesn't behave quite the same for insertParagraph and line
+breaks.  But it's pretty close, and I expect the differences are bugs.)
+
 Then, of course, we have several flavors of line-breaking behavior to choose
 from.  Firefox prefers <br>s, unless it's in the middle of a <p> or something.
 Opera and IE like <p>.  Chrome prefers <div>.  And there are lots of subtleties
@@ -4356,6 +4362,10 @@
   <li>If <var title="">new container</var> has no <a class=external data-anolis-spec=domcore href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-tree-child title=concept-tree-child>children</a>, call
   <code class=external data-anolis-spec=domcore title=dom-Document-createElement><a href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-document-createelement>createElement("br")</a></code> on the <a class=external data-anolis-spec=domrange href=http://html5.org/specs/dom-range.html#context-object>context object</a>, and append the result as the
   last <a class=external data-anolis-spec=domcore href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-tree-child title=concept-tree-child>child</a> of <var title="">new container</var>.
+  <!-- These two steps follow Firefox 5.0a2, Chrome 13 dev, and Opera 11.10.
+  IE9 instead inserts an &nbsp; which magically does not appear in innerHTML.
+  In all cases, the reason is that an empty block box in CSS will have zero
+  height, so the user won't be able to put the selection cursor inside it. -->
 
   <p class=XXX>Needs to also happen if there are only comments/whitespace/etc.
   Also, this can leave stray useless br's lying around.  Probably when the user
--- a/source.html	Sun May 29 15:19:36 2011 -0600
+++ b/source.html	Sun May 29 15:26:38 2011 -0600
@@ -197,14 +197,17 @@
 
   <li>What should be used as a line separator?  See <a
   href=http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-May/031577.html>lengthy
-  discussion</a>.  I see no strong arguments in favor of any of the three
-  existing behaviors, so I'm weakly in favor of following the plurality, namely
-  IE/Opera's behavior of using [[p]].  This affects not only what happens when
-  the user hits Enter, but also what happens when we need to separate lines for
-  other reasons (e.g., outdenting a list).  We likely want switches to allow
-  authors to control this behavior, like Gecko's insertBrOnReturn and Opera's
-  opera-defaultblock.  Currently the spec assumes [[br]] should separate lines,
-  which is like Gecko and sometimes WebKit.
+  discussion</a>.  This affects not only what happens when the user hits Enter,
+  but also what happens when we need to separate lines for other reasons (e.g.,
+  outdenting a list).  We likely want switches to allow authors to control this
+  behavior, like Gecko's insertBrOnReturn and Opera's opera-defaultblock.
+  Previously the spec assumed [[br]] should separate lines, which is like Gecko
+  and sometimes WebKit, but I'm moving it to use [[p]] instead.
+
+  <li>[[br]]s are a nightmare.  I have tons of hacks all over the place which
+  are totally wrong, mostly to account for the fact that sometimes [[br]]s do
+  nothing and we need to treat that case magically.  I don't know what a good
+  way is to fix this.
 </ul>
 
 <p class=XXX>A variety of other issues are also noted in the text, formatted
@@ -4177,9 +4180,12 @@
 execCommand("formatBlock", false, "p"), which is not really useful.  IE9
 actually just overwrites the selection with an empty paragraph element, which
 seems not very useful either.  Chrome 13 dev and Opera 11.10 behave basically
-the same as if the user hit the Return key.  This later behavior seems much
+the same as if the user hit the Return key.  This latter behavior seems much
 more useful, even though it's horribly misnamed, so it's what I'll spec.
 
+(Actually, Opera doesn't behave quite the same for insertParagraph and line
+breaks.  But it's pretty close, and I expect the differences are bugs.)
+
 Then, of course, we have several flavors of line-breaking behavior to choose
 from.  Firefox prefers <br>s, unless it's in the middle of a <p> or something.
 Opera and IE like <p>.  Chrome prefers <div>.  And there are lots of subtleties
@@ -4394,6 +4400,10 @@
   <li>If <var>new container</var> has no [[children]], call
   [[createelement|"br"]] on the [[contextobject]], and append the result as the
   last [[child]] of <var>new container</var>.
+  <!-- These two steps follow Firefox 5.0a2, Chrome 13 dev, and Opera 11.10.
+  IE9 instead inserts an &nbsp; which magically does not appear in innerHTML.
+  In all cases, the reason is that an empty block box in CSS will have zero
+  height, so the user won't be able to put the selection cursor inside it. -->
 
   <p class=XXX>Needs to also happen if there are only comments/whitespace/etc.
   Also, this can leave stray useless br's lying around.  Probably when the user