RE: [css-tables] repeating table headers and footers

> 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

Yes this is fine, I'm pushing up an issue page right now and yours in the only one that I've pulled from comments at the moment. That said, I'll reply below with what we discussed in person to your suggestions below for archiving.

> 
> > 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.

Francois and I will add a new section and test for this under table fragmentation.

> > 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.

We currently do **not** want to add any additional feature to the current specification. The reason for this is our first goal is to have a foundational specification that any UA can go and fix bugs against. At the point that we feel we have a stable table specification and this is on its way to CR, we'll consider features for L4.

> > 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?

We'll test this and spec the most interoperable behavior, and if there is none we'll spec the most sane behavior that is currently being shipped by a UA (to ease on web compat).

> > 2) Can we have a property to switch that off if authors so desire?
> > 3) How do we design that property?

Not in the current spec, see longer statement above.


> >
> > - Florian

Received on Sunday, 7 February 2016 07:10:10 UTC