Discussion:
[css-tables] Dropping repeated headers/footers when one content row doesn't fit
(too old to reply)
François REMY
2017-01-06 20:18:23 UTC
Permalink
Raw Message
I'm reading it to say that as long as repeating the header and footer leaves room for at least part of a tbody row in the fragmentainer then they can both remain. If it doesn't, but dropping the repeated footer allows room for at least part of a tbody row, then drop the repeated footer but keep the repeated header.
Correct that is what browsers seems to do today.
I had expected you to say that where a tbody row can't fit in full in a fragmentainer that both header and footer should be dropped from that fragmentainer so I just want to be sure I'm not misreading your proposal!
I thought it was what browsers were doing so that is what I initially intended, but matching current implementations when they agree on a result is what we want, not to define a new behavior, so I would like to clarify that to mention any part of a row and
François REMY
2017-01-06 21:04:41 UTC
Permalink
Raw Message
1. 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.

Looks fine to me. The issue is that at least in Edge if we break the thead in fragments we cannot repeat it later on. However since we only support repeated footer/header when printing and we don’t support variations in paper size our behavior is guaranteed to provide the same result as your algorithm.



1. 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”?

I assume the repeat behavior is always all or nothing, you can’t get partial repetition. If the rows are included due to normal flow, this isn’t a repetition (in short “repeated” does not include the original).


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.

Fair point.
Florian Rivoal
2017-01-07 02:45:38 UTC
Permalink
Raw Message
Post by François REMY
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”?
I assume the repeat behavior is always all or nothing, you can’t get partial repetition. If the rows are included due to normal flow, this isn’t a repetition (in short “repeated” does not include the original).
I don't remember for sure, but I think I meant that if you had multiple tfoot elements (not multiple rows in a tfoot), you're repeat them all. However, that's not what browsers do, so never mind.

—Florian
François REMY
2017-01-07 04:14:05 UTC
Permalink
Raw Message
On Jan 7, 2017, at 06:04, François REMY <***@outlook.com<mailto:***@outlook.com>> wrote:

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

I assume the repeat behavior is always all or nothing, you can't get partial repetition. If the rows are included due to normal flow, this isn't a repetition (in short "repeated" does not include the original).

I don't remember for sure, but I think I meant that if you had multiple tfoot elements (not multiple rows in a tfoot), you're repeat them all. However, that's not what browsers do, so never mind.

-Florian

Yes, and that is in the spec as well:

If a table owns multiple display:table-header-group boxes, only the first is treated as a header; the others are treated as if they had display:table-row-group. https://drafts.csswg.org/css-tables-3/#table-header-group
Robert Hogan
2017-04-30 20:42:22 UTC
Permalink
Raw Message
HI there,

https://drafts.csswg.org/css-tables-3/#repeated-headers now says:

"When rendering the document into a paged media, user agents must repeat header
rows <https://drafts.csswg.org/css-tables-3/#table-header-group> and footer
rows <https://drafts.csswg.org/css-tables-3/#table-footer-group> on each
page spanned by a table if the page is the table’s fragmentainer, if the
header/footer has avoid break-inside
<https://drafts.csswg.org/css-break-3/#propdef-break-inside> applied to it,
if the height required to do so is inferior to two quarters of the page
height (up to one quarter for header rows, and up to one quarter for footer
rows), and* if that doesn’t cause a row to be displayed twice on that page*
."

What is the text in bold referring to? I can't work out how displaying a
row twice on the same page would come about.

Thanks,
Rob
Post by François REMY
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.
“with the tfoot being repeated at its bottom” shouldn't that be “with
**all** tfoot being repeated at its bottom”?
I assume the repeat behavior is always all or nothing, you can’t get
partial repetition. If the rows are included due to normal flow, this isn’t
a repetition (in short “repeated” does not include the original).
I don't remember for sure, but I think I meant that if you had multiple
tfoot elements (not multiple rows in a tfoot), you're repeat them all.
However, that's not what browsers do, so never mind.
—Florian
If a table owns multiple display:table-header-group boxes, only the first
is treated as a header; the others are treated as if they had
display:table-row-group.
https://drafts.csswg.org/css-tables-3/#table-header-group
Florian Rivoal
2017-05-01 08:18:58 UTC
Permalink
Raw Message
Post by Robert Hogan
HI there,
"When rendering the document into a paged media, user agents must repeat header rows <https://drafts.csswg.org/css-tables-3/#table-header-group> and footer rows <https://drafts.csswg.org/css-tables-3/#table-footer-group> on each page spanned by a table if the page is the table’s fragmentainer, if the header/footer has avoid break-inside <https://drafts.csswg.org/css-break-3/#propdef-break-inside> applied to it, if the height required to do so is inferior to two quarters of the page height (up to one quarter for header rows, and up to one quarter for footer rows), and if that doesn’t cause a row to be displayed twice on that page."
What is the text in bold referring to? I can't work out how displaying a row twice on the same page would come about.
This is trying to say that repeating the header/footer should not cause them to be added to a page where they already would be. No double header on the first fragment, no double footer on the last one.

—Florian

François REMY
2017-01-06 21:07:49 UTC
Permalink
Raw Message
Post by François REMY
I'm reading it to say that as long as repeating the header and footer leaves room for at least part of a tbody row in the fragmentainer then they can both remain. If it doesn't, but dropping the repeated footer allows room for at least part of a tbody row, then drop the repeated footer but keep the repeated header.
Correct that is what browsers seems to do today.
Actually I had a look at our source code, and what Edge and Firefox do is easier than that even, we just repeat the footer/header if they occupy less than 25% of the fragmentainer height. Combined they can therefore never account for more than half of the fragmentainer height, which means that it should be enough to fit a row for sure.

I will put that in the
François REMY
2017-01-06 23:36:14 UTC
Permalink
Raw Message
Can you please have a look at the new text and tell me if that works for you both?

I didn't call out an explicit algorithm for now but trying to write one informed how I rewrote some of the paragraphs.

https://drafts.csswg.org/css-tables-3/#fragmentation




-----Original Message-----
From: François REMY
Sent: Friday, January 6, 2017 1:08 PM
To: 'François REMY' <***@outlook.com>; Robert Hogan <***@gmail.com>; www-style list <www-***@w3.org>
Subject: RE: [css-tables] Dropping repeated headers/footers when one content row doesn't fit
Post by François REMY
I'm reading it to say that as long as repeating the header and footer leaves room for at least part of a tbody row in the fragmentainer then they can both remain. If it doesn't, but dropping the repeated footer allows room for at least part of a tbody row, then drop the repeated footer but keep the repeated header.
Correct that is what browsers seems to do today.
Actually I had a look at our source code, and what Edge and Firefox do is easier than that even, we just repeat the footer/header if they occupy less than 25% of the fragmentainer height. Combined they can therefore never account for more than half of the fragmentainer height, which means that it should be enough to fit a row for sure.

I will put t
Florian Rivoal
2017-01-07 02:42:20 UTC
Permalink
Raw Message
I thought it was what browsers were doing so that is what I initially intended, but matching current implementations when they agree on a result is what we want, not to define a new behavior, so I would like to clarify that to mention any part of a row and not necessarily a row in full.
Do you have test cases (even informal ones) for that?

I agree that we want to match current implementations when they agree rather than define a new behavior, but when it comes to table fragmentation, I think we ought to include non-browser implementations as well (vivliostyle, prince, antenna house, pdf reactor...), as they tend to have paid a lot more attention to fragmentation than browsers have.

I have not run the tests, so I don't know if they're different or not. And even if they are, maybe we'll want to overrule them. But we should at least check.

—Florian
Loading...