Closed Bug 1694340 Opened 3 years ago Closed 3 years ago

[wpt-sync] Sync PR 27740 - [TablesNG] COL visibility:collapse and table inline size interaction

Categories

(Core :: Layout: Tables, task, P4)

Product:
Core
Component:
Layout: Tables
Type:
task

Tracking

()

Status:
RESOLVED FIXED
Milestone:
88 Branch
Tracking Flags:
Tracking Status
firefox88 --- fixed

People

(Reporter: mozilla.org, Unassigned)

References

(
URL
)

Details

(Whiteboard: [wptsync downstream])

Sync web-platform-tests PR 27740 into mozilla-central (this bug is closed when the sync is complete).

PR: https://github.com/web-platform-tests/wpt/pull/27740
Details from upstream follow.

b'Aleks Totic <atotic@chromium.org>' wrote:

[TablesNG] COL visibility:collapse and table inline size interaction

What happens to table size when column collapses?
And what happens to table's intrinsic size when column collapses?

Column collapsing standard specifies something like "table tracks
should be laid out as if column was there. After tracks are laid out
the collapsed track should get a width of 0".

What happens to the table size?

I think FF handles this better than we do. In FF, table gets resized,
but the space occupied by the table remains the same (unless table
is inline).

In our current architecture, table frament inline size is determined
before layout, inside ComputeInitialFragmentGeometry.

This size gets set on container_builder, and cannot be changed.

We could ship as is, but I think FF is better, and I'd like to match
it.

But this cannot be done in current architecture. The problem is
usage of FixedInlineSize on constraint space.

Certain layouts (flex, abspos), compute table's MinMax size,
and then compute what size they'd like final table to be.
This size is set as ConstraintSpace().FixedInlineSize.

Table layout algorithm uses FixedInlineSize to layout table tracks.
This value must be "size of the table before column
collapse", othewise non-collapsed columns will be too narrow.

I could not think of a workaround for FixedInlineSize problem.

I think we can match FF if container_builder_
could change inline size of fragment not to match
InitialFragmentGeometry. But I know Ian does not like this.

It is an exception: table generates a fragment
"as if table's size is X" and then at the last second
changes that final size to Y.

Bug: 958381
Change-Id: I5ea98f01fec4be5cbb7377920cdd2d3693b3c725
Reviewed-on: https://chromium-review.googlesource.com/2714425
WPT-Export-Revision: 8a70543822491a10df1399522c22d7e48eed1f8f

Component: web-platform-tests → Layout: Tables
Product: Testing → Core

CI Results

Ran 15 Firefox configurations based on mozilla-central, and Firefox, Chrome, and Safari on GitHub CI

Total 1 tests and 5 subtests

Status Summary

Firefox

OK : 1
PASS: 5

Chrome

OK : 1
PASS: 5

Safari

OK : 1
PASS: 5

Links

Gecko CI (Treeherder)
GitHub PR Head
GitHub PR Base

Pushed by wptsync@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1074a89cdf47
[wpt PR 27740] - [TablesNG] COL visibility:collapse and table inline size interaction, a=testonly

https://hg.mozilla.org/mozilla-central/rev/1074a89cdf47

Status: NEW → RESOLVED
Closed: 3 years ago
status-firefox88: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 88 Branch
You need to log in before you can comment on or make changes to this bug.