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}