Skip to content

[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

Open
gregwhitworth opened this issue Sep 14, 2016 · 7 comments
Open

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

gregwhitworth opened this issue Sep 14, 2016 · 7 comments
Labels
css-tables-3 Current Work

Comments

@gregwhitworth
Copy link
Contributor

gregwhitworth commented Sep 14, 2016

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

  • auto columns are expanded first
  • then px columns if there is no auto column
  • then % if there is no px column either.

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
Copy link
Contributor

FremyCompany commented Jul 24, 2017

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
Copy link
Contributor

FremyCompany commented Jul 24, 2017

(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
Copy link
Member

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
Copy link
Contributor

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 FremyCompany changed the title [css-tables] fixed width distribution [css-tables] excess width distribution in fixed layout mode Jul 24, 2017
@FremyCompany
Copy link
Contributor

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 :)

@w3c w3c deleted a comment from davidsgrogan Jul 24, 2017
@w3c w3c deleted a comment from davidsgrogan Jul 24, 2017
@davidsgrogan
Copy link
Member

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
css-tables-3 Current Work
Projects
None yet
Development

No branches or pull requests

4 participants