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

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

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);

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

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

Same.

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)

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

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.

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

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

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

@tabatkins

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?)

@Loirooriol

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.

Bug 1956578: Preserve the min-width/min-height 'auto' value in getCom…

Preserve the min-width/min-height 'auto' value in getComputedStyle, f…

Bug 1956578: Preserve the min-width/min-height 'auto' value in getCom…

[css-sizing-3] aspect-ratio preserves auto minium size #11716

Navigation Menu

Repository navigation

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

css-meeting-bot commented on Mar 12, 2025

Loirooriol commented on Mar 13, 2025

bfgeek commented on Mar 26, 2025

dholbert commented on Mar 26, 2025

css-meeting-bot commented on Mar 26, 2025

dholbert commented on Mar 26, 2025

Loirooriol commented on Mar 26, 2025

dholbert commented on Mar 26, 2025

dholbert commented on Mar 26, 2025

Loirooriol commented on Mar 26, 2025

dholbert commented on Mar 27, 2025

dholbert commented on Mar 27, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions