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

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

From: Florian Rivoal <florian@rivoal.net>
Date: Wed, 21 Dec 2016 10:20:12 +0900
Cc: Robert Hogan <robhogan@gmail.com>, www-style list <www-style@w3.org>
Message-Id: <B86D9B01-45FB-403D-A48F-C7DC6B2A2E9C@rivoal.net>
To: François REMY <francois.remy.dev@outlook.com>

> On Dec 21, 2016, at 04:24, François REMY <francois.remy.dev@outlook.com> wrote:
> 
> 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:
>  
> 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.
> 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.
Why abort? If the next fragmentainer is larger, you may be able to repeat there. We do want to avoid infinite loops of looking for a large enough fragmentainer somewhere down the road, but how about something like this instead:
- If that happens and the table was the first element in the current fragmentainer:
  - if all thead rows of this table have already been laid out at least once in a previous fragmentainer, skip all thead rows for this fragmentainer and otherwise apply these steps normally.
  - if some thead rows of this table have not yet been laid out in a previous fragmentainers,  skip for this fragmentainer those that already have laid out and start with those that have not and otherwise apply these steps normally.

This should ensure that:
- all thead rows are displayed at least once
- if there isn't enough room to fit them all in a single fragmentainer, they get spread in however many fragmentainers it take to get them all
- if somewhere down the line, we start having enough room, we'll start/resume thread row repetition from there.

At least that's what I'm trying to do here.

> 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.
“with the tfoot being repeated at its bottom” shouldn't that be “with **all** tfoot being repeated at its bottom”?

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

If you can either fit thead or tfoot, you should use the thead. But if you have very large thead that cannot fit but small tfoot that can, why not repeat the tfoot? I think the modified step 2 I gave above gives that result.

—Florian
Received on Wednesday, 21 December 2016 01:20:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 December 2016 01:20:43 UTC