[css-break] table orphans and widows

[frivoal]

https://drafts.csswg.org/css-break/#widows-orphans

The orphans and widows properties work fine for textual content, but the same concept is needed for tables, so that you can ask for a minimum number of table rows that must be left in a fragment before a fragmentation break, or that must be left in a fragment after a break.

We could either set up a new pair of properties (table-widows / table-orphans), or simply decide that widows and orphans apply to tables as well.

The later seems preferable, since if we had both pair of properties, the elements they would apply to would be mutually exclusive. The only downside is that it is not entirely clear if inheritance from the content surrounding the table to the table, and from the table to the table content makes a whole lot of sense.

That could be solved by having widows and orphans take multiple value, the first one applying to lines, the second optional one to table rows and defaulting to the same as the first one if omitted. But that may be overkill.

[Crissov]

Can table columns ever be affected, i.e. when a table spans multiple pages (or “fragmentainers”) horizontally?

[frivoal]

@Crissov I'd say no, as this makes most sense to me in terms of block axis fragmentation, but then again, table fragmentation in mixed writing modes (which is what you'd need to have a table that is fragmented in its inline direction) is a mystery to me.

[gregwhitworth]

Before digging in too deeply on this, why is this needed? Is this a common pattern that authors are having to fight against, requesting of UAs, etc?

Since tables currently focuses on fragmenting on the row, I'd doubt that writing modes which reside inside of the rows will have much affect on how we're fragmenting, but I haven't done much investigation here though - so I could be wrong and have been wrong numerous times before when investigating table issues.

Based on your answer to the use case question above, I'd rather shore up the holes in our spec (if any, we already specified more than what was currently specified) so that this will leave the Break Editors free to define what they think is best for the most common use cases in this space. Because, I really don't think this is table specific, you'll have this same issue with Grid. I've filed a bug on us to look into writing modes, and please let us know if there are any other fragmentation issues you feel aren't specified and we'll investigate them accordingly: #669

[frivoal]

I don't know of the use case for mixed writing modes and table fragmentation (although I am sure that with a bit of digging, we could find something).

Putting that aside, for table row orphans/widows, I've run into the requirement into documents with dense data table, and it was judged bad to have for example 12 rows of data on one page/column and 1 row on the next, and we're rather have 11/2 or 10/3.

I agree that there is a good chance that there is an analogue with grids, so it is worth considering. At the same time, a table row is often a single line of text, and that's in these cases that the property would be most desirable. I don't think that's nearly as frequent with Grid, but I could be wrong.

[frivoal]

@jensimmons, as the resident grid/design expert, do you think the concept of widow/orphan on grid rows would be useful?

[atanassov]

Moving the issue to L4. This is a rather advanced feature requirement that shouldn't hold L3 from moving forward to REC.

[fantasai]

Fwiw, it definitely needs to be a separate property. widows and orphans are inherited. Maybe row-widows and row-orphans.

[kinkoazc]

This could help when printing a dynamically generated table, in case there should be at least 1 data row together with a footer row(non-repeating footer), on the last printed page(think invoices). Let's say each printed page can have a maximum of n data rows(non-multiline, to simplify the example).
An ideal layout would look something like the following(as opposed to the footer row being left alone on the last page):

Printed page 1
-------------
<thead>[abc]</thead>
<tbody>[n data rows]</tbody>
-------------

Printed page 2
-------------
<thead>[abc]</thead>
<tbody>[n-1 data rows(that one-and last- data row should flow to the last printed page)]</tbody>
-------------   

Printed page 3
-------------
<thead>[abc]</thead>
<tbody>
  <tr><td>[1 data row(left from printed page 2)]</td></tr>
  <tr><td>[simulated footer here, preceded/accompanied by at least 1 data row]</td></tr>
</tbody>
------------- 

[Parakoos]

Yes, this is needed. It is bad form to have a page break and then a single table row. It would look much better to have 2 or 3 rows on the new table (if table has many rows) or move the entire table to a new page (if it has few rows)