[css-writing-modes-3] Remove newly-added bidi-induced fragmentation spec text from L3 (leave undefined) so as not to add new requirements for advancing to REC. Keep it in L4; updated changes sections accordingly.

Author: fantasai

css-writing-modes-3/Overview.bs

@@ -669,78 +669,9 @@ Reordering-induced Box Fragmentation</h4>
     bidirectional text can cause an <a>inline box</a> containing such text
     to be split and its fragments reordered within a line.
 
-<h5 id="bidi-fragmentation">
-Conditions of Reordering-induced Box Fragmentation</h5>
-
-  <p>
-    When bidi reordering would split apart an inline box
-    due to intervening content,
-    the inline box is considered to be broken into multiple <a>box fragments</a>.
-    [[CSS-BREAK-3]]
-    The box is considered to be thus <a>fragmented</a>
-    if it would be divided by intervening content on an infinitely long line,
-    even if line breaking happens to result in both <a>box fragments</a>
-    being placed adjacent to each other on the line.
-    In such cases, the nearest common ancestor of text in the two <a>box fragments</a>
-    (which determines certain aspects of text formatting
-    such as <a spec="css-text">tracking</a> and <a href="https://www.w3.org/TR/css-text/#text-justify-property">justification</a>
-    between the two <a>box fragments</a>, see [[CSS-TEXT-3]])
-    is considered to be the nearest common ancestor of the two <a>box fragments</a>,
-    not the <a>inline box</a> itself.
-    However, an <a>inline box</a> is not considered to be broken
-    into multiple <a>box fragments</a> due to bidi reordering
-    if no intervening content would force it to split.
-    (These rules maintain the integrity of an <a>inline box</a> where possible,
-    while keeping bidi-induced fragmentation stable
-    across variations in line-breaking.)
-    <!-- See https://github.com/w3c/csswg-drafts/issues/1509 -->
-
-  <div class="example">
-    In the following example, where lowercase letters represent LTR letters
-    and uppercase letters represent RTL letters,
-    bidi reordering causes the <code>&lt;em></code>’s <a>inline box</a>
-    to be divided into two <a>box fragments</a>
-    separated by text outside the <code>&lt;em</code>.
-
-    Source code (logical order):
-    <pre>&lt;p>here is &lt;em>some MIXED&lt;/em> TEXT.&lt;/p></pre>
-
-    Rendering (visual order) in a wide containing block, resulting in two inline box fragments separated by external content:
-    <pre>here is <em style="border: 1px solid; border-right: 1px dashed red">some </em>TXET <em style="border: 1px solid; border-left: 1px dashed red">DEXIM</em>.</pre>
-
-    Rendering (visual order) in a narrow containing block, resulting in two inline box fragments placed adjacent to each other:
-    <pre>
-      here is <em style="border: 1px solid; border-right: 1px dashed red">some </em><em style="border: 1px solid; border-left: 1px dashed red">DEXIM</em>
-      TXET.
-    </pre>
-  </div>
-
-  <div class="example">
-    By contrast, in this example,
-    where the mixed-direction phrase is kept together with an isolation,
-    only one fragment is generated--
-    the surrounding content will never split the <code>&lt;em></code>’s <a>inline box</a>
-    even inside an infinitely-long containing block:
-
-    Source code (logical order):
-    <pre>&lt;p>here is &lt;em dir=rtl>some MIXED&lt;/em> TEXT.&lt;/p></pre>
-
-    Rendering (visual order) in a wide containing block, resulting in one fragment:
-    <pre>here is <em style="border: 1px solid; ">some DEXIM</em> TXET.</pre>
-
-    Rendering (visual order) in a narrow containing block, resulting in one fragment:
-    <pre>
-      here is <em style="border: 1px solid; ">some DEXIM</em>
-      TXET.
-    </pre>
-  </div>
-
-<h5 id="bidi-fragment-boxes">
-Box Model of Reordering-induced Box Fragments</h5>
-
 <!-- CSS2.1 8.6 -->
   <p>For each line box, UAs must take the fragments of each inline box
-    and assign the margins, borders and padding in visual order (not logical order).
+    and assign the margins, borders, and padding in visual order (not logical order).
     The <a>start</a>-most fragment on the first line box in which the box appears
     has the <a>start</a> edge's margin, border, and padding;
     and the end-most fragment on the last line box in which the box appears
@@ -2561,8 +2492,6 @@ Privacy and Security Considerations {#priv-sec}
     <li>Fixed the fallback “available space” for orthogonal flows
         to handle 'max-height' (and 'min-height') which it forgot to consider.
         (<a href="https://github.com/w3c/csswg-drafts/issues/2239">Issue 2239</a>)
-    <li>Clarified the <a href="#bidi-fragmentation">conditions for bidi reordering-induced fragmentation</a>.
-        (<a href="https://github.com/w3c/csswg-drafts/issues/1509">Issue 1509</>)
   </ul>
 
   <h3 class="no-num" id="changes-201512">

css-writing-modes-4/Overview.bs

@@ -2802,9 +2802,11 @@ New in Level 4</h3>
 	The difference from the <a href="https://www.w3.org/TR/css-writing-modes-3/">current CSS Writing Modes Level 3</a> is the set of features that were deferred from Level 3 due to later implementation uptake:
 
 	<ul>
-		<li>The ''sideways-lr'' and ''sideways-rl'' values of 'writing-mode'
-		<li>The ''digits'' value of 'text-combine-upright'.
-		<li>The <a href="#auto-multicol">automatic multi-column behavior</a> of orthogonal flows.
+		<li>Re-introduced ''sideways-lr'' and ''sideways-rl'' values of 'writing-mode'
+		<li>Re-introduced the ''digits'' value of 'text-combine-upright'.
+		<li>Re-introduced  <a href="#auto-multicol">automatic multi-column behavior</a> of orthogonal flows.
+		<li>Clarified the <a href="#bidi-fragmentation">conditions for bidi reordering-induced fragmentation</a>.
+		(<a href="https://github.com/w3c/csswg-drafts/issues/1509">Issue 1509</>)
 	</ul>
 
 <h2 class="no-num" id="acknowledgements">