Re: [csswg-drafts] [css-tables][css-sizing] What sizing keywords allow fixed table mode? (#10937)

The CSS Working Group just discussed `[css-tables][css-sizing] What sizing keywords allow fixed table mode?`, and agreed to the following:

* `RESOLVED: fixed table layout is triggered except when inline-size is auto`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> iank_: When we trigger fixed table layout depends on the inline-size property.<br>
&lt;fantasai> iank_: This is inconsistent between implementations and spec<br>
&lt;fantasai> iank_: As we've added more keywords, it's also changed<br>
&lt;fantasai> iank_: Gecko and Blink are consistent with each other, and spec and WebKit are consistent<br>
&lt;fantasai> iank_: but spec wasn't kept up to date<br>
&lt;fantasai> iank_: Tables generally have a lot of behavior changes when something isn't 'auto'<br>
&lt;fantasai> iank_: This triggers for sizing columns, rows, etc.<br>
&lt;fantasai> iank_: We're already pretty close on 2 implementations<br>
&lt;fantasai> iank_: so easiest resolution would be condition on if inline-size is 'auto'<br>
&lt;oriol> q+<br>
&lt;fantasai> oriol: I like this proposed resolution. Note WebKit was aligned with the spec when I filed the issue, but they recently aligned 'fill-available' to align with Blink and Gecko<br>
&lt;fantasai> iank_: Also a difference between... if inline-size is not auto, need a different behavior. That's the easiest behavior.<br>
&lt;fantasai> iank_: Gecko and Blink also trigger on max-content, but don't see a reason to do that.<br>
&lt;astearns> ack oriol<br>
&lt;oriol> scribenick:oriol<br>
&lt;fantasai> scribe+ oriol<br>
&lt;astearns> ack fantasai<br>
&lt;oriol> fantasai: I'm trying to think the underlying logic of treating max-content different than min-content, semes weird<br>
&lt;oriol> fantasai: allowing fixed layout for stretch and such makes sense<br>
&lt;fantasai> fantasai: what does 'intrinsic' mean?<br>
&lt;fantasai> oriol: Webkit's non-standard thing, unsure what it's doing<br>
&lt;oriol> fantasai: I don't understand what min-intrinsic means<br>
&lt;fantasai> iank_: We're advocating to have max-content match min-content/fit-content<br>
&lt;fantasai> iank_: Logic is if inline-size is not auto, trigger fixed layout behavior<br>
&lt;emilio> q+<br>
&lt;astearns> ack emilio<br>
&lt;fantasai> emilio: ?? missed ??. Maybe dbaron remembers<br>
&lt;fantasai> astearns: so we're trying to turn table all green except for 'auto' value?<br>
&lt;fantasai> iank_: That's correct.<br>
&lt;fantasai> astearns: biggest change in WebKit, but changes all browsers<br>
&lt;emilio> s/??/looked up the special case, and goes back to the initial implementation by dbaron<br>
&lt;oriol> scribe+ fantasai<br>
&lt;emilio> s/??/But I also don't see any reason to special-case max-content and not other keywords<br>
&lt;emilio> https://bugzilla.mozilla.org/show_bug.cgi?id=311415<br>
&lt;fantasai> fantasai: what does fixed layout do for max-content?<br>
&lt;fantasai> iank_: It's not fixed layout, it's also intrinsically sized, but slightly different wa<br>
&lt;fantasai> s/wa/way<br>
&lt;TabAtkins> iirc, it's mainly just "only pay attention to the first row", right?<br>
&lt;fantasai> iank_: It's very confusing<br>
&lt;fantasai> iank_: At one point you didn't need to run intrinsic sizing, but we're well past that at this point<br>
&lt;fantasai> fantasai: Original justification was that you could do single-pass layout on it<br>
&lt;fantasai> iank_: Definitely no longer possible<br>
&lt;fantasai> iank_: we definitely compute intrinsic sizes for fixed table layout<br>
&lt;TabAtkins> (i remember using it to get reasonable column sizes based on the headings, rather than the body cells)<br>
&lt;oriol> fantasai: If you wave a huge table that is huge to layout, can you use fixed to get that?<br>
&lt;fantasai> iank_: We'd have to add a new table layout keyword for that to happen. Don't think it's possible today.<br>
&lt;fantasai> oriol: Still can bring some perf optimization, since you're ignoring measures of cells not in the first row, so may be faster<br>
&lt;fantasai> fantasai: So if doing max-content fixed layout, would size for first row and then lay out table following that?<br>
&lt;fantasai> oriol: in servo we don't do anything special except compute different measures for the tracks<br>
&lt;fantasai> fantasai: If by "compute different measures" you mean ignore the cell contents, that's pretty significant difference.<br>
&lt;fantasai> oriol: whether table is fixed or not is not relevant to intrinsic sizes of table, or the way you compute them ... can affect the final result<br>
&lt;fantasai> iank_: Difference between fixed vs auto layout is minimal, they both have a max-content size and min-content size<br>
&lt;fantasai> iank_: from my point of view there's not a good perf optimization benefit to it given where web-compat is now<br>
&lt;fantasai> iank_: you always need to determine min-content size on everything<br>
&lt;fantasai> iank_: there's a max-content size<br>
&lt;fantasai> florian: Is it used for perf? Or is it used when just tuning for first row?<br>
&lt;fantasai> iank_: Min constraint doesn't even restrict to first row.<br>
&lt;miriam> (yes, Florian's comment matches my experience of the use-case)<br>
&lt;fantasai> astearns: since the issue isn't about how it generally works, but what triggers it, can we resolve on it works for everything except auto?<br>
&lt;fantasai> [general silence]<br>
&lt;fantasai> RESOLVED: fixed table layout is triggered except when inline-size is auto<br>
</details>


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


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

Received on Wednesday, 19 February 2025 16:27:35 UTC