[css-sizing] Resolved value of min size properties doesn't round-trip #11716

Loirooriol · 2025-02-14T21:37:27Z

<!DOCTYPE html>
<button>Click me</button>
<div id="target" style="width: 100px; aspect-ratio: 1; border: solid">
  <div style="height: 200px"></div>
</div>
<script>
var target = document.getElementById("target");
document.querySelector("button").addEventListener("click", () => {
  target.style.minHeight = getComputedStyle(target).minHeight;
});
</script>

There is interoperability among Gecko, Blink and WebKit: the resolved value of min-height doesn't round-trip. Awful.

This is because of CSS Sizing 3: https://drafts.csswg.org/css-sizing-3/#valdef-width-auto

For backwards-compatibility, the resolved value of this keyword is zero for boxes of all [CSS2] display types: block and inline boxes, inline blocks, and all the table layout boxes. It also resolves to zero when no box is generated.

This was fine because min-height: auto used to behave as zero. But CSS Sizing 4 went and changed that, without taking care of the resolved value: https://drafts.csswg.org/css-sizing-4/#aspect-ratio-minimum

In order to avoid unintentional overflow, the automatic minimum size in the ratio-dependent axis of a box with a preferred aspect ratio that is neither a replaced element nor a scroll container is its min-content size capped by its maximum size.

Hopefully it's not too late to change.

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

css-meeting-bot · 2025-03-12T17:02:09Z

The CSS Working Group just discussed [css-sizing] Resolved value of min size properties doesn't round-trip.

The full IRC log of that discussion

<TabAtkins> oriol: Sizing 3 changed the initial value of min size properties. Was '0', now is 'auto'
<TabAtkins> oriol: but for back-compat, on block/inline-blcok/inline/table, when you use gCS() 'auto' can serialize as 0
<TabAtkins> oriol: problem is Sizing 4 added aspect-ratio, and that makes 'auto' behave differently than 0 on those boxes
<iank_> q+
<TabAtkins> oriol: so if you use gCS() you see 0, but it has a different meaning. if you assign it back, the value changes.
<TabAtkins> oriol: so I propose if aspect-ratio is a non-initial value, the "auto can serialize to 0" hack isn't applied
<TabAtkins> oriol: hopefully webcompatible to change
<emilio> q+
<astearns> ack iank_
<TabAtkins> iank_: i'm a little concerned. we already had auto problem for flex/grid, min-size:auto was treated differently too
<TabAtkins> iank_: didn't roundtrip there either
<TabAtkins> iank_: a little concerned that if gCS() starts returning 'auto' things could break. scared about compat.
<TabAtkins> iank_: mostly because this is the default
<TabAtkins> iank_: but width/height also don't fully roundtrip anyway
<TabAtkins> emilio: i think they do in gecko, blink has some bugs with scrollbars
<TabAtkins> iank_: nah, height:auto vs explciit value changes definiteness, which affects %s
<astearns> ack emilio
<TabAtkins> iank_: so the idea that width/height roundtrips is a spec fiction
<TabAtkins> emilio: similar concern. i think in principle we should probably do this, but it does scare me compat-wise
<TabAtkins> emilio: can try it, see what happens
<TabAtkins> emilio: middle ground, maybe less scary, is doing this for layout boxes where we know it makes a difference, like for flex items
<TabAtkins> emilio: but still not sure it's worth
<TabAtkins> oriol: you mentioned flex items, for those it's alreayd the case, 'auto' serializes to 'auto'. it only serializes to 0 for block/inline/inline-block/tab le
<TabAtkins> oriol: so only *those* will change, and only when aspect-ratio is a non-initial value
<TabAtkins> astearns: out of time. can resolve to try fixing this roundtripping, or take it back to the issue. ian, emilio, preference?
<TabAtkins> iank_: can we put it at start of call nexte week? want to check some things. I didn't realize we were alreayd doing this for flex/grid items.
<TabAtkins> emilio: same. I think this makes it a bit less scary.
<TabAtkins> astearns: so let's take it back to the issue. we'll revisit next week.

Loirooriol · 2025-03-13T01:00:09Z

BTW, this is the logic in browsers.

https://searchfox.org/mozilla-central/rev/1678bc7ae853954854542c5dcddd14f6600bb9d0/layout/style/nsComputedDOMStyle.cpp#1804-1819

/**
 * This function indicates whether we should return "auto" as the
 * getComputedStyle() result for the (default) "min-width: auto" and
 * "min-height: auto" CSS values.
 *
 * As of this writing, the CSS Sizing draft spec says this "auto" value
 * *always* computes to itself.  However, for now, we only make it compute to
 * itself for grid and flex items (the containers where "auto" has special
 * significance), because those are the only areas where the CSSWG has actually
 * resolved on this "computes-to-itself" behavior. For elements in other sorts
 * of containers, this function returns false, which will make us resolve
 * "auto" to 0.
 */
bool nsComputedDOMStyle::ShouldHonorMinSizeAutoInAxis(PhysicalAxis aAxis) {
  return mOuterFrame && mOuterFrame->IsFlexOrGridItem();
}

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/css/properties/computed_style_utils.cc;l=747-753;drc=ebb421b7cdc02be3ee4abf49d6bad7646b3da9ab

CSSValue* ComputedStyleUtils::MinWidthOrMinHeightAuto(
    const ComputedStyle& style) {
  if (style.IsFlexOrGridOrCustomItem() && !style.IsEnsuredInDisplayNone()) {
    return CSSIdentifierValue::Create(CSSValueID::kAuto);
  }
  return ZoomAdjustedPixelValue(0, style);
}

https://searchfox.org/wubkat/rev/7d784721e440d04932945e2decb933720c4e0fc7/Source/WebCore/css/ComputedStyleExtractor.cpp#4206-4219

    case CSSPropertyMinHeight:
        if (style.minHeight().isAuto()) {
            if (isFlexOrGridItem(renderer))
                return CSSPrimitiveValue::create(CSSValueAuto);
            return zoomAdjustedPixelValue(0, style);
        }
        return zoomAdjustedPixelValueForLength(style.minHeight(), style);
    case CSSPropertyMinWidth:
        if (style.minWidth().isAuto()) {
            if (isFlexOrGridItem(renderer))
                return CSSPrimitiveValue::create(CSSValueAuto);
            return zoomAdjustedPixelValue(0, style);
        }
        return zoomAdjustedPixelValueForLength(style.minWidth(), style);

bfgeek · 2025-03-26T16:00:26Z

I'm ok with special casing aspect-ratio returning auto now.

dholbert · 2025-03-26T16:10:28Z

I'm ok with special casing aspect-ratio returning auto now

Same.

css-meeting-bot · 2025-03-26T16:13:15Z

The CSS Working Group just discussed [css-sizing] Resolved value of min size properties doesn't round-trip, and agreed to the following:

RESOLVED: When aspect-ratio is non-initial, then min-size:auto serializes as 'auto' in gCS() (rather than being censored to 0)

The full IRC log of that discussion

<TabAtkins> oriol: summarizing last time...
<TabAtkins> oriol: min-height and min-width have initial value of 'auto' but for back-compat gCS() returns 0 on all elements except flex and grid items
<TabAtkins> oriol: however, Sizing 4 added a new effect to 'auto', when you're using aspect-ratio
<TabAtkins> oriol: so it's not equivalent to zero on those elements
<TabAtkins> oriol: so my proposal was that if aspect-ratio had a non-initial value, gCS() would stay as 'auto' rather than becoming 0
<TabAtkins> oriol: Ian wanted to time to check on stuff, he just said he's okay with this special-casing, not sure if he means the proposal
<weinig> q+
<TabAtkins> TabAtkins: I read his comment as meaning your proposal, yeah
<TabAtkins> weinig: Is there a known compat concern with just returning auto always for min size properties?
<TabAtkins> weinig: do we think it'll actually break sites?
<TabAtkins> oriol: Not sure
<astearns> ack weinig
<TabAtkins> oriol: Possibly the editors that said it originally have an idea. but changing that seems riskier.
<TabAtkins> oriol: so not suggesting changing that for now, can do another issue to investigate
<TabAtkins> dbaron: I think changing a behavior that's small-integer number of years old is much less scary than changing a 20yo behavior
<TabAtkins> weinig: fair enough, just wanted to mention it
<astearns> ack fantasai
<TabAtkins> fantasai: yeah, because this affects the initial value, which is what you'll usually get back for it, and for a property that's 20+ years old
<TabAtkins> fantasai: we didn't do a compat analysis, but we suspected there would be a problem
<dbaron> I'm dating it back to when getComputedStyle was interoperable, which I think is newer than the min-width/min-height properties! :-)
<TabAtkins> astearns: so the proposed resolution si that when aspect-ratio is non-initial, then min-size:auto serializes as 'auto' in gCS() (rather than being censored to 0)
<TabAtkins> dholbert: in both axises, right?
<TabAtkins> oriol: yes
<TabAtkins> RESOLVED: When aspect-ratio is non-initial, then min-size:auto serializes as 'auto' in gCS() (rather than being censored to 0)

dholbert · 2025-03-26T20:55:14Z

One edge case that we need to clarify...

Our above-quoted resolution was conditioned on When aspect-ratio is non-initial

What about non-initial values of aspect-ratio that behave like the initial value? (The spec says that "degenerate" aspect ratios (those involving 0 or infinity) behave the same as the initial value "and, generally, won’t do anything").

I tend to think those should behave as the initial value for this new behavior as well (i.e. we should still return 0 from getComputedStyle if the element has a specified-but-degenerate aspect-ratio). The point of our resolution here is that we want getComputedStyle(elem).minWidth and minHeight to return the string "auto" in the cases where there's a meaningful aspect-ratio and the automatic minimum size is potentially going to do something interesting (different from what 0 would do).

Loirooriol · 2025-03-26T23:25:44Z

I would rather keep it simple and just check whether aspect-ratio computes to auto.

Otherwise: even if the spec doesn't say it in these terms, it can be said that auto <ratio> behaves as auto on a replaced element with a natural aspect ratio. So should that also resolve min-width: auto to zero, then? It starts becoming a bit annoying to implement for no real benefit.

dholbert · 2025-03-26T23:29:34Z

That's fair, I'm happy with that (and that matches the letter of the resolution, so no change needed).

One other edge case: what should we do for elements in a display:none subtree that happen to have aspect-ratio: 1/1 for example?

I tend to think we should continue returning 0 for those elements (as we do now) instead of needing to check their aspect-ratio to decide whether we should return auto. This is what happens for flex/grid items in a display:none subtree (since strictly speaking they're not actually flex or grid items if they don't generate a box). And in Gecko at least, that makes this much easier, since we don't have the styles readily available for elements in display:none subtrees. (Maybe we can look them up if we need to, but I forget how offhand.)

dholbert · 2025-03-26T23:30:21Z

(I'm writing a WPT for this now, BTW, hence why I'm thinking about these edge cases. :) )

Loirooriol · 2025-03-26T23:34:18Z

Yeah, seems reasonable to keep the "It also resolves to zero when no box is generated" even if aspect-ratio is not auto.

dholbert · 2025-03-27T00:04:50Z

I've got a WPT posted, for now called "css/cssom/getComputedStyle-resolved-min-size-auto.html", in this phabricator review for Mozilla's bug on implementing this spec change.

It notably does assume that boxes in display:none subtrees all return 0 as the resolved min-width/min-height for "auto", regardless of their aspect-ratio, as I suggested above. If that's controversial or feels like it needs an additional csswg resolution, I'm happy to rename the test to .tentative or remove that part for the time being.

(@tabatkins @fantasai do you think we need to go back to the WG on that for another resolution or does that feel like a reasonable enough extension of what we resolved combined with existing behavior for flexbox/grid?)

dholbert · 2025-03-27T00:11:01Z

Ah right, I didn't initially realize that @Loirooriol's quote was in fact a spec quote.

The auto length spec text ends its "For min-width/min-height..." section with

It also resolves to zero when no box is generated.

...which handles the display:none case that I was asking about. So I think we're all good, no further clarification needed on that.

…putedStyle, for elements with non-default 'aspect-ratio'. r=TYLin This is the behavior that was resolved on in w3c/csswg-drafts#11716 I'm including a WPT that exercises a bunch of different cases where 'auto' is or isn't preserved in getComputedStyle. Differential Revision: https://phabricator.services.mozilla.com/D243234

…or elements with non-default 'aspect-ratio'. This is the behavior that was resolved on in w3c/csswg-drafts#11716 I'm including a WPT that exercises a bunch of different cases where 'auto' is or isn't preserved in getComputedStyle. Differential Revision: https://phabricator.services.mozilla.com/D243234 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1956578 gecko-commit: 6b9e820b1f3df0b5447c14e0a5a9af2b160cd09b gecko-reviewers: TYLin

…putedStyle, for elements with non-default 'aspect-ratio'. r=TYLin This is the behavior that was resolved on in w3c/csswg-drafts#11716 I'm including a WPT that exercises a bunch of different cases where 'auto' is or isn't preserved in getComputedStyle. Differential Revision: https://phabricator.services.mozilla.com/D243234

Loirooriol added Agenda+ css-sizing-3 Current Work css-sizing-4 labels Feb 14, 2025

Loirooriol changed the title ~~[css-sizing] Resolved size of min size properties doesn't round-trip~~ [css-sizing] Resolved value of min size properties doesn't round-trip Feb 14, 2025

Loirooriol added the cssom-1 Current Work label Feb 16, 2025

css-meeting-bot removed the Agenda+ label Mar 26, 2025

fantasai added Closed Accepted by CSSWG Resolution Needs Edits labels Mar 26, 2025

chromium-helper mentioned this issue Mar 26, 2025

[css-sizing] Resolved value of min size properties doesn't round-trip chromium-helper/csswg-resolutions#728

Closed

mozilla-apprentice mentioned this issue Mar 26, 2025

[css-sizing] Resolved value of min size properties doesn't round-trip mozilla/wg-decisions#1840

Closed

moz-wptsync-bot mentioned this issue Apr 1, 2025

[Gecko Bug 1956578] Preserve the min-width/min-height 'auto' value in getComputedStyle, for elements with non-default 'aspect-ratio'. web-platform-tests/wpt#51748

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[css-sizing] Resolved value of min size properties doesn't round-trip #11716

[css-sizing] Resolved value of min size properties doesn't round-trip #11716

Loirooriol commented Feb 14, 2025 •

edited

Loading

css-meeting-bot commented Mar 12, 2025

Loirooriol commented Mar 13, 2025

bfgeek commented Mar 26, 2025

dholbert commented Mar 26, 2025

css-meeting-bot commented Mar 26, 2025

dholbert commented Mar 26, 2025 •

edited

Loading

Loirooriol commented Mar 26, 2025

dholbert commented Mar 26, 2025

dholbert commented Mar 26, 2025

Loirooriol commented Mar 26, 2025

dholbert commented Mar 27, 2025 •

edited

Loading

dholbert commented Mar 27, 2025 •

edited

Loading

[css-sizing] Resolved value of min size properties doesn't round-trip #11716

[css-sizing] Resolved value of min size properties doesn't round-trip #11716

Comments

Loirooriol commented Feb 14, 2025 • edited Loading

css-meeting-bot commented Mar 12, 2025

Loirooriol commented Mar 13, 2025

bfgeek commented Mar 26, 2025

dholbert commented Mar 26, 2025

css-meeting-bot commented Mar 26, 2025

dholbert commented Mar 26, 2025 • edited Loading

Loirooriol commented Mar 26, 2025

dholbert commented Mar 26, 2025

dholbert commented Mar 26, 2025

Loirooriol commented Mar 26, 2025

dholbert commented Mar 27, 2025 • edited Loading

dholbert commented Mar 27, 2025 • edited Loading

Loirooriol commented Feb 14, 2025 •

edited

Loading

dholbert commented Mar 26, 2025 •

edited

Loading

dholbert commented Mar 27, 2025 •

edited

Loading

dholbert commented Mar 27, 2025 •

edited

Loading