Re: [csswg-drafts] [css-sizing] Resolved value of min size properties doesn't round-trip (#11716)

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

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


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


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

Received on Wednesday, 12 March 2025 17:02:11 UTC