commit 4e1dddf5a4bbd613747f04af48d9f150ff0a1df6
author Morten Stenshorne <mstensho@chromium.org> Wed Jul 06 09:00:51 2022
committer Blink WPT Bot <blink-w3c-test-autoroller@chromium.org> Wed Jul 06 09:13:24 2022
tree 28f92e06bf1dcf7dc7b3ef6beeea3d0f8b8954c3
parent 514941924839805f60dec72877751bf8294d060a

Handle specified table block-size correctly when fragmented.

Introduce table-specific break token data to make our job easier /
possible. The break token will know the total consumed block-size of the
"table box" (the table element, excluding captions), and also whether we
have entered the table box and whether we're also past it.

This involves some non-trivial changes to the table layout algorithm, so
that we can calculate the intrinsic block-size correctly (which
shouldn't be affected by the specified block-size), so that we can break
correctly inside the table. The fragmentation machinery will not break
inside if the intrinsic block-size is larger than available space,
except for the space taken up by block-end border/padding. The machinery
expects block-end border/padding to be included in the fragment size (it
will subtract it again, if necessary), even if we know we're going to
break inside. So we generally shouldn't omit block-end border/padding
when laying out the fragment. That's one thing less for the table layout
algorithm to worry about.

Had to shuffle some code around, so that we invoke the fragmentation
machinery before setting a table grid block-size.

I also discovered that we set the table column block-size incorrectly
when fragmented. Will address this in a follow-up CL, but added a TODO
for now.

Remove fragmentation/fragmented-table-with-fixed-height.html , since
it's invalid. It expects a table's specified height to be ignored if the
table gets fragmented, which is what the legacy fragmentation engine
does.

This also happens to fix crbug.com/1251689 , which is about a flexbox
with a table inside that establishes an orthogonal writing mode.
Probably fixed by the fact that we no longer let specified block-size
(and flex-basis, I suppose) affect the intrinsic block-size of the
table. The table layout algorithm has some hacks for intrinsic
block-size calculation when inside a flex container, which probably
didn't work in this particular case. Maybe we can remove that now.

Bug: 1335881, 1251689
Change-Id: I9a803daf5f08647aaa019ff0484e425406bc7d27
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3745936
Reviewed-by: Alison Maher <almaher@microsoft.com>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1021095}