[css-tables][css-sizing] What sizing keywords allow fixed table mode? #10937

Loirooriol · 2024-09-23T23:53:25Z

Situation

https://drafts.csswg.org/css-tables/#table-layout-property says

A table-root is said to be laid out in fixed mode whenever the computed value of the table-layout property is equal to fixed, and the specified width of the table root is either a <length-percentage>, min-content or fit-content.

This is the logic that browsers use for the inline size:

WebKit: https://searchfox.org/wubkat/rev/b36cbce69fddb7da33823f316bd8ead5bebee970/Source/WebCore/rendering/style/RenderStyleInlines.h#526
logicalWidth().isSpecified() || logicalWidth().isFitContent() || logicalWidth().isMinContent()
Firefox: https://searchfox.org/mozilla-central/rev/1e8cec3727d6e09f4af41bb3d202b7a4c326ed84/layout/tables/nsTableFrame.cpp#3482
(negated) iSize.IsAuto() || iSize.IsMaxContent()
Chrome: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/style/computed_style.h;drc=572789ee61c7e857aa288a7ac7768b2b0b4f4dcc;l=1924
!LogicalWidth().HasAuto() && !LogicalWidth().HasMaxContent()

So we have a mismatch of keywords that accept fixed table layout:

Value	Spec	WebKit	Gecko	Blink
`<length-percentage>`	✅	✅	✅	✅
`auto`	❌	❌	❌	❌
`min-content` (*)	✅	✅	✅	✅
`max-content` (*)	❌	❌	❌	❌
`fit-content` (*)	✅	✅	✅	✅
`<fit-content()>`	❌	❌︎	✅	✅︎
`contain`	❌	❌︎	✅︎	✅︎
`stretch`	❌	❌︎	✅	✅︎
`-webkit-fill-available`	❌︎	❌	✅	✅
`-moz-available`	❌︎	❌︎	✅	✅︎
`intrinsic`	❌︎	❌	✅︎	✅︎
`min-intrinsic`	❌︎	❌	✅︎	✅︎

<calc-size()> should just behave as its basis.

(*) including -webkit- and -moz- prefixes.
✅: Supports the value (at least partially), and allows fixed table layout
✅︎: Doesn't support the value, but it would allow fixed table layout
❌: Supports the value (at least partially), and doesn't allows fixed table layout
❌︎: Doesn't support the value, but it wouldn't allow fixed table layout

Example

<!DOCTYPE html>
<div style="width: 0">
  <table style="table-layout: fixed; width: -webkit-fill-available" border>
    <tr><td>lorem ipsum</td></tr>
  </table>
</div>

On Firefox (with layout.css.webkit-fill-available.enabled = true) and Blink the table ignores the contents and is almost 0px wide, while on WebKit it's wider according to the text.

Changes

I think that <fit-content()> should allow fixed table layout, just like fit-content and min-content.

And maybe stretch should too, to match 100%? Also, -webkit-fill-available/-moz-available is kinda the same thing, and it allows fixed table layout on 2/3 of the major browsers.

Nobody implements contain, but we should also decide what to do with it.

The text was updated successfully, but these errors were encountered:

bfgeek · 2024-09-24T17:20:47Z

As an aside does anyone know what max-content doesn't apply?

(FWIW the "rule" that we've been applying to to a lot of these table behaviours, is if "width is auto" do the special behaviour - this comes up a suprising amount in table layout).

Loirooriol · 2024-09-24T18:36:25Z

Yeah, it's kinda weird that, given enough available space, fit-content doesn't behave like max-content:

<!DOCTYPE html>
<div style="width: max-content">
  <table style="table-layout: fixed; width: max-content" border>
    <tr><td style="width: 0">lorem ipsum</td></tr>
  </table>
  <table style="table-layout: fixed; width: fit-content" border>
    <tr><td style="width: 0">lorem ipsum</td></tr>
  </table>
</div>

Only checking for auto would make this more future-proof.

Loirooriol · 2024-09-27T23:05:18Z

There was a broken test in https://github.com/web-platform-tests/wpt/blob/master/css/css-tables/fixed-layout-2.html, I have fixed it and tested all the cases above to help with interoperability.

…yout https://bugs.webkit.org/show_bug.cgi?id=280900 rdar://137297914 Reviewed by Alan Baradlay. This patch aligns WebKit with Blink / Chromium and Gecko / Firefox. In [1], the test was updated to also ensure that fixed table layout should also account for `fill-available` (-webkit-fill-available). It seems WebKit was not doing it, so this patch is to account for it and progress our behavior. [1] w3c/csswg-drafts#10937 The patch also sync particular test from below: Upstream commit: web-platform-tests/wpt@38d6fa7 * Source/WebCore/rendering/style/RenderStyleInlines.h: (WebCore::RenderStyle::isFixedTableLayout const): * LayoutTests/imported/w3c/web-platform-tests/css/css-tables/fixed-layout-2-expected.txt: * LayoutTests/imported/w3c/web-platform-tests/css/css-tables/fixed-layout-2.html: Canonical link: https://commits.webkit.org/284712@main

Loirooriol · 2024-10-05T02:08:18Z

WebKit/WebKit#34706 aligned -webkit-fill-available with Blink and Gecko.

tabatkins · 2025-02-12T18:05:10Z

If fit-content works and does a reasonable thing, then max-content should be allowed, since fit-content is just "max-content, clamped between min-content and available space". So it can resolve to the same value as max-content, and relies on max-content logic to do so. Or, if there is a good reason to disallow max-content, then that same reason blocks fit-content (and its variants) as well.

I suspect we might indeed just want to hinge the logic on "not auto".

frivoal · 2025-02-19T16:17:52Z

FYI, on my computer (which is running macOS), ✅ looks identical to ✅︎, and ❌ looks identical to ❌︎, so the table in the original comment is not easily readable.

css-meeting-bot · 2025-02-19T16:27:31Z

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

The full IRC log of that discussion

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

Loirooriol · 2025-02-19T17:03:08Z

Sorry, this is how it looks for me:

As per: w3c/csswg-drafts#10937 Behind the flag: TableIsAutoFixedLayout. Bug: 397669048 Change-Id: I906da424db40a52e92a026c3ae45b17bef2368c6

As per: w3c/csswg-drafts#10937 Behind the flag: TableIsAutoFixedLayout. Bug: 397669048 Change-Id: I906da424db40a52e92a026c3ae45b17bef2368c6 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6317355 Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org> Reviewed-by: David Grogan <dgrogan@chromium.org> Auto-Submit: Ian Kilpatrick <ikilpatrick@chromium.org> Commit-Queue: David Grogan <dgrogan@chromium.org> Cr-Commit-Position: refs/heads/main@{#1427334}

…when not auto., a=testonly Automatic update from web-platform-tests [css-tables] Trigger fixed table layout when not auto. As per: w3c/csswg-drafts#10937 Behind the flag: TableIsAutoFixedLayout. Bug: 397669048 Change-Id: I906da424db40a52e92a026c3ae45b17bef2368c6 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6317355 Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org> Reviewed-by: David Grogan <dgrogan@chromium.org> Auto-Submit: Ian Kilpatrick <ikilpatrick@chromium.org> Commit-Queue: David Grogan <dgrogan@chromium.org> Cr-Commit-Position: refs/heads/main@{#1427334} -- wpt-commits: f7a1b42e7d27e916e2953971150e7b39e44aefba wpt-pr: 51072

We were ignoring `table-layout: fixed` both for `inline-size: auto` and ìnline-size: max-content`. However, the CSSWG resolved that fixed table layout should be triggered except when `inline-size` is `auto`. w3c/csswg-drafts#10937 (comment) Blink has already adopted this change, and they modified the WPT `/css/css-tables/fixed-layout-2.html` accordingly. Here I'm doing some further cosmetic cleanups to the test.

We were ignoring `table-layout: fixed` both for `inline-size: auto` and `inline-size: max-content`. However, the CSSWG resolved that fixed table layout should be triggered except when `inline-size` is `auto`. w3c/csswg-drafts#10937 (comment) Blink has already adopted this change, and they modified the WPT `/css/css-tables/fixed-layout-2.html` accordingly. Here I'm doing some further cosmetic cleanups to the test.

Loirooriol · 2025-03-10T12:40:43Z

BTW, we didn't discuss this case in detail. @bfgeek interpreted the resolution as implying that calc-size(auto, size) allows fixed layout because it's not exactly auto.

But https://drafts.csswg.org/css-values-5/#resolving-calc-size

A calc-size() is treated, in all respects, as if it were its calc-size basis

So not sure if calc-size(auto, size) should prevent fixed layout just like auto?

We were ignoring `table-layout: fixed` both for `inline-size: auto` and `inline-size: max-content`. However, the CSSWG resolved that fixed table layout should be triggered except when `inline-size` is `auto`. w3c/csswg-drafts#10937 (comment) Blink has already adopted this change, and they modified the WPT `/css/css-tables/fixed-layout-2.html` accordingly. Here I'm doing some further cosmetic cleanups to the test. Signed-off-by: Oriol Brufau <obrufau@igalia.com>

…35882) We were ignoring `table-layout: fixed` both for `inline-size: auto` and `inline-size: max-content`. However, the CSSWG resolved that fixed table layout should be triggered except when `inline-size` is `auto`. w3c/csswg-drafts#10937 (comment) Blink has already adopted this change, and they modified the WPT `/css/css-tables/fixed-layout-2.html` accordingly. Here I'm doing some further cosmetic cleanups to the test. Signed-off-by: Oriol Brufau <obrufau@igalia.com>

We were ignoring `table-layout: fixed` both for `inline-size: auto` and `inline-size: max-content`. However, the CSSWG resolved that fixed table layout should be triggered except when `inline-size` is `auto`. w3c/csswg-drafts#10937 (comment) Blink has already adopted this change, and they modified the WPT `/css/css-tables/fixed-layout-2.html` accordingly. Here I'm doing some further cosmetic cleanups to the test. Signed-off-by: Oriol Brufau <obrufau@igalia.com>

bfgeek · 2025-03-11T18:31:08Z

BTW, we didn't discuss this case in detail. @bfgeek interpreted the resolution as implying that calc-size(auto, size) allows fixed layout because it's not exactly auto.

So I did this as it matches the "not initial" we've done for other cases in table layout.

Loirooriol · 2025-03-11T20:09:53Z

Can you provide some examples of these cases?

bfgeek · 2025-03-11T23:44:36Z

Loirooriol · 2025-03-12T00:07:44Z

OK it probably makes more sense to discuss these things in another issue.

…when `inline-size` is `auto`, a=testonly Automatic update from web-platform-tests layout: Only prevent fixed table layout when `inline-size` is `auto` We were ignoring `table-layout: fixed` both for `inline-size: auto` and `inline-size: max-content`. However, the CSSWG resolved that fixed table layout should be triggered except when `inline-size` is `auto`. w3c/csswg-drafts#10937 (comment) Blink has already adopted this change, and they modified the WPT `/css/css-tables/fixed-layout-2.html` accordingly. Here I'm doing some further cosmetic cleanups to the test. Signed-off-by: Oriol Brufau <obrufau@igalia.com> -- wpt-commits: afa16aa1d44cdc7d33cb4812a794b3ed4c2c8789 wpt-pr: 51231

https://bugs.webkit.org/show_bug.cgi?id=290247 rdar://problem/147636653 Reviewed by Alan Baradlay. This patch aligns WebKit with CSSWG Resolution [1]: [1] w3c/csswg-drafts#10937 (comment) "Fixed table layout is triggered except when inline-size is auto". In this patch, we remove `allow-list` we had for different length types and keep it to just `isAuto()`.` * Source/WebCore/rendering/style/RenderStyleInlines.h: (WebCore::RenderStyle::isFixedTableLayout const): * LayoutTests/imported/w3c/web-platform-tests/css/css-tables/fixed-layout-2-expected.txt: Rebaselined Canonical link: https://commits.webkit.org/292536@main

Loirooriol added css-tables-3 Current Work css-sizing-3 Current Work css-sizing-4 labels Sep 23, 2024

Loirooriol added the Agenda+ label Sep 24, 2024

Loirooriol mentioned this issue Sep 25, 2024

[css-sizing] Stretch-fitting inline size next to floats. #4028

Open

Ahmad-S792 mentioned this issue Oct 4, 2024

Table Root should also account for fill-available in fixed table layout WebKit/WebKit#34706

Merged

astearns moved this to FTF agenda items in CSSWG January 2025 meeting Jan 22, 2025

astearns added this to CSSWG January 2025 meeting Jan 22, 2025

astearns moved this from FTF agenda items to Regular agenda items in CSSWG January 2025 meeting Jan 22, 2025

astearns moved this from Regular agenda items to Friday morning in CSSWG January 2025 meeting Jan 28, 2025

css-meeting-bot removed the Agenda+ label Feb 19, 2025

chromium-helper mentioned this issue Feb 19, 2025

[css-tables][css-sizing] What sizing keywords allow fixed table mode? chromium-helper/csswg-resolutions#704

Closed

mozilla-apprentice mentioned this issue Feb 19, 2025

[css-tables][css-sizing] What sizing keywords allow fixed table mode? mozilla/wg-decisions#1812

Open

astearns added the Needs Edits label Feb 19, 2025

chromium-wpt-export-bot mentioned this issue Mar 3, 2025

[css-tables] Trigger fixed table layout when not auto. web-platform-tests/wpt#51072

Merged

Loirooriol mentioned this issue Mar 10, 2025

layout: Only prevent fixed table layout when inline-size is auto servo/servo#35882

Merged

3 tasks

servo-wpt-sync mentioned this issue Mar 10, 2025

layout: Only prevent fixed table layout when inline-size is auto web-platform-tests/wpt#51231

Merged

Loirooriol added the Agenda+ label Mar 11, 2025

Loirooriol removed the Agenda+ label Mar 12, 2025

Ahmad-S792 mentioned this issue Mar 22, 2025

Fixed table layout should only be triggered when inline-size is not auto WebKit/WebKit#42872

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[css-tables][css-sizing] What sizing keywords allow fixed table mode? #10937

[css-tables][css-sizing] What sizing keywords allow fixed table mode? #10937

Loirooriol commented Sep 23, 2024 •

edited

Loading

bfgeek commented Sep 24, 2024

Uh oh!

Loirooriol commented Sep 24, 2024

Uh oh!

Loirooriol commented Sep 27, 2024

Uh oh!

Loirooriol commented Oct 5, 2024

Uh oh!

tabatkins commented Feb 12, 2025

Uh oh!

frivoal commented Feb 19, 2025

Uh oh!

css-meeting-bot commented Feb 19, 2025

Uh oh!

Loirooriol commented Feb 19, 2025

Uh oh!

Loirooriol commented Mar 10, 2025

Uh oh!

bfgeek commented Mar 11, 2025

Uh oh!

Loirooriol commented Mar 11, 2025

Uh oh!

bfgeek commented Mar 11, 2025

Uh oh!

Loirooriol commented Mar 12, 2025

Uh oh!

[css-tables][css-sizing] What sizing keywords allow fixed table mode? #10937

[css-tables][css-sizing] What sizing keywords allow fixed table mode? #10937

Comments

Loirooriol commented Sep 23, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Situation

Example

Changes

bfgeek commented Sep 24, 2024

Uh oh!

Loirooriol commented Sep 24, 2024

Uh oh!

Loirooriol commented Sep 27, 2024

Uh oh!

Loirooriol commented Oct 5, 2024

Uh oh!

tabatkins commented Feb 12, 2025

Uh oh!

frivoal commented Feb 19, 2025

Uh oh!

css-meeting-bot commented Feb 19, 2025

Uh oh!

Loirooriol commented Feb 19, 2025

Uh oh!

Loirooriol commented Mar 10, 2025

Uh oh!

bfgeek commented Mar 11, 2025

Uh oh!

Loirooriol commented Mar 11, 2025

Uh oh!

bfgeek commented Mar 11, 2025

Uh oh!

Loirooriol commented Mar 12, 2025

Uh oh!

Loirooriol commented Sep 23, 2024 •

edited

Loading