-
Notifications
You must be signed in to change notification settings - Fork 707
[css-tables] excess width distribution in fixed layout mode #484
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
Comments
Summary
Face to face recommendation
Examples |
(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 |
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. |
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 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. |
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 :) |
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 In Edge the auto and fixed tables are identical, which is the behavior this issue is striving for. |
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;
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:
|
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
The text was updated successfully, but these errors were encountered: