RE: [css-tables] Dropping repeated headers/footers when one content row doesn't fit

That was the intent of the spec, since we have to make the assumption fragmentainers might not all share the same size.

Trying to define what happens with fragementation without writing down an algorithm was not easy, so maybe we should actually try to define an algorithm in the spec.

What do you think of this proposal?


When you need to fragment a table in a fragmentainer, if you must (or may + want to) repeat headers in this fragmentation chain, start this algorithm:


  1.  Fragment the rows of the table in the first fragmentainer. If you reach the end of all table rows without needing to break to another fragmentainer, no further action is needed and you can continue fragmentation in that fragmentainer as usual. Otherwise, continue to the next step.
  2.  If the last row that did partially fit in the fragmentainer was a thead row (and the table was not the first element to be fragmented in the current fragmentainer), break to the next fragmentainer before the table and restart this algorithm in the new fragmentainer.

If that happens and the table was the first element in the current fragmentainer, continue fragmenting the remaining table rows normally in the next fragmentainers and abort these steps (repeated headers and footers are cancelled). Otherwise, continue to the next step.
  3.  If the last row that did partially fit in the fragmentainer was a tbody or tfoot row restart fragmentation in that fragmentainer with the tfoot being repeated at its bottom and therefore a reduced vertical space. If that doesn’t leave enough vertical space in the fragmentainer to contain at least partially one tbody row (or if the last row that did partially fit in the fragmentainer was a tfoot row), return to the previous fragmentation without the repeated tfoot; otherwise keep this new fragmentation. In both cases, continue to the next step.
  4.  If the last row that did partially fit in the fragmentainer was a tfoot row, continue fragmenting the remaining tfoot rows normally in the next fragmentainers and abort these steps. Otherwise, continue to the next step.
  5.  Break to the next fragmentainer. In the subsequent fragmentainer, start fragmentation with a repeated header at the top of the fragmentainer and therefore a reduced vertical space (if that space would become zero or negative, don’t repeat the header and continue this algorithm).
  6.  Fragment the remaining rows of the table in the fragmentainer. If you reach the end of all table rows without needing to break to another fragmentainer, no further action is needed and you can continue fragmentation in that fragmentainer as usual. Otherwise, continue this algorithm from step 3.

This clarifies that if you can’t have repeated header you shouldn’t get repeated footers either.

I guess implementations might decide to invert the 6-to-3 move and always try to add the repeated footer and restart fragmentation only if you end up exhausting all tbody rows. This wouldn’t change the visible result so if you want to do this instead this is totally fine.



From: Robert Hogan [mailto:robhogan@gmail.com]
Sent: Tuesday, December 20, 2016 2:19 AM
To: www-style list <www-style@w3.org<mailto:www-style@w3.org>>
Subject: [css-tables] Dropping repeated headers/footers when one content row doesn't fit

Hi there,

The text in https://drafts.csswg.org/css-tables-3/#repeated-headers says that we should drop the repeated footers and headers if it would prevent a content-row fitting on the page.

My implementation in Blink is pretty naive - and just applies this rule to the first page: if at least one content-row doesn't fit on the page after the header group it drops the repeated headers. It will do the same once we add footers.

Am I right in thinking that intention of the spec is to apply the rule on a page-by-page basis? So if we have a content-row on a page that needs to drop the footer in order to fit we should just drop the footer for that page? And likewise if it also needs to drop the header?

In the case where a row straddles more than one page I'm planning to fix a bug in Blink which handles this situation badly by repeating the header on the pages the content-row straddles but just push the content of the cell below it. Firefox does it this way currently and it looks like the common sense rendering to me.

Thanks,
Rob


From: Robert Hogan [mailto:robhogan@gmail.com]
Sent: Tuesday, December 20, 2016 2:19 AM
To: www-style list <www-style@w3.org>
Subject: [css-tables] Dropping repeated headers/footers when one content row doesn't fit

Hi there,

The text in https://drafts.csswg.org/css-tables-3/#repeated-headers says that we should drop the repeated footers and headers if it would prevent a content-row fitting on the page.

My implementation in Blink is pretty naive - and just applies this rule to the first page: if at least one content-row doesn't fit on the page after the header group it drops the repeated headers. It will do the same once we add footers.

Am I right in thinking that intention of the spec is to apply the rule on a page-by-page basis? So if we have a content-row on a page that needs to drop the footer in order to fit we should just drop the footer for that page? And likewise if it also needs to drop the header?

In the case where a row straddles more than one page I'm planning to fix a bug in Blink which handles this situation badly by repeating the header on the pages the content-row straddles but just push the content of the cell below it. Firefox does it this way currently and it looks like the common sense rendering to me.

Thanks,
Rob