Re: [csswg-drafts] Collapsed table first row width quirk (#6230)

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.`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> Topic: collapsed table row quirk<br>
&lt;TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/6230<br>
&lt;TabAtkins> fremy: while reimplementing tables in chrome, the dev found a lot of bugs that werne't bugs per spec, but were unexpected by authors<br>
&lt;TabAtkins> fremy: We realized the new version of the spec was causing the issues<br>
&lt;TabAtkins> fremy: But behavior that is currently implemented was mentioned in an old version of the spec<br>
&lt;TabAtkins> fremy: So chrome dev decided to implement the old behavior, since we didn't ahve resolution for the spec change, but they'd like to change to the new beahvior because the old didn't make much sense<br>
&lt;TabAtkins> fremy: They feared there would be some breakage with new behavior, so they added a UseCounter and studied websites<br>
&lt;TabAtkins> fremy: Found that on all websites, the changes to layout would be very small, if any, and often slightly better. Found one case where it was slightly worse, but in no case was it worse than about 3px.<br>
&lt;TabAtkins> fremy: So they want to update their impl to the new spec, if the WG approves it<br>
&lt;TabAtkins> fremy: So that's context. Here's the behavior.<br>
&lt;iank_> https://www.w3.org/TR/CSS2/tables.html#:~:text=17.6.2-,The%20collapsing%20border%20model,-In%20the%20collapsing<br>
&lt;TabAtkins> fremy: When you have a table in collapsed border mode<br>
&lt;bradk> 3px narrower or 3px wider?<br>
&lt;TabAtkins> fremy: Two cells next to each other, the border needs to be "harmonized" - pick one of the two borders and draw.<br>
&lt;TabAtkins> fremy: Must also harmonize border between cells and the table itself.<br>
&lt;TabAtkins> fremy: In the new spec you harmonize all the cells on the table edge, take the biggest one. Do that for each edge.<br>
&lt;TabAtkins> fremy: The older spec for some reason only harmonized the first cell of the first row.<br>
&lt;astearns> https://www.w3.org/TR/CSS2/tables.html#collapsing-borders is a more interoperable version of iank_'s URL<br>
&lt;TabAtkins> fremy: If you have a table you don't draw borders around the header row, but you use borders for the rest,<br>
&lt;TabAtkins> fremy: According to the old spec, the borders will then be drawn outside the table<br>
&lt;TabAtkins> fremy: so it often just causes an overflow of like 1px, not noticeable<br>
&lt;TabAtkins> fremy: But scrollbars can pop<br>
&lt;TabAtkins> fremy: And devs can't figure out why it's happening<br>
&lt;bradk> That answers my question<br>
&lt;TabAtkins> fremy: Bug is marked as Doesn'tReproduce in Firefox, technically true, because they do something differently but still wrong, it's based on rounding.<br>
&lt;TabAtkins> fremy: So proposal is to accept the new spec text: when you decide the border of a table, you look at *all* the cells against each border edge, not just the first<br>
&lt;TabAtkins> fremy: Should be more in line with dev expectations, but it's currently a breaking change so we wanted a resolution.<br>
&lt;TabAtkins> iank_: Ironically this is one of the better specified areas in 2.1 regarding tables, which is why everyone has the same (bad) behavior.<br>
&lt;astearns> ack fantasai<br>
&lt;TabAtkins> fantasai: I worked on this issue in 2.1. I was really unhappy with the old resolution.<br>
&lt;TabAtkins> fantasai: Happy to move away from that.<br>
&lt;TabAtkins> fantasai: There was a proposal to have the borders not belonging to the table overlfow; another was to count thema s part of the border with. I think there was a third to allow it to overlap with the margin, but take up space if there wasn't enough amrgin.<br>
&lt;TabAtkins> fantasai: Say you have a table with anrrow borders, and you used a thick border to highlight an interesting cell.<br>
&lt;TabAtkins> fantasai: If you want the table to stay centered when the highlighted cell happens to be on the edge, we can't include the difference in the border width, it'll shift the table slighitly<br>
&lt;TabAtkins> fantasai: But that is a more complicated behavior, but I want to put it out for consideration.<br>
&lt;TabAtkins> fantasai: That effect is why, I suspect, why we had not taken the max border width, so those borders could overlap into the margin.<br>
&lt;TabAtkins> iank_: I don't believe we've found anyone using it that way. Might exist, but broadly the usage fell into a few buckets.<br>
&lt;TabAtkins> iank_: Primary is calendar widgets - craigslist was the big one. Had some dead code to add a transparent border to fix the behavior.<br>
&lt;TabAtkins> astearns: So the current spec describes what you prefer?<br>
&lt;TabAtkins> iank_: I think the max-border beahvior is defined in Tables 3.<br>
&lt;TabAtkins> iank_: caveated on us not breaking too much<br>
&lt;TabAtkins> iank_: Use counter is high-ish but layout changes are very minor.<br>
&lt;TabAtkins> fremy: Current Tables spec does have symmetrical behavior<br>
&lt;TabAtkins> astearns: francois, do you ahve opinions on the behavior fantasai described?<br>
&lt;TabAtkins> fremy: I see it's useful behavior<br>
&lt;TabAtkins> fremy: But think you should probably be using outline to add this kind of call-out border<br>
&lt;TabAtkins> fremy: So I think the simple behavior is fine. Wouldn't be mad either way.<br>
&lt;TabAtkins> fantasai: Think it's probably fine.<br>
&lt;TabAtkins> astearns: So proposed resolution is no change to the Tables spec, just confirming that the current spec is intended.<br>
&lt;fantasai> The thing I *wish* we could fix in table borders model is to invert the priority so that table wins over rowgroup over row over cell.<br>
&lt;fantasai> The current version is just so impossible to deal with if you want different colored but same-thickness borders for rows vs rowgroups, etc.<br>
&lt;TabAtkins> iank_: Think the spec fixes some unintuitive behavior for webdevs. Will report if there's problems.<br>
&lt;TabAtkins> RESOLVED: Accept current Tables 3 spec text regarding calculation of shared borders in collapsed-border mode between table and cells.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6230#issuecomment-1049044173 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 23 February 2022 17:45:28 UTC