Update white space processing rules by syncing against changes to CSS2.1. Write a better explanation of the purpose of white space processing rules and further disentangle it from line breaking.

Author: fantasai

css3-text/Overview.src.html

@@ -464,33 +464,45 @@ <h3 id="partial-impl"><span class="secno">2.1.</span> Partial and Experimental I
 <h2 id="white-space-processing"><span class="secno">3.</span>
   White Space Processing</h2>
 
+  <p>The source text of a document often contains formatting that
+    is not relevant to the final rendering: for example, breaking
+    the source into segments (lines) for ease of editing or adding
+    white space characters such as tabs and spaces to indent the
+    source code. CSS white space processing allows the author to
+    control interpretation of such formatting: to preserve or
+    collapse it away when rendering the document.
+
+  <p>Segments in the document source can be separated by a carriage
+    return (U+000D), a linefeed (U+000A) or both (U+000D U+000A),
+    or by some other mechanism that identifies the beginning
+    and end of document segments, such as the SGML RECORD-START
+    and RECORD-END tokens.
+    If no segmentation rules are specified for the document language,
+    each line feed (U+000A), carriage return (U+000D) and CRLF sequence
+    (U+000D U+000A) in the text is considered a segment break. (This
+    default rule also applies to generated content.)
+    In CSS, each such segment break is treated as a single line feed
+    character (U+000A).
+
   <p>White space processing in CSS interprets white space characters
     for rendering: it has no effect on the underlying document data.
-    In the context of CSS, the document white space set is defined to be
-    any space characters (Unicode value U+0020), tab characters (U+0009),
-    or line break characters (defined by the document format: typically
-    line feed, U+000A). Control characters besides the white space
-    characters and the bidi formatting characters (U+202x) are treated as
-    normal characters and rendered according to the same rules.
-
-  <p>The document parser must normalize line break character sequences
-    according to its own format rules before CSS processing takes effect.
-    However, in generated content strings the line feed character (U+000A)
-    and only the line feed character is considered a line break sequence.
-    For CSS white space processing all line breaks must be normalized to a
-    single character representation&#8212;usually the line feed character
-    (U+000A)&#8212;here called a "line break". This way, all recognized
-    line breaks are treated the same and style rules behave consistently
-    across systems.</p>
+    In the context of CSS, the document white space set is defined
+    to be any space characters (Unicode value U+0020), tab characters
+    (U+0009), and line feeds (U+000A).
 
   <p class="note">Note that the document parser may have not only normalized
-    line break characters, but also collapsed other space characters or
+    segment breaks, but also collapsed other space characters or
     otherwise processed white space according to markup rules. Because CSS
     processing occurs <em>after</em> the parsing stage, it is not possible
     to restore these characters for styling. Therefore, some of the
     behavior specified below can be affected by these limitations and
     may be user agent dependent.</p>
 
+  <p>Control characters other than U+0009 (tab), U+000A (line feed),
+    U+0020 (space), and U+202x (bidi formatting characters) are treated
+    as characters to render in the same way as any normal character.
+    <span class="issue">Copied from CSS2.1 but this has got to be wrong.</span>
+
   <h3 id="white-space-collapsing"><span class="secno">3.1.</span>
     White Space Collapsing: the 'white-space-collapsing' property</h3>
 
@@ -548,10 +560,10 @@ <h3 id="white-space-collapsing"><span class="secno">3.1.</span>
         cases</a>, no character).</dd>
       <dt><dfn title="white-space-collapsing:preserve"><code>preserve</code></dfn></dt>
       <dd>This value prevents user agents from collapsing sequences
-      of white space. Line breaks are preserved.</dd>
+      of white space. Segment breaks are preserved as forced line breaks.</dd>
       <dt><dfn title="white-space-collapsing:preserve-breaks"><code>preserve-breaks</code></dfn></dt>
       <dd>This value collapses white space as for 'collapse', but preserves
-        line breaks.</dd>
+        segment breaks as forced line breaks.</dd>
       <dt><dfn title="white-space-collapsing:discard"><code>discard</code></dfn></dt>
       <dd>This value directs user agents to "discard" all white space in the
         element.
@@ -566,9 +578,6 @@ <h3 id="white-space-collapsing"><span class="secno">3.1.</span>
   <h3 id="white-space-rules"><span class="secno">3.2.</span>
     The White Space Processing Rules</h3>
 
-    <p>Any text that is directly contained inside a block (not inside
-      an inline) is treated as being inside an anonymous inline element.</p>
-
     <p>For each inline (including anonymous inlines), white space
       characters are handled as follows, ignoring bidi formatting
       characters as if they were not there:</p>
@@ -579,19 +588,21 @@ <h3 id="white-space-rules"><span class="secno">3.2.</span>
       are considered <dfn>collapsible</dfn> and are processed by
       performing the following steps:</p>
       <ol>
-        <li>All non-line-break white space characters immediately following
-          a line break character are removed. (This has the effect of
-          discarding all white space at the start of a line but preserving
-          a trailing space if one exists at the end.)</li>
+        <li>All spaces and tabs immediately following a line feed character
+          are removed. (This has the effect of discarding all white space
+          at the start of a line but preserving a trailing space if one
+          exists at the end.)</li>
         <li>If <span class="property">'white-space-collapsing'</span> is not
-          'preserve-breaks', line break characters are transformed for
+          'preserve-breaks', line feed characters are transformed for
           rendering according to the <a href="#line-break-transform">line
           break transformation rules</a>.
         </li>
         <li>Every tab (U+0009) is converted to a space (U+0020)</li>
-        <li>Any space (U+0020) following another space (U+0020)&mdash;even
-          a space before the inline, if that space is also collapsible&mdash;is
-          removed.</li>
+        <li>Any space (U+0020) following another collabsible space
+          (U+0020)&mdash;even a space before the inline&mdash;is removed.
+          However, if removing this space would eliminate a line breaking
+          opportunity in the text, that opportunity is still considered
+          to exist.</li>
       </ol>
     </li>
     <li><p>If <span class="property">'white-space-collapsing'</span> is set to
@@ -612,13 +623,13 @@ <h3 id="white-space-rules"><span class="secno">3.2.</span>
     <ol>
       <li>A sequence of collapsible spaces (U+0020) at the beginning of a
         line is removed.</li>
-      <li>A tab (U+0009) is rendered as a horizontal shift that lines up
+      <li>Each tab (U+0009) is rendered as a horizontal shift that lines up
         the start edge of the next glyph with the next tab stop.
         Tab stops occur at points that are multiples of 8 times the width
         of a space (U+0020) rendered in the block's font from the block's
         starting content edge.</li>
-      <li>A sequence of collapsible spaces (U+0020) or ideographic spaces
-        (U+3000) at the end of a line is removed.</li>
+      <li>A sequence of collapsible spaces (U+0020) at the end of a line
+        is removed.</li>
       <li>If spaces (U+0020) or tabs (U+0009) at the end of a line are
         non-collapsible but have 'text-wrap' set to 'normal' or 'suppress'
         the UA may visually collapse them.
@@ -665,37 +676,43 @@ <h4 id="egbidiwscollapse"><span class="secno">3.2.1.</span>
     <h4 id="line-break-transform"><span class="secno">3.2.2.</span>
       Line Break Transformation Rules</h4>
 
-      <p>When line breaks are <a href="#collapse">collapsible</a>, they are
+      <p>When line feeds are <a href="#collapse">collapsible</a>, they are
         either transformed into a space (U+0020) or removed depending on the
         script context before and after the line break.</p>
 
       <p>The script context is determined by the Unicode-given script value
-        [UAX24] of the first character that side of the line break. However,
+        [UAX24] of the first character that side of the line feed. However,
         characters such as punctuation that belong to the COMMON and INHERITED
         scripts are ignored in this check; the next character is examined
         instead. The UA must not examine characters outside the block and may
         limit its examination to as few as four characters on each side of the
-        line break. If the check fails to find an acceptable script value
+        line feed. If the check fails to find an acceptable script value
         (i.e. it has hit the check limits), then the script context is neutral.</p>
 
+      <p class="note">Note that the white space processing rules have already
+        removed any tabs and spaces after the line feed before these checks
+        take place.</p>
+
       <ul>
         <li>If the character immediately before or immediately after the line
-          break is the zero width space character (U+200B), then the line break
+          feed is the zero width space character (U+200B), then the line feed
           is removed.
-        <li>Otherwise, if the script context on one side of the line break is
+        <li>Otherwise, if the script context on one side of the line feed is
           Han, Yi, Hiragana, or Katakana and the context on the other side is
-          Han, Yi, Hiragana, Katakana, or neutral, then the line break is removed.
-          <p class="issue">IE removes line breaks not only between two Hiragana but also Hiragana and fullwidth alphabets.
-            Firefox, Opera, and Safari does not remove line breaks even between two Hiragana.
-            So current rule written here will break everyone.</p>
+          Han, Yi, Hiragana, Katakana, or neutral, then the line feed is removed.
+          <p class="issue">IE removes line feed not only between two Hiragana
+            but also Hiragana and fullwidth alphabets.
+            Firefox, Opera, and Safari does not remove line breaks even between
+            two Hiragana.
+            Should fullwidth Latin be considered in this rule?</p>
         <li>Otherwise, if ''text-autospace'' property is set to add extra spaces
-          for the combination of the character before the line break and after,
+          for the combination of the character before the line feed and after,
           then the line break is removed.
           <p class="issue">Any feedback on this behavior is appreciated.
             Now that we have text-autospace property, it makes sense to favor it than inserting spaces.
             However, we also want to preserve backward compatibility as much as possible.
-            That is the reason why the line break should be removed only if text-autospace inserts spaces instead.</p></li>
-        <li>Otherwise, the line break is converted to a space (U+0020).
+            That is the reason why the line feed should be removed only if text-autospace inserts spaces instead.</p></li>
+        <li>Otherwise, the line feed is converted to a space (U+0020).
       </ul>
 
       <p class="issue">Comments on how well this would work in practice would
@@ -1075,8 +1092,8 @@ <h3 id="text-wrap"><span class="secno">5.1.</span>
       for the WJ, ZW, and GL line-breaking classes in
       [<a href="#UAX14">UAX14</a>] must be honored.
     <dt><dfn title="text-wrap:none"><code>none</code></dfn></dt>
-    <dd>Lines may not break except at forced break points; text that
-      does not fit within the block box overflows it.</dd>
+    <dd>Lines may not break; text that does not fit within the block container
+      overflows it.</dd>
     <dt><dfn title="text-wrap:unrestricted"><code>unrestricted</code></dfn></dt>
     <dd>Lines may break between any two grapheme clusters. Line-breaking
       restrictions have no effect and hyphenation does not take place.
@@ -1090,7 +1107,8 @@ <h3 id="text-wrap"><span class="secno">5.1.</span>
       'normal'.
     </dl>
 
-    <p>For all values, line-breaking behavior defined for the BK, CR, LF, CM
+    <p>Regardless of the 'text-wrap' value, lines always break at forced breaks:
+     for all values, line-breaking behavior defined for the BK, CR, LF, CM
      NL, and SG line breaking classes in [<a href="#UAX14-norm">UAX14</a>] must
      be honored.</p>