- From: Florian Rivoal <florian@rivoal.net>
- Date: Thu, 4 Feb 2016 20:11:32 +0900
- To: CSS public list <www-style@w3.org>, Greg Whitworth <gwhit@microsoft.com>
Hi Greg,
Does the mail I am replying to count as filing the issue of repeated table headers / footers against your new table spec, or do you want me to file it again separately?
- Florian
> On Jan 20, 2016, at 22:21, Florian Rivoal <florian@rivoal.net> wrote:
>
> When a table is fragmented over several fragmentainers (pages, columns...) should table headers and footers be repeated?
>
> CSS2.1 is the only spec I know of to speak about this[1], and it doesn't actually decide:
>
>> Print user agents may repeat header rows on each page spanned by a table.
>
>> Print user agents may repeat footer rows on each page spanned by a table.
>
> First, I don't think we behavior should depend on categories of UAs (print vs non print).
>
> Second, this is not clear whether this should also apply to fragmentainers other than pages, introduced after CSS2.1.
>
> And last, I am not too happy about this being up to the UA. If anyone, it feels like something that should be up to the author.
>
> As far as I can tell, today:
> * Firefox, IE, and many print oriented formatters do repeat the headers/footers on page breaks
> * Webkit, Blink, and Vivliostyle don't (but we're considering switching).
> * Some print formatters also repeat on column breaks.
>
> As browsers are inconsistent with eachother, I doubt we have a web compat problem. Since repeating table headers and footers on a fragmentation break is generally a useful thing, I suggest we make a normative requirement and say that UAs must repeat header/footer rows when a table spans a break.
>
> To make sure layout does make progress even if fragmentainers are too small, we should probably also add an exception allowing header rows (resp. footer rows) to be skipped in the non first (resp. non last) fragmentainers if there isn't enough space for normal rows otherwise.
>
> Finally, since authors may sometimes want the other way around, it would make sense to have a property to turn this off. We could model it after XSL[2][3]:
> table-omit-footer-at-break: true | false
> table-omit-header-at-break: true | false
> Initial: false
> Inherited: no
>
> Maybe renaming the values to do better than true and false:
>
> table-omit-*-at-break: always | avoid
>
> And maybe extending it for various kinds of breaks:
>
> table-omit-*-at-break: always | [ page || column || region ] | avoid
>
> Or maybe if we don't like double negatives ("avoid omitting" isn't great), do something like that:
>
> table-repeat-*-at-break: repeat | no-repeat
> table-repeat-*-at-break: repeat [ page || column || region ]? | no-repeat
>
> Or some other bikesheding.
>
> Yet another alternative would be to have one property instead of two, and rely on selectors to select headers or footers.
>
> And we could possibly make that single property apply to regular table row groups in addition to table header groups and table footer groups, and have the initial value be auto, which computes to repeat on header and footer groups, and to no-repeat on regular table row groups.
>
> Or some other variation.
>
> Summary:
>
> 1) Can we agree table headers and footers must be repeated by default when the table spans a fragmentation break?
>
> 2) Can we have a property to switch that off if authors so desire?
>
> 3) How do we design that property?
>
> - Florian
>
> [1] https://www.w3.org/TR/CSS21/tables.html
> [2] https://www.w3.org/TR/xsl/#table-omit-header-at-break
> [3] https://www.w3.org/TR/xsl/#table-omit-footer-at-break
>
>
Received on Thursday, 4 February 2016 15:32:17 UTC