[css-writing-modes] Clarify when bidi induces fragmentation of an inline box, and what the nearest common ancestor of the two fragments is (for the purpose of finding spacing rules etc.). Fixes #1509.

Author: fantasai

css-writing-modes-3/Overview.bs

@@ -664,17 +664,83 @@ Paragraph Breaks Within Embeddings and Isolates</h4>
 <h4 id="bidi-box-model">
 Reordering-induced Box Fragmentation</h4>
 
-  <p>Since bidi reordering can split apart and reorder text that is
-    logically contiguous, bidirectional text can cause an inline box
-    to be split and reordered within a line.
+  <p>Since bidi reordering can split apart and reorder text
+    that is logically contiguous,
+    bidirectional text can cause an <a>inline box</a> containing such text
+    to be split and its fragments reordered within a line.
 
-  <p class="note">Note that in order to be able to flow inline boxes in a
-    uniform direction (either entirely left-to-right or entirely
-    right-to-left), anonymous inline boxes may have to be created.</p>
+<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 render 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

css-writing-modes-4/Overview.bs

@@ -665,17 +665,83 @@ Paragraph Breaks Within Embeddings and Isolates</h4>
 <h4 id="bidi-box-model">
 Reordering-induced Box Fragmentation</h4>
 
-  <p>Since bidi reordering can split apart and reorder text that is
-    logically contiguous, bidirectional text can cause an inline box
-    to be split and reordered within a line.
+  <p>Since bidi reordering can split apart and reorder text
+    that is logically contiguous,
+    bidirectional text can cause an <a>inline box</a> containing such text
+    to be split and its fragments reordered within a line.
 
-  <p class="note">Note that in order to be able to flow inline boxes in a
-    uniform direction (either entirely left-to-right or entirely
-    right-to-left), anonymous inline boxes may have to be created.</p>
+<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 render 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
@@ -696,7 +762,7 @@ Reordering-induced Box Fragmentation</h4>
     <p>Analogous rules hold for vertical writing modes.</p>
 
   <p class="note">The 'box-decoration-break' property can override this behavior
-  to draw box decorations on both sides of each fragment. [[!CSS3-BREAK]]
+  to draw box decorations on both sides of each fragment. [[!CSS-BREAK-3]]
 
 <h2 id="vertical-modes">
 Vertical Writing Modes</h2>