W3C home > Mailing lists > Public > www-style@w3.org > February 2016

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

From: Florian Rivoal <florian@rivoal.net>
Date: Tue, 23 Feb 2016 10:26:09 +0100
Cc: Greg Whitworth <gwhit@microsoft.com>, CSS public list <www-style@w3.org>
Message-Id: <C9DD3647-4C21-4B67-94E4-F391E53D2D29@rivoal.net>
To: Francois Remy <frremy@microsoft.com>

> On Feb 23, 2016, at 03:00, Francois Remy <frremy@microsoft.com> wrote:
> 
>>> From what I have seen, browsers do not repeat headers/footers in
>>> multi-columns.
>>> http://codepen.io/FremyCompany/pen/YwbOMM
>> 
>> 
>> For multicol, as far as I can tell:
>> - IE+Edge / Chrome / Safari don't repeat
>> - Print formatters do repeat (Vivliostyle doesn't as of now, but we're planning
>> to, unless this discussion convinces us it's a bad idea).
>> - Firefox doesn't count, since it doesn't fragment tables across columns at all.
>> 
>> CSS Regions don't have enough implementations to be worth looking at what
>> "everybody" does when fragmenting tables there.
>> 
>> Despite the current lack of browser support for repeating table
>> headers/footers in multicol, I'd argue the spec still should ask for repetition
>> everywhere:
>> - I don't think the distinction between different types of fragmentainers is
>> justified
>> - Multicol usage on the web is still low enough that I don't expect compat
>> problems
>> - Multicol in paged media is used more often, and UAs focused on paged
>> media do repeat.
>> - Minimizing the difference between "CSS for print" and "CSS for screen" is
>> good.
> 
> Given no browser does it, I feel pretty confident we should not put that in the spec. 
> [...]
> I think we should raise the issue in a table-spec-breakout session in the future, with the following options:
> - Statu quo (repeating does not have to occur in non-page fragmentainers)
> - User agents may repeat headers and/or footers when fragmenting
> - User agents should repeat headers when fragmenting
> - User agents should repeat headers and footers when fragmenting
> 
> Anything beyond "should" makes me uncomfortable. I am personally leaning towards 1 and 3.

CSS is not just for browsers (even if they are obviously the dominant force), and if you broaden the UAs you consider, the "none of them does it" is no longer true.

Despite no browser doing it, I don't think we'd have a compat problem. Tables with thead and tfoot elements, especially when they are being nested in a multi-col, are extremely unlikely to be tables-for-layout, and almost certainly actual tabular content. When tables are being used for layout, preserving the current behavior, no matter how insane, is important. For actual tabular data, "doing the right thing" is worth at least considering.

In part due to browser bugginess, in part because the usability of multicol in scrolled media being tricky, multicol usage on the web is fairly low. If you throw in the fact that firefox never fragments tables in multicol at all, I'd expect that usage of tables, with thead and/or tfoot, in multicol, on the web, is somewhere between marginal and non existent.

So, if we required repeating in multicol, I don't think we'd be breaking anything, nor do I think that browser's behavior is particularly reliable to indicate desired behavior.

On the other hand, pdf formatters are used to generate things like catalogs, corporate reports, scientific  articles, and so on, all of which tend to both use tables and multicol. This both represents a body of content to be compatible with, and good evidence that this is the desired behavior.

Now, I do understand that browsers may not care to prioritize this very much, and that we wouldn't want to hold back the table specification on this (though I don't think we're any where near exiting CR on this spec), so doing some process shenanigans (at-risk?) on this sounds fine to me, but if it is the right behavior, and requiring it wouldn't cause breakage, I'm not too comfortable with not specifying it.

 - Florian
Received on Tuesday, 23 February 2016 09:26:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:36 UTC