--- a/editing.html Wed Oct 26 15:03:20 2011 -0600
+++ b/editing.html Thu Oct 27 12:48:44 2011 -0600
@@ -21,8 +21,10 @@
margin-left: 2em;
white-space: pre-wrap;
}
-div.note > p:first-child::before { content: 'Note: '; }
+div.note > p:first-child::before,
+li.note > p:first-child::before { content: 'Note: ' }
.note var { font-style: normal }
+li.note { display: block }
.XXX > :last-child { margin-bottom: 0 }
.XXX li {
margin-top: 0;
@@ -65,7 +67,7 @@
<body class=draft>
<div class=head id=head>
<h1>HTML Editing APIs</h1>
-<h2 class="no-num no-toc" id=work-in-progress-—-last-update-26-october-2011>Work in Progress — Last Update 26 October 2011</h2>
+<h2 class="no-num no-toc" id=work-in-progress-—-last-update-27-october-2011>Work in Progress — Last Update 27 October 2011</h2>
<dl>
<dt>Editor
<dd>Aryeh Gregor <<a href=mailto:ayg@aryeh.name>ayg@aryeh.name</a>>
@@ -5212,11 +5214,11 @@
and <var title="">end offset</var> be the <a href=#active-range>active range</a>'s <a class=external data-anolis-spec=dom href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-range-start title=concept-range-start>start</a>
and <a class=external data-anolis-spec=dom href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-range-end title=concept-range-end>end</a> <a class=external data-anolis-spec=dom href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-node title=concept-node>nodes</a> and <a class=external data-anolis-spec=dom href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-range-bp-offset title=concept-range-bp-offset>offsets</a>.
+ <li class=note>
+ <p>First we adjust the selection so that we don't delete more than we should.
+
<li>
<div class=comments>
- <p>We drill the range down to the lowest possible level, so we don't delete
- more elements than necessary.
-
<p>We don't want to keep going when we hit an element with no children,
because then we'd do something like
@@ -5338,19 +5340,17 @@
<li>Call <code title=dom-Selection-extend><a href=#dom-selection-extend>extend(<var title="">end node</var>, <var title="">end offset</var>)</a></code> on the
<a class=external data-anolis-spec=dom href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#context-object>context object</a>'s <a href=#concept-selection title=concept-selection>selection</a>.
- <li>
- <div class=comments>
+ <li class=note>
<p>When we delete a selection that spans multiple blocks, we merge the end
block's contents into the start block, like
<pre><p>fo[o</p><pre>b]ar</pre>
-> <p>fo[]ar</p>.</pre>
- <p>Figure out what the start and end blocks are before we start deleting
+ <p>We figure out what the start and end blocks are before we start deleting
anything.
- </div>
-
- <p>Let <var title="">start block</var> be the <a href=#active-range>active range</a>'s
+
+ <li>Let <var title="">start block</var> be the <a href=#active-range>active range</a>'s
<a class=external data-anolis-spec=dom href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-range-start-node title=concept-range-start-node>start node</a>.
<li>While <var title="">start block</var>'s <a class=external data-anolis-spec=dom href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-tree-parent title=concept-tree-parent>parent</a> is <a href=#in-the-same-editing-host>in the same editing
@@ -5362,10 +5362,11 @@
<p>We only merge to or from block nodes or editing hosts. (This is just in
case someone makes a span into an editing host and sticks paragraphs inside
it or something . . . we could probably drop that proviso.) Firefox 7.0a2
- ignores the display property when merging, so it doesn't merge <span
- style=display:block> but does merge <p style=display:inline>. This is
- undesirable, because it's visually wrong. IE10PP2 and Chrome 14 dev behave
- more like the spec, and Opera 11.50 seems to be unable to make up its mind.
+ ignores the display property when merging, so it doesn't merge <code title=""><span
+ style=display:block></code> but does merge <code title=""><p style=display:inline></code>.
+ This is undesirable, because it's visually wrong. IE10PP2 and Chrome 14 dev
+ behave more like the spec, and Opera 11.50 seems to be unable to make up its
+ mind.
<p>If span isn't an allowed child, it's probably something unpleasant like a
table row or a list or such. We don't want to merge to or from something
@@ -5398,6 +5399,11 @@
<var title="">end block</var>, or <var title="">end block</var> is a <code class=external data-anolis-spec=html title="the td element"><a href=http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#the-td-element>td</a></code> or <code class=external data-anolis-spec=html title="the th element"><a href=http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#the-th-element>th</a></code>, set
<var title="">end block</var> to null.
+ <li class=note>
+ <p>Later on we'll restore <var title="">overrides</var>. This ensures that
+ if we delete inline formatting elements and the user then types something,
+ the typed text will have the same style as before.
+
<li>
<div class=comments>
<p>As far as I can tell, IE9 and Opera 11.50 don't do this at all. If you
@@ -5415,6 +5421,9 @@
<p><a href=#record-current-states-and-values>Record current states and values</a>, and let
<var title="">overrides</var> be the result.
+ <li class=note>
+ <p>Now we actually begin deleting things.
+
<li>
<p class=comments>This whole piece of the algorithm is based on
deleteContents() in DOM Range, copy-pasted and then adjusted to fit.
@@ -5476,15 +5485,16 @@
<li>
<p class=comments>Taking insertText to test the case where strip wrappers
- is false, with value a: <p>[foo<b>bar</b>]baz becomes <p>a[]baz
- per spec, in IE9, and in Chrome 14 dev. Firefox 7.0a2 and Opera 11.50 make
- it <p>a[]<b></b>baz, with a useless wrapper.
- <p>foo<b>[bar</b>baz] becomes <p>foo<b>a[]</b> per spec
+ is false, with value a: <code title=""><p>[foo<b>bar</b>]baz</code> becomes
+ <code title=""><p>a[]baz</code> per spec, in IE9, and in Chrome 14 dev. Firefox 7.0a2
+ and Opera 11.50 make it <code title=""><p>a[]<b></b>baz</code>, with a useless wrapper.
+ <code title=""><p>foo<b>[bar</b>baz]</code> becomes <code title=""><p>foo<b>a[]</b></code> per spec
and in IE9 and Firefox 7.0a2 and Opera 11.50; in Chrome 14 dev apparently
- it initially becomes <p>fooa[], but then the style is recreated. This
- is detectable if you do something weird like <span style=color:#aBcDeF>
- instead of <b>: it comes <font class=Apple-style-span color=#abcdef>
- or such. I follow IE9 in all cases, because it makes the most sense.
+ it initially becomes <code title=""><p>fooa[]</code>, but then the style is recreated.
+ This is detectable if you do something weird like <code title=""><span
+ style=color:#aBcDeF></code> instead of <code title=""><b></code>: it comes <code title=""><font
+ class=Apple-style-span color=#abcdef></code> or such. I follow IE9 in all
+ cases, because it makes the most sense.
<p>If <var title="">strip wrappers</var> is true or <var title="">parent</var> is not an
<a class=external data-anolis-spec=dom href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-tree-inclusive-ancestor title=concept-tree-inclusive-ancestor>inclusive ancestor</a> of <var title="">start node</var>, while <var title="">parent</var> is
@@ -5508,8 +5518,7 @@
<li><a href=#canonicalize-whitespace>Canonicalize whitespace</a> at the <a href=#active-range>active range</a>'s
<a class=external data-anolis-spec=dom href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-range-end title=concept-range-end>end</a>, with <var title="">fix collapsed space</var> false.
- <li>
- <div class=comments>
+ <li class=note>
<p>Now we need to merge blocks. The simplest case is something like
<pre><p>fo[o</p><p>bar</p><p>b]az</p>
@@ -5528,9 +5537,8 @@
-> <p>foo[]bar</p></pre>
<p>where one descends from the other.
- </div>
-
- <p>If <var title="">block merging</var> is false, or <var title="">start block</var> or
+
+ <li>If <var title="">block merging</var> is false, or <var title="">start block</var> or
<var title="">end block</var> is null, or <var title="">start block</var> is not <a href=#in-the-same-editing-host>in the
same editing host</a> as <var title="">end block</var>, or <var title="">start block</var>
and <var title="">end block</var> are the same:
--- a/preprocess Wed Oct 26 15:03:20 2011 -0600
+++ b/preprocess Thu Oct 27 12:48:44 2011 -0600
@@ -166,16 +166,21 @@
if "[[" in s:
raise Exception("Unrecognized macro: " + s[s.find("[["):s.find("]]") + 2])
-# {{code|<foo>}} -> <code title><foo></code>. Also, to avoid things like
-# {{code|<b>}} messing up syntax highlighting, {{code<|b>}} is also supported
-# with the same effect as {{code|<b>}}.
+# {{html|<foo>}} -> <foo>, no wrapper. Also, to avoid things like
+# {{code|<b>}} messing up syntax highlighting, {{html<|b>}} is also supported
+# with the same effect as {{html|<b>}}.
+def htmlsub(matchobj):
+ return matchobj.group(1).replace("<", "<") \
+ + matchobj.group(2).replace("&", "&").replace("<", "<")
+
+# {{code|...}} is just a shortcut for <code title>{{pre|...}}</code>.
def codesub(matchobj):
return "<code title>" \
- + matchobj.group(1).replace("<", "<") \
- + matchobj.group(2).replace("&", "&").replace("<", "<") \
+ + htmlsub(matchobj) \
+ "</code>"
-s = re.sub(r"\{\{code(<?)\|(.*?)\}\}", codesub, s)
+s = re.compile(r"\{\{html(<?)\|(.*?)\}\}", re.DOTALL).sub(htmlsub, s)
+s = re.compile(r"\{\{code(<?)\|(.*?)\}\}", re.DOTALL).sub(codesub, s)
s = s.replace("<var>", "<var title>")
--- a/source.html Wed Oct 26 15:03:20 2011 -0600
+++ b/source.html Thu Oct 27 12:48:44 2011 -0600
@@ -23,8 +23,10 @@
margin-left: 2em;
white-space: pre-wrap;
}
-div.note > p:first-child::before { content: 'Note: '; }
+div.note > p:first-child::before,
+li.note > p:first-child::before { content: 'Note: ' }
.note var { font-style: normal }
+li.note { display: block }
.XXX > :last-child { margin-bottom: 0 }
.XXX li {
margin-top: 0;
@@ -5261,11 +5263,11 @@
and <var>end offset</var> be the <span>active range</span>'s [[rangestart]]
and [[rangeend]] [[nodes]] and [[bpoffsets]].
+ <li class=note>
+ <p>First we adjust the selection so that we don't delete more than we should.
+
<li>
<div class=comments>
- <p>We drill the range down to the lowest possible level, so we don't delete
- more elements than necessary.
-
<p>We don't want to keep going when we hit an element with no children,
because then we'd do something like
@@ -5388,19 +5390,18 @@
<li>Call [[extend|<var>end node</var>, <var>end offset</var>]] on the
[[contextobject]]'s [[selection]].
- <li>
- <div class=comments>
+ <li class=note>
<p>When we delete a selection that spans multiple blocks, we merge the end
block's contents into the start block, like
-<pre><p>fo[o</p><pre>b]ar</pre>
--> <p>fo[]ar</p>.</pre>
-
- <p>Figure out what the start and end blocks are before we start deleting
+<pre>{{html|
+<p>fo[o</p><pre>b]ar</pre>
+-> <p>fo[]ar</p>.}}</pre>
+
+ <p>We figure out what the start and end blocks are before we start deleting
anything.
- </div>
-
- <p>Let <var>start block</var> be the <span>active range</span>'s
+
+ <li>Let <var>start block</var> be the <span>active range</span>'s
[[startnode]].
<li>While <var>start block</var>'s [[parent]] is <span>in the same editing
@@ -5412,10 +5413,11 @@
<p>We only merge to or from block nodes or editing hosts. (This is just in
case someone makes a span into an editing host and sticks paragraphs inside
it or something . . . we could probably drop that proviso.) Firefox 7.0a2
- ignores the display property when merging, so it doesn't merge <span
- style=display:block> but does merge <p style=display:inline>. This is
- undesirable, because it's visually wrong. IE10PP2 and Chrome 14 dev behave
- more like the spec, and Opera 11.50 seems to be unable to make up its mind.
+ ignores the display property when merging, so it doesn't merge {{code|<span
+ style=display:block>}} but does merge {{code|<p style=display:inline>}}.
+ This is undesirable, because it's visually wrong. IE10PP2 and Chrome 14 dev
+ behave more like the spec, and Opera 11.50 seems to be unable to make up its
+ mind.
<p>If span isn't an allowed child, it's probably something unpleasant like a
table row or a list or such. We don't want to merge to or from something
@@ -5448,6 +5450,11 @@
<var>end block</var>, or <var>end block</var> is a [[td]] or [[th]], set
<var>end block</var> to null.
+ <li class=note>
+ <p>Later on we'll restore <var>overrides</var>. This ensures that
+ if we delete inline formatting elements and the user then types something,
+ the typed text will have the same style as before.
+
<li>
<div class=comments>
<p>As far as I can tell, IE9 and Opera 11.50 don't do this at all. If you
@@ -5465,6 +5472,9 @@
<p><span>Record current states and values</span>, and let
<var>overrides</var> be the result.
+ <li class=note>
+ <p>Now we actually begin deleting things.
+
<li>
<p class=comments>This whole piece of the algorithm is based on
deleteContents() in DOM Range, copy-pasted and then adjusted to fit.
@@ -5526,15 +5536,16 @@
<li>
<p class=comments>Taking insertText to test the case where strip wrappers
- is false, with value a: <p>[foo<b>bar</b>]baz becomes <p>a[]baz
- per spec, in IE9, and in Chrome 14 dev. Firefox 7.0a2 and Opera 11.50 make
- it <p>a[]<b></b>baz, with a useless wrapper.
- <p>foo<b>[bar</b>baz] becomes <p>foo<b>a[]</b> per spec
+ is false, with value a: {{code<|p>[foo<b>bar</b>]baz}} becomes
+ {{code|<p>a[]baz}} per spec, in IE9, and in Chrome 14 dev. Firefox 7.0a2
+ and Opera 11.50 make it {{code<|p>a[]<b></b>baz}}, with a useless wrapper.
+ {{code<|p>foo<b>[bar</b>baz]}} becomes {{code<|p>foo<b>a[]</b>}} per spec
and in IE9 and Firefox 7.0a2 and Opera 11.50; in Chrome 14 dev apparently
- it initially becomes <p>fooa[], but then the style is recreated. This
- is detectable if you do something weird like <span style=color:#aBcDeF>
- instead of <b>: it comes <font class=Apple-style-span color=#abcdef>
- or such. I follow IE9 in all cases, because it makes the most sense.
+ it initially becomes {{code|<p>fooa[]}}, but then the style is recreated.
+ This is detectable if you do something weird like {{code<|span
+ style=color:#aBcDeF>}} instead of {{code<|b>}}: it comes {{code<|font
+ class=Apple-style-span color=#abcdef>}} or such. I follow IE9 in all
+ cases, because it makes the most sense.
<p>If <var>strip wrappers</var> is true or <var>parent</var> is not an
[[inclusiveancestor]] of <var>start node</var>, while <var>parent</var> is
@@ -5558,32 +5569,30 @@
<li><span>Canonicalize whitespace</span> at the <span>active range</span>'s
[[rangeend]], with <var>fix collapsed space</var> false.
- <li>
- <div class=comments>
+ <li class=note>
<p>Now we need to merge blocks. The simplest case is something like
-<pre>
-<p>fo[o</p><p>bar</p><p>b]az</p>
--> <p>fo</p>{}<p>az</p>
--> <p>fo{}az</p></pre>
+<pre>{{html|
+<p>fo[o</p><p>bar</p><p>b]az</p>
+-> <p>fo</p>{}<p>az</p>
+-> <p>fo{}az</p>}}</pre>
<p>where neither block descends from the other. More complicated is
something like
-<pre>
-foo[<p>]bar</p>
--> foo[]bar</pre>
+<pre>{{html|
+foo[<p>]bar</p>
+-> foo[]bar}}</pre>
<p>or
-<pre>
-<p>foo[</p>]bar
--> <p>foo[]bar</p></pre>
+<pre>{{html|
+<p>foo[</p>]bar
+-> <p>foo[]bar</p>}}</pre>
<p>where one descends from the other.
- </div>
-
- <p>If <var>block merging</var> is false, or <var>start block</var> or
+
+ <li>If <var>block merging</var> is false, or <var>start block</var> or
<var>end block</var> is null, or <var>start block</var> is not <span>in the
same editing host</span> as <var>end block</var>, or <var>start block</var>
and <var>end block</var> are the same: