Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 1 commit into from Feb 24, 2021

Conversation

@chromium-wpt-export-bot
Copy link
Collaborator

@chromium-wpt-export-bot chromium-wpt-export-bot commented Feb 23, 2021

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/c/chromium/src/+/2714425
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Commit-Queue: Aleks Totic <atotic@chromium.org>
Cr-Commit-Position: refs/heads/master@{#857005}

Copy link
Collaborator

@wpt-pr-bot wpt-pr-bot left a comment

The review process for this patch is being conducted in the Chromium project.

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/c/chromium/src/+/2714425
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Commit-Queue: Aleks Totic <atotic@chromium.org>
Cr-Commit-Position: refs/heads/master@{#857005}
@chromium-wpt-export-bot chromium-wpt-export-bot force-pushed the chromium-export-cl-2714425 branch from 8f78816 to dae9e9d Feb 24, 2021
@chromium-wpt-export-bot chromium-wpt-export-bot merged commit 78f2b7c into master Feb 24, 2021
23 checks passed
23 checks passed
update-pr-preview
Details
Azure Pipelines Build #20210224.10 succeeded
Details
Azure Pipelines (./wpt test-jobs) ./wpt test-jobs succeeded
Details
Azure Pipelines (affected tests without changes: Safari Technology Preview) affected tests without changes: Safari Technology Preview succeeded
Details
Azure Pipelines (affected tests: Safari Technology Preview) affected tests: Safari Technology Preview succeeded
Details
Azure Pipelines (wpt.fyi hook: safari-preview-affected-tests) wpt.fyi hook: safari-preview-affected-tests succeeded
Details
Azure Pipelines (wpt.fyi hook: safari-preview-affected-tests-without-changes) wpt.fyi hook: safari-preview-affected-tests-without-changes succeeded
Details
download-firefox-nightly Community-TC (pull_request)
Details
lint Community-TC (pull_request)
Details
sink-task Community-TC (pull_request)
Details
staging.wpt.fyi - chrome[experimental] Chrome results
Details
staging.wpt.fyi - firefox[experimental] Firefox results
Details
staging.wpt.fyi - safari[experimental] Safari results
Details
wpt-chrome-dev-results Community-TC (pull_request)
Details
wpt-chrome-dev-results-without-changes Community-TC (pull_request)
Details
wpt-chrome-dev-stability Community-TC (pull_request)
Details
wpt-decision-task Community-TC (pull_request)
Details
wpt-firefox-nightly-results Community-TC (pull_request)
Details
wpt-firefox-nightly-results-without-changes Community-TC (pull_request)
Details
wpt-firefox-nightly-stability Community-TC (pull_request)
Details
wpt.fyi - chrome[experimental] Chrome results
Details
wpt.fyi - firefox[experimental] Firefox results
Details
wpt.fyi - safari[experimental] Safari results
Details
@chromium-wpt-export-bot chromium-wpt-export-bot deleted the chromium-export-cl-2714425 branch Feb 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants