w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.42k stars 652 forks source link

[css-tables] excess width distribution in fixed layout mode #484

Open gregwhitworth opened 7 years ago

gregwhitworth commented 7 years ago

Compat Issues: Potentially

Description: Chrome and Webkit distribute excess width differently when the table-layout is fixed. This is understandable to an extent given that width distribution works differently in fixed layout, but it would be good to be consistent where possible.

Proposed Option: Have fixed excess width distribution follow that of table-layout: auto: https://drafts.csswg.org/css-tables-3/#distributing-width-to-columns

CSS 2.1 Option: Undefined in CSS 2.1.

Other options: Use a different width distribution for table-layout:fixed, which would work like Chrome and Webkit and consider percentages columns prime candidate for distribution and not pixel ones like usually.

Testcases: http://codepen.io/FremyCompany/pen/yeKRGW?editors=1100

Browsers Passing Test: Non webkit-based browsers

FremyCompany commented 7 years ago

Summary

Chrome and Webkit distribute excess width differently when the table-layout is fixed. This is understandable to an extent given that width distribution works differently in fixed layout, but it would be good to be consistent where possible.

Face to face recommendation

Discuss proposed resolution (Edge+Firefox) and Google's compat data if any yet

Examples

http://codepen.io/FremyCompany/pen/yeKRGW?editors=1100

FremyCompany commented 7 years ago

(Replying to @davidsgrogan confusion about obscure text used before)

Greg meant that in Edge+Firefox if you have to distribute extra space beyond the preferred widths of columns, the extra width is distributed to auto columns first, if possible. Then, if not possible, it is distributed to px columns (to preserve percentages correctness), then finally if that was not possible then percentages get increased.

The guess system for min-content / min-content-percentage / ... that is used to compute what to do if columns cannot get their preferred width do not apply for fixed layout, see https://drafts.csswg.org/css-tables-3/#width-distribution-in-fixed-mode

davidsgrogan commented 7 years ago

Ah, so this issue is about the https://drafts.csswg.org/css-tables-3/#distributing-excess-width-to-columns, specifically the rules in the fixed-mode advisement at the end of that section.

FremyCompany commented 7 years ago

Exactly.

The interop difference is what happens when the rules in 3.9.3.1 do not apply because if you assign their preferred width to all columns, you still have excess width to distribute.

Firefox and Edge apply the same algorithm for excess width distribution in this case whether you are table-layout:auto or table-layout:fixed (this is the algorithm which will try to preserve percentage correctness most importantly, and pixel correctness secondly only: as such it will distribute the excess width to auto columns first; if not possible it will distribute to pixel columns; then if still not possible it will distribute it to percentage columns).

Webkit and Blink apply a different excess-width distribution algorithm in this case which attempts to preserve pixel values instead. This is what we would like to avoid to add to the spec.

FremyCompany commented 7 years ago

I updated the general description to make things clearer, and will delete the comments where we got lost. It's funny how things look clear when you write them initially and how confusing things appear less than a year after and your memory slightly faded out :)

davidsgrogan commented 7 years ago

Note that FF actually behaves differently between auto and fixed in the given test case (http://codepen.io/FremyCompany/pen/yeKRGW?editors=1100).

auto (top) table has cell widths of 157px each fixed (bottom) table has cell widths of 159px and 155px

In Edge the auto and fixed tables are identical, which is the behavior this issue is striving for.

FremyCompany commented 7 years ago

The sizing difference of 2px is not due to the excess width distribution (everything is distributed to the second column in both browsers). It is actually due to the cellpadding of 1px. 157px + 1px * 2 = 159px. It looks like Firefox does not have the following rule from the spec implemented;

Cells ignore their border and padding size if their width is a percentage (box-sizing is ignored)

In Firefox, if you set a 10px cell padding, then the first cell will be 20px bigger than 50% of the table. I will still be 50% of the table in Edge. Edge's behavior is consistent with what is being done in auto mode.

Well, except that in auto mode the cell padding will still be counted for the minimum width of the cell, but there is no such thing in fixed mode (the whole point being that cell's content should not influence track size so that you can be fast). In the spec that is:

The minimum width of percent-columns and auto-columns is considered to be zero