Open atotic opened 3 years ago
My understanding is that fixed tables work that way so that you can add rows without having to recompute the column widths. Checking the second row would defeat that purpose.
add rows without having to recompute the column widths
I believe that original intent was that you were able to determine column widths just by traversing the first row.
This optimization is no longer possible, and might have never been possilble.
Also, computing table's ink overflow requires traversing the entire table.
Today, this behavior is just a historical quirk that makes life more complex for web developers. Also, we might see many more "0-width borders on the first row", because that is currently the only way to get glitch-free collapsed borders + sticky headers.
Ok, so if I understood correctly, what you are saying that with the current complexity level of the web platform, this optimization is no longer useful, and that it's a constraint we should relax to make developers' life easier. Is that correct?
If so, I am not against that.
Regarding web compatibility, could you put a use counter so we can take a look at a few sites and check if that improves or cause issues for them?
Filed a chrome issue asking for a use counter: https://bugs.chromium.org/p/chromium/issues/detail?id=1238243
Wonderful, thanks @atotic!
I've added in the use-counter. My expectation is that there won't be a many (if any) sites relying on this quirk. We should have some initial data in a couple of months.
As Aleks says implementations already have to calculate the other value to correctly determine visual-overflow so there really isn't any "performance benefit". (There /potentially/ was in old implementations which has much simpler paint sub-systems, e.g. they didn't care about visual overflow as much, but this isn't true for modern implementations).
I finally got around to performing some analysis on our UseCounter data. TL;DR I think this change is going to be fine.
The UseCounter is "high" at ~0.55% of pageloads. However I analyzed a lot of examples URLs - all the changes are all minimal. The changes broadly fall into ~4-5 categories.
Craigslist - e.g. https://sfbay.craigslist.org/ Here the calendar widget on the right changes size by 1px. This doesn't have any affect on page layout. It does have a small (barely noticeable) visual effect making the border between the table body and header uniform. Interestingly this was previously present. E.g. it has the CSS rule:
.cal .dys th, .cal td {
border: 1px #ccc solid;
}
However this doesn't match the <th>
element as it now uses the class .days
(instead of .dys
).
Discourse - e.g. https://discourse.wicg.io/categories Here the "categories" panel uses visual table overflow to add category color on the left of the table. This is the largest visual effect I've seen in my analysis (3px shift in visual - border is 6px). No layout change. The new behaviour is arguably slightly better at small screen sizes with this change, and a little bit of a wash at large. We could submit a PR to modify discourse directly if they'd like to keep their current behaviour.
Open table reservation widget - e.g. https://www.charcoalgrillbar.com/ Similar to the calendar widget in craigslist - no significant change (0.5px delta on each side) - no visual difference.
Various calendar widgets on blogs etc. Similar to the other calendar widgets no significant changes.
In my opinion if we'd like to do this change - it'll has a high chance of being fine, and given the amount of confusion it has generated over the years (e.g. we still get bug reports about this behaviour) likely a positive for the web platform. Personally my only real concern is the discourse example.
Ian
Sounds like good news to me! Would Chrome volunteer to try the change if I update the spec to allow the behavior?
Yeah I think so - its fairly straightforward for us. I'll let you adgenda+ it so that you can be on the call.
This week is APAC call. So yeah not joining, will Agenda+ for the next one.
FWIW the current spec:
Harmonize the table-root border-{top,bottom,left,right} with the corresponding border of all cells forming the border of the table (indenpendently), without actually modifying the border properties of the table-root.
If the table and the cell border styles have the same specificity, keep the cell border style.
Once this is done, set the table-root border-{…}-width to half the maximum width found during the harmonization processes for that border, then set border-{…}-style to solid, and border-{…}-color to transparent.
And the older spec:
UAs must compute an initial left and right border width for the table by examining the first and last cells in the first row of the table. The left border width of the table is half of the first cell's collapsed left border, and the right border width of the table is half of the last cell's collapsed right border. If subsequent rows have larger collapsed left and right borders, then any excess spills into the margin area of the table.
Any borders that spill into the margin are taken into account when determining if the table overflows some ancestor (see 'overflow').
All engines seem to do this latter thing, but rounding issues cause this to be un-noticable in Firefox in the initial test case. Here is a more clear test case: https://jsfiddle.net/gfhLs745/
The CSS Working Group just discussed collapsed table row quirk
, and agreed to the following:
RESOLVED: Accept current Tables 3 spec text regarding calculation of shared borders in collapsed-border mode between table and cells.
\o/ When I filed this issue, I did not think we'd actually fix it. Thanks everyone!
Chrome gets bug reports about incorrect table widths for tables with collapsed borders. Examples: https://crbug.com/1200116 https://crbug.com/711360
The issue happens because per spec, width of the table in collapsed borders mode is determined by borders in the 1st row. I could not find definition of this behavior in the latest spec, but here it is in the old spec: https://www.w3.org/TR/2011/REC-CSS2-20110607/tables.html#collapsing-borders "As must compute an initial left and right border width for the table by examining the first and last cells in the first row of the table.'
If the first row has no borders, this results in a behavior developers consider a bug.
What do you think about using all the rows to compute table size? I am not sure if this is web compatible, but it would increase developer happiness.