[html5] r6570 - [e] (0) Provide advice to authors regarding styling editing regions Fixing http: [...]
whatwg at whatwg.org
whatwg at whatwg.org
Thu Sep 22 17:14:48 PDT 2011
Author: ianh
Date: 2011-09-22 17:14:46 -0700 (Thu, 22 Sep 2011)
New Revision: 6570
Modified:
complete.html
index
source
Log:
[e] (0) Provide advice to authors regarding styling editing regions
Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=13011
Modified: complete.html
===================================================================
--- complete.html 2011-09-22 23:51:29 UTC (rev 6569)
+++ complete.html 2011-09-23 00:14:46 UTC (rev 6570)
@@ -239,7 +239,7 @@
<header class=head id=head><p><a class=logo href=http://www.whatwg.org/><img alt=WHATWG height=101 src=/images/logo width=101></a></p>
<hgroup><h1>Web Applications 1.0</h1>
- <h2 class="no-num no-toc">Living Standard — Last Updated 22 September 2011</h2>
+ <h2 class="no-num no-toc">Living Standard — Last Updated 23 September 2011</h2>
</hgroup><dl><dt>Multiple-page version:</dt>
<dd><a href=http://www.whatwg.org/specs/web-apps/current-work/complete/>http://www.whatwg.org/specs/web-apps/current-work/complete/</a></dd>
<dt>One-page version:</dt>
@@ -969,9 +969,10 @@
<li><a href=#contenteditable><span class=secno>8.5.1 </span>Making document regions editable: The <code title=attr-contenteditable>contenteditable</code> content
attribute</a></li>
<li><a href=#making-entire-documents-editable:-the-designmode-idl-attribute><span class=secno>8.5.2 </span>Making entire documents editable: The <code title=dom-document-designMode>designMode</code> IDL attribute</a></li>
- <li><a href=#user-editing-actions><span class=secno>8.5.3 </span>User editing actions</a></li>
- <li><a href=#editing-apis><span class=secno>8.5.4 </span>Editing APIs</a></li>
- <li><a href=#spelling-and-grammar-checking><span class=secno>8.5.5 </span>Spelling and grammar checking</a></ol></li>
+ <li><a href=#best-practices-for-in-page-editors><span class=secno>8.5.3 </span>Best practices for in-page editors</a></li>
+ <li><a href=#user-editing-actions><span class=secno>8.5.4 </span>User editing actions</a></li>
+ <li><a href=#editing-apis><span class=secno>8.5.5 </span>Editing APIs</a></li>
+ <li><a href=#spelling-and-grammar-checking><span class=secno>8.5.6 </span>Spelling and grammar checking</a></ol></li>
<li><a href=#dnd><span class=secno>8.6 </span>Drag and drop</a>
<ol>
<li><a href=#introduction-9><span class=secno>8.6.1 </span>Introduction</a></li>
@@ -44676,9 +44677,9 @@
<p class=note>This requirement is a <a href=#willful-violation>willful violation</a>
of RFC 5322, which defines a syntax for e-mail addresses that is
simultaneously too strict (before the "@" character), too vague
- (after the "@" character), and too lax (allowing comments, white
- space characters, and quoted strings in manners unfamiliar to most
- users) to be of practical use here.</p>
+ (after the "@" character), and too lax (allowing comments,
+ whitespace characters, and quoted strings in manners unfamiliar to
+ most users) to be of practical use here.</p>
<p>A <dfn id=valid-e-mail-address-list>valid e-mail address list</dfn> is a <a href=#set-of-comma-separated-tokens>set of
comma-separated tokens</a>, where each token is itself a
@@ -54747,7 +54748,7 @@
<p class=example>For example, this could involve removing
characters that are not legal in file names, or trimming leading
- and trailing white space.</p>
+ and trailing whitespace.</p>
</li>
@@ -71761,10 +71762,48 @@
</div>
+ <h4 id=best-practices-for-in-page-editors><span class=secno>8.5.3 </span>Best practices for in-page editors</h4>
+ <p>Authors are encouraged to set the 'white-space' property on <a href=#editing-host title="editing host">editing hosts</a> and on markup that was
+ originally created through these editing mechanisms to the value
+ 'pre-wrap'. Default HTML whitespace handling is not well suited to
+ WYSIWYG editing, and line wrapping will not work correctly in some
+ corner cases if 'white-space' is left at its default value.</p>
+
+ <div class=example>
+
+ <p>As an example of problems that occur if the default 'normal'
+ value is used instead, consider the case of the user typing
+ "<kbd>yellow␣␣ball</kbd>", with two spaces (here
+ represented by "2423;") between the words. With the editing
+ rules in place for the default value of 'white-space' ('normal'),
+ the resulting markup will either consist of
+ "<samp>yellow ball</samp>" or
+ "<samp>yellow ball</samp>"; i.e., there will be a
+ non-breaking space between the two words in addition to the regular
+ space. This is necessary because the 'normal' value for
+ 'white-space' requires adjacent regular spaces to be collapsed
+ together.</p>
+
+ <p>In the former case, "<samp>yellow⍽</samp>" might wrap to
+ the next line ("⍽" being used here to represent a
+ non-breaking space) even though "<samp>yellow</samp>" alone might
+ fit at the end of the line; in the latter case,
+ "<samp>⍽ball</samp>", if wrapped to the start of the line,
+ would have visible indentation from the non-breaking space.</p>
+
+ <p>When 'white-space' is set to 'pre-wrap', however, the editing
+ rules will instead simply put two regular spaces between the words,
+ and should the two words be split at the end of a line, the spaces
+ would be neatly removed from the rendering.</p>
+
+ </div>
+
+
+
<div class=impl>
- <h4 id=user-editing-actions><span class=secno>8.5.3 </span>User editing actions</h4>
+ <h4 id=user-editing-actions><span class=secno>8.5.4 </span>User editing actions</h4>
<p class=XXX>This section will be removed shortly. What remains
here is simply what has not yet been merged into Aryeh's spec.</p>
@@ -71839,7 +71878,7 @@
</div>
- <h4 id=editing-apis><span class=secno>8.5.4 </span>Editing APIs</h4>
+ <h4 id=editing-apis><span class=secno>8.5.5 </span>Editing APIs</h4>
<p>The definition of the terms <dfn id=active-range>active range</dfn>, <dfn id=editing-host>editing
host</dfn>, and <dfn id=editable>editable</dfn>, the user interface requirements
@@ -71868,7 +71907,7 @@
- <h4 id=spelling-and-grammar-checking><span class=secno>8.5.5 </span>Spelling and grammar checking</h4>
+ <h4 id=spelling-and-grammar-checking><span class=secno>8.5.6 </span>Spelling and grammar checking</h4>
<div class=impl>
Modified: index
===================================================================
--- index 2011-09-22 23:51:29 UTC (rev 6569)
+++ index 2011-09-23 00:14:46 UTC (rev 6570)
@@ -243,7 +243,7 @@
<header class=head id=head><p><a class=logo href=http://www.whatwg.org/><img alt=WHATWG height=101 src=/images/logo width=101></a></p>
<hgroup><h1 class=allcaps>HTML</h1>
- <h2 class="no-num no-toc">Living Standard — Last Updated 22 September 2011</h2>
+ <h2 class="no-num no-toc">Living Standard — Last Updated 23 September 2011</h2>
</hgroup><dl><dt><strong>Web developer edition</strong></dt>
<dd><strong><a href=http://developers.whatwg.org/>http://developers.whatwg.org/</a></strong></dd>
<dt>Multiple-page version:</dt>
@@ -969,9 +969,10 @@
<li><a href=#contenteditable><span class=secno>8.5.1 </span>Making document regions editable: The <code title=attr-contenteditable>contenteditable</code> content
attribute</a></li>
<li><a href=#making-entire-documents-editable:-the-designmode-idl-attribute><span class=secno>8.5.2 </span>Making entire documents editable: The <code title=dom-document-designMode>designMode</code> IDL attribute</a></li>
- <li><a href=#user-editing-actions><span class=secno>8.5.3 </span>User editing actions</a></li>
- <li><a href=#editing-apis><span class=secno>8.5.4 </span>Editing APIs</a></li>
- <li><a href=#spelling-and-grammar-checking><span class=secno>8.5.5 </span>Spelling and grammar checking</a></ol></li>
+ <li><a href=#best-practices-for-in-page-editors><span class=secno>8.5.3 </span>Best practices for in-page editors</a></li>
+ <li><a href=#user-editing-actions><span class=secno>8.5.4 </span>User editing actions</a></li>
+ <li><a href=#editing-apis><span class=secno>8.5.5 </span>Editing APIs</a></li>
+ <li><a href=#spelling-and-grammar-checking><span class=secno>8.5.6 </span>Spelling and grammar checking</a></ol></li>
<li><a href=#dnd><span class=secno>8.6 </span>Drag and drop</a>
<ol>
<li><a href=#introduction-9><span class=secno>8.6.1 </span>Introduction</a></li>
@@ -44543,9 +44544,9 @@
<p class=note>This requirement is a <a href=#willful-violation>willful violation</a>
of RFC 5322, which defines a syntax for e-mail addresses that is
simultaneously too strict (before the "@" character), too vague
- (after the "@" character), and too lax (allowing comments, white
- space characters, and quoted strings in manners unfamiliar to most
- users) to be of practical use here.</p>
+ (after the "@" character), and too lax (allowing comments,
+ whitespace characters, and quoted strings in manners unfamiliar to
+ most users) to be of practical use here.</p>
<p>A <dfn id=valid-e-mail-address-list>valid e-mail address list</dfn> is a <a href=#set-of-comma-separated-tokens>set of
comma-separated tokens</a>, where each token is itself a
@@ -54614,7 +54615,7 @@
<p class=example>For example, this could involve removing
characters that are not legal in file names, or trimming leading
- and trailing white space.</p>
+ and trailing whitespace.</p>
</li>
@@ -71657,10 +71658,48 @@
</div>
+ <h4 id=best-practices-for-in-page-editors><span class=secno>8.5.3 </span>Best practices for in-page editors</h4>
+ <p>Authors are encouraged to set the 'white-space' property on <a href=#editing-host title="editing host">editing hosts</a> and on markup that was
+ originally created through these editing mechanisms to the value
+ 'pre-wrap'. Default HTML whitespace handling is not well suited to
+ WYSIWYG editing, and line wrapping will not work correctly in some
+ corner cases if 'white-space' is left at its default value.</p>
+
+ <div class=example>
+
+ <p>As an example of problems that occur if the default 'normal'
+ value is used instead, consider the case of the user typing
+ "<kbd>yellow␣␣ball</kbd>", with two spaces (here
+ represented by "2423;") between the words. With the editing
+ rules in place for the default value of 'white-space' ('normal'),
+ the resulting markup will either consist of
+ "<samp>yellow ball</samp>" or
+ "<samp>yellow ball</samp>"; i.e., there will be a
+ non-breaking space between the two words in addition to the regular
+ space. This is necessary because the 'normal' value for
+ 'white-space' requires adjacent regular spaces to be collapsed
+ together.</p>
+
+ <p>In the former case, "<samp>yellow⍽</samp>" might wrap to
+ the next line ("⍽" being used here to represent a
+ non-breaking space) even though "<samp>yellow</samp>" alone might
+ fit at the end of the line; in the latter case,
+ "<samp>⍽ball</samp>", if wrapped to the start of the line,
+ would have visible indentation from the non-breaking space.</p>
+
+ <p>When 'white-space' is set to 'pre-wrap', however, the editing
+ rules will instead simply put two regular spaces between the words,
+ and should the two words be split at the end of a line, the spaces
+ would be neatly removed from the rendering.</p>
+
+ </div>
+
+
+
<div class=impl>
- <h4 id=user-editing-actions><span class=secno>8.5.3 </span>User editing actions</h4>
+ <h4 id=user-editing-actions><span class=secno>8.5.4 </span>User editing actions</h4>
<p class=XXX>This section will be removed shortly. What remains
here is simply what has not yet been merged into Aryeh's spec.</p>
@@ -71735,7 +71774,7 @@
</div>
- <h4 id=editing-apis><span class=secno>8.5.4 </span>Editing APIs</h4>
+ <h4 id=editing-apis><span class=secno>8.5.5 </span>Editing APIs</h4>
<p>The definition of the terms <dfn id=active-range>active range</dfn>, <dfn id=editing-host>editing
host</dfn>, and <dfn id=editable>editable</dfn>, the user interface requirements
@@ -71764,7 +71803,7 @@
- <h4 id=spelling-and-grammar-checking><span class=secno>8.5.5 </span>Spelling and grammar checking</h4>
+ <h4 id=spelling-and-grammar-checking><span class=secno>8.5.6 </span>Spelling and grammar checking</h4>
<div class=impl>
Modified: source
===================================================================
--- source 2011-09-22 23:51:29 UTC (rev 6569)
+++ source 2011-09-23 00:14:46 UTC (rev 6570)
@@ -49876,9 +49876,9 @@
<p class="note">This requirement is a <span>willful violation</span>
of RFC 5322, which defines a syntax for e-mail addresses that is
simultaneously too strict (before the "@" character), too vague
- (after the "@" character), and too lax (allowing comments, white
- space characters, and quoted strings in manners unfamiliar to most
- users) to be of practical use here.</p>
+ (after the "@" character), and too lax (allowing comments,
+ whitespace characters, and quoted strings in manners unfamiliar to
+ most users) to be of practical use here.</p>
<p>A <dfn>valid e-mail address list</dfn> is a <span>set of
comma-separated tokens</span>, where each token is itself a
@@ -61674,7 +61674,7 @@
<p class="example">For example, this could involve removing
characters that are not legal in file names, or trimming leading
- and trailing white space.</p>
+ and trailing whitespace.</p>
</li>
@@ -81678,7 +81678,46 @@
</div>
+ <h4>Best practices for in-page editors</h4>
+ <p>Authors are encouraged to set the 'white-space' property on <span
+ title="editing host">editing hosts</span> and on markup that was
+ originally created through these editing mechanisms to the value
+ 'pre-wrap'. Default HTML whitespace handling is not well suited to
+ WYSIWYG editing, and line wrapping will not work correctly in some
+ corner cases if 'white-space' is left at its default value.</p>
+
+ <div class="example">
+
+ <p>As an example of problems that occur if the default 'normal'
+ value is used instead, consider the case of the user typing
+ "<kbd>yellow␣␣ball</kbd>", with two spaces (here
+ represented by "&#x;2423;") between the words. With the editing
+ rules in place for the default value of 'white-space' ('normal'),
+ the resulting markup will either consist of
+ "<samp>yellow ball</samp>" or
+ "<samp>yellow ball</samp>"; i.e., there will be a
+ non-breaking space between the two words in addition to the regular
+ space. This is necessary because the 'normal' value for
+ 'white-space' requires adjacent regular spaces to be collapsed
+ together.</p>
+
+ <p>In the former case, "<samp>yellow⍽</samp>" might wrap to
+ the next line ("⍽" being used here to represent a
+ non-breaking space) even though "<samp>yellow</samp>" alone might
+ fit at the end of the line; in the latter case,
+ "<samp>⍽ball</samp>", if wrapped to the start of the line,
+ would have visible indentation from the non-breaking space.</p>
+
+ <p>When 'white-space' is set to 'pre-wrap', however, the editing
+ rules will instead simply put two regular spaces between the words,
+ and should the two words be split at the end of a line, the spaces
+ would be neatly removed from the rendering.</p>
+
+ </div>
+
+
+
<div class="impl">
<h4>User editing actions</h4>
More information about the Commit-Watchers
mailing list