--- 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 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 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