[css-tables] Updated fragmentation section

Author: FremyCompany

css-tables-3/Overview.bs

@@ -2469,18 +2469,19 @@ spec:css22; type:property; text:display
 
 		When fragmenting a table, user agents must attempt
 			to preserve the table rows unfragmented
-			if their height is at least twice smaller than the table width.
+			if the cells spanning the row do not span any subsequent row, and
+			their height is at least twice smaller than both the fragmentainer height and width.
 		Other rows are said <dfn id="freely-fragmentable">freely fragmentable</dfn>.
 
 		When a table doesn't fit entirely in a fragmentainer,
+			at least one row did fit entirely in the fragmentainer,
 			and the first row that does not fit in the fragmentainer is not <a>freely fragmentable</a>.
 			the user agent has to insert some vertical gap
 			between the rows located before and at the overflow point
 			such that the two rows end up separated in sibling fragmentainers.
-		Cells spanning across those two rows are
-			divided into two fragments (one in each fragmentainer),
-			whose height is kept equal to the rows they span in each of these fragments, and
-			their content is fragmented among those two fragments, in parallel.
+		If the fragmentation requires repeating headers and footers, and the footer is repeated,
+			then the footer must come directly after the last row in the fragmentainer
+			and the vertical gap must be inserted after the repeated footer.
 
 		<figure>
 			<img src="./images/CSS-Tables-Fragmentation-1.svg" style="width:100%; max-width: 500px;" />
@@ -2489,10 +2490,10 @@ spec:css22; type:property; text:display
 
 		When there is no row fitting entirely in the current fragmentainer
 		or when the first row that does not fit in the fragmentainer is <a>freely fragmentable</a>,
-			user agents must split each cell of the row in two fragments (one in each fragmentainer)
-			so that all fragments in the same fragmentainer continue to share the same height.
-		Then, the user agent must fragment the content of each cell
-			among its two fragments, in parallel.
+			user agents must attribute all the remaining height in the fragmentainer to the cells
+			of that row, and fit as much content as it can in each of the cells independently,
+			then break to the next fragment and start the content of each cell where it was stopped
+			in its previous fragment (top borders must not be repainted in continuation fragments).
 
 		<figure>
 			<img src="./images/CSS-Tables-Fragmentation-2.svg" style="width:100%; max-width: 500px;" />
@@ -2501,21 +2502,30 @@ spec:css22; type:property; text:display
 
 		When 'break-before' or 'break-after' is applied
 		to a <a>table-row-grouping</a> or a <a>table-row</a> box,
-			the user agent has to insert some horizontal gap
+			the user agent has to insert some vertical gap
 			between the rows located before and after the breaking point
 			such that the two rows end up separated in sibling fragmentainers
 			as required by the property value.
+		If the fragmentation requires repeating headers and footers, and the footer is repeated,
+			then the footer must come directly after the last row in the fragmentainer
+			and the vertical gap must be inserted after the repeated footer.
 
 	<!--——————————————————————————————————————————————————————————————————————————-->
 	<h3 id="repeated-headers">Repeating headers across pages</h3>
 
 		When rendering the document into a paged media,
-			user agents must try to repeat
+			user agents must repeat
 				<a href="#table-header-group">header rows</a> and
 				<a href="#table-footer-group">footer rows</a>
-			on each page spanned by a table
-			where at least one header row or body row
-			was considered to be a <a>content row</a>.
+			on each page spanned by a table 
+			if the page is the table's fragmentainer,
+			if the header/footer has avoid 'break-inside' applied to it,
+			if the height required to do so is inferior to
+				two quarters of the page height
+				(up to one quarter for header rows, and
+				up to one quarter for footer rows), and
+			if that doesn't cause a row to be displayed twice
+				on that page.
 
 		When the header rows are being repeated, user agents must
 			leave room and if needed render the table top border.
@@ -2526,28 +2536,9 @@ spec:css22; type:property; text:display
 			<figcaption>Expected rendering of table with headers and footers fragmented across two pages</figcaption>
 		</figure>
 
-		When doing so doesn't leave enough space to insert at least one <a>content row</a>,
-			users agents must drop the footer rows which are not content rows (possibly all of them).
-
-		When doing so still doesn't leave enough space to insert at least one <a>content row</a>,
-			users agents must drop the header rows which are not content rows (possibly all of them).
-
-
-		In a given fragmentainer, a table row is considered a <dfn>content row candidate</dfn> if
-			it hasn't been included yet in a preceding fragmentainer where it was considered a content row
-			(if no preceding fragmentainer exists, all table rows are considered content row candidates);
-
-		In a given fragmentainer, a table row is considered a <dfn>content row</dfn> if it is in the set of
-			all <a>content row candidate</a>s from the table header, if any;
-			otherwise, all <a>content row candidate</a>s from the table bodies, if any;
-			otherwise, all <a>content row candidate</a>s from the table footer, if any.
-
-		User agents may consider all header rows and footer rows
-			to form an unfragmentable block, to enable rendering the headers and footers the same way on each page.
-
 		<p class="advisement">
-			User agents may decide to extend this behavior to every fragmentation context,
-				and not just to the main document's paging fragmentation context.
+			User agents may decide to extend this behavior to more fragmentation contexts,
+				for instance repeat headers/rows across columns in addition to pages.
 			User-agents that are rendering static documents are more likely to adopt this behavior,
 				though this is not required per spec.
 
@@ -2833,6 +2824,7 @@ Using CSS Tables does not incur any privacy risk to mitigate.
 	col      { display: table-column }
 	caption  { display: table-caption }
 	table, thead, tbody, tfoot, tr, td, th, colgroup, col, caption { box-sizing: border-box; }
+	thead, tfoot { break-inside: avoid }
 
 <!--
 	Non-border built-ins