--- a/editcommands.html Tue Mar 01 11:32:02 2011 -0700
+++ b/editcommands.html Wed Mar 02 12:17:54 2011 -0700
@@ -19,7 +19,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-1-march-2011>Work in Progress — Last Update 1 March 2011</h2>
+<h2 class="no-num no-toc" id=work-in-progress-—-last-update-2-march-2011>Work in Progress — Last Update 2 March 2011</h2>
<dl>
<dt>Editor
<dd>Aryeh Gregor <ayg+spec@aryeh.name>
@@ -54,7 +54,8 @@
<li><a href=#styling-a-range><span class=secno>6 </span>Styling a Range</a></li>
<li><a href=#unstyling-a-range><span class=secno>7 </span>Unstyling a Range</a></li>
<li><a href=#commands><span class=secno>8 </span>Commands</a></li>
- <li><a class=no-num href=#references>References</a></ol>
+ <li><a class=no-num href=#references>References</a></li>
+ <li><a class=no-num href=#acknowledgements>Acknowledgements</a></ol>
<!--end-toc-->
@@ -73,23 +74,13 @@
<h2 id=issues><span class=secno>2 </span>Issues</h2>
-<p>I'm not sure if my priorities in writing the algorithms here are correct.
-My goals were 1) make the algorithms as simple as possible, and 2) minimize
-surprising user-visible behavior (e.g., "I clicked B but it didn't turn
-bold!"). I didn't try to optimize the niceness of the resulting DOM at all, so
-for instance, when bolding <code title="">abc <i>def</i> <br> ghi</code>
-you get <code title=""><b>abc </b><i style="font-weight:
-bold">def</i><b> </b><br style="font-weight: bold"><b>
-ghi</b></code> instead of wrapping the whole thing in a single <code title=""><b></code>. This is to avoid making the algorithm understand content
-models, but maybe it's worth revisiting later. Likewise, unbolding the middle
-word of <code title=""><b>Foo bar baz</b></code> produces <code title=""><b>Foo <span style="font-weight: normal">bar</span>
-baz</b></code> instead of the simpler <code title=""><b>Foo </b>bar<b>
-baz</b></code>. For now, the algorithm works, even if it produces messy
-DOMs.
+<ul>
+ <li><p>The styling/unstyling algorithms produce unreasonably messy DOMs. I
+ don't know how far I'll go to simplify the output, but at the very least, I
+ need to wrap continguous phrasing content in a single tag, and be more
+ aggressive about splitting up existing tags instead of nesting extra tags
+ inside (e.g., unbolding the middle letter of <code title=""><b>abc</b></code> should become <code title=""><b>a</b>b<b>c</b></code> instead of <code title=""><b>a<span style=font-weight:normal>b</span>c</b></code>).
-<p>Other issues:
-
-<ul>
<li><p>Need to make CSS terminology more precise, about setting/unsetting CSS
properties. The intent is to modify the style attribute, CSSOM-style.
Likewise, CSS value comparisons need to be done after serializing both
@@ -108,6 +99,11 @@
<li><p>I also don't pay attention to what happens to the selection when you
mutate the DOM. This is essential.
+
+ <li><p>JavaScript can modify the DOM synchronously in some cases, such as DOM
+ mutation events and onunload when moving around iframes and objects. This
+ has to be dealt with somehow. (Pointed out by Ryosuke Niwa of WebKit: <a href=http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-March/030730.html>1</a>
+ <a href=http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-March/030751.html>2</a>)
</ul>
@@ -919,8 +915,17 @@
<div id=anolis-references><dl></dl></div>
-<!--
-<h2 class=no-num>Acknowledgements</h2>
-<p>...
--->
+<h2 class=no-num id=acknowledgements>Acknowledgements</h2>
+<p>Thanks to:
+
+<ul>
+ <li>Google, for funding this work
+ <li>Ian Hickson, for overseeing it
+ <li>Julie Parent, Ojan Vafai, Alex Russel, and Eric Seidel for their <a href=http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-December/024627.html>research</a>
+ on how browsers and other rich text editors behave in many common scenarios
+ <li>Ryosuke Niwa, Julie Parent, and Roland Steiner for their feedback on
+ drafts of this document
+</ul>
+
<script src=http://www.whatwg.org/specs/web-apps/current-work/dfn.js></script>
+<!-- vim: set expandtab shiftwidth=2 tabstop=2: -->
--- a/source.html Tue Mar 01 11:32:02 2011 -0700
+++ b/source.html Wed Mar 02 12:17:54 2011 -0700
@@ -62,25 +62,16 @@
<h2>Issues</h2>
-<p>I'm not sure if my priorities in writing the algorithms here are correct.
-My goals were 1) make the algorithms as simple as possible, and 2) minimize
-surprising user-visible behavior (e.g., "I clicked B but it didn't turn
-bold!"). I didn't try to optimize the niceness of the resulting DOM at all, so
-for instance, when bolding <code title>abc <i>def</i> <br> ghi</code>
-you get <code title><b>abc </b><i style="font-weight:
-bold">def</i><b> </b><br style="font-weight: bold"><b>
-ghi</b></code> instead of wrapping the whole thing in a single <code
-title><b></code>. This is to avoid making the algorithm understand content
-models, but maybe it's worth revisiting later. Likewise, unbolding the middle
-word of <code title><b>Foo bar baz</b></code> produces <code
-title><b>Foo <span style="font-weight: normal">bar</span>
-baz</b></code> instead of the simpler <code title><b>Foo </b>bar<b>
-baz</b></code>. For now, the algorithm works, even if it produces messy
-DOMs.
+<ul>
+ <li><p>The styling/unstyling algorithms produce unreasonably messy DOMs. I
+ don't know how far I'll go to simplify the output, but at the very least, I
+ need to wrap continguous phrasing content in a single tag, and be more
+ aggressive about splitting up existing tags instead of nesting extra tags
+ inside (e.g., unbolding the middle letter of <code
+ title><b>abc</b></code> should become <code
+ title><b>a</b>b<b>c</b></code> instead of <code
+ title><b>a<span style=font-weight:normal>b</span>c</b></code>).
-<p>Other issues:
-
-<ul>
<li><p>Need to make CSS terminology more precise, about setting/unsetting CSS
properties. The intent is to modify the style attribute, CSSOM-style.
Likewise, CSS value comparisons need to be done after serializing both
@@ -99,6 +90,12 @@
<li><p>I also don't pay attention to what happens to the selection when you
mutate the DOM. This is essential.
+
+ <li><p>JavaScript can modify the DOM synchronously in some cases, such as DOM
+ mutation events and onunload when moving around iframes and objects. This
+ has to be dealt with somehow. (Pointed out by Ryosuke Niwa of WebKit: <a
+ href=http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-March/030730.html>1</a>
+ <a href=http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-March/030751.html>2</a>)
</ul>
@@ -948,8 +945,18 @@
<div id=anolis-references></div>
-<!--
<h2 class=no-num>Acknowledgements</h2>
-<p>...
--->
+<p>Thanks to:
+
+<ul>
+ <li>Google, for funding this work
+ <li>Ian Hickson, for overseeing it
+ <li>Julie Parent, Ojan Vafai, Alex Russel, and Eric Seidel for their <a
+ href=http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-December/024627.html>research</a>
+ on how browsers and other rich text editors behave in many common scenarios
+ <li>Ryosuke Niwa, Julie Parent, and Roland Steiner for their feedback on
+ drafts of this document
+</ul>
+
<script src=http://www.whatwg.org/specs/web-apps/current-work/dfn.js></script>
+<!-- vim: set expandtab shiftwidth=2 tabstop=2: -->