Re: [csswg-drafts] [css-sizing] How to transfer intrinsic keywords via aspect ratio? (#11236)

The CSS Working Group just discussed `[css-sizing] How to transfer intrinsic keywords via aspect ratio?`, and agreed to the following:

* `RESOLVED: for the final step in determining natural sizes, use the determined aspect-ratio to coerce the block size to match`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> iank_: replaced elements ahve three things<br>
&lt;TabAtkins> iank_: natural width, natural height, natural aspect ratio<br>
&lt;TabAtkins> iank_: you can have a natural widht of 20, height of 10, and ratio woudl be 2/1<br>
&lt;TabAtkins> iank_: it used to be possible (in svg, at least) to have the natural sizes not match the aspect ratio<br>
&lt;TabAtkins> iank_: this is more of a problem now with aspect-ratio proeprty<br>
&lt;TabAtkins> iank_: can have natural width/height of 20px and 10px, and an aspect-ratio proeprty of 1/1<br>
&lt;TabAtkins> iank_: so what happens<br>
&lt;TabAtkins> iank_: there's places where you're sizing a replaced element where you only llook at natural sizes, but then the aspect ratio comes in (to transfer min-height to a width, for example), and they're disjoint<br>
&lt;TabAtkins> iank_: there's a step which normalizes the natural sizes and aspect ratio<br>
&lt;TabAtkins> iank_: I think simplest answer is we coerce the natural sizes to match the aspect ratio<br>
&lt;TabAtkins> iank_: so if your natural sizes are 20px/10px, and aspect-ratio is 1/1, we coerce the block size to match and it becomes 20px/20px natural size<br>
&lt;TabAtkins> iank_: we have this normalization step for SVG. you can specify only a natural width, no natural height, yes natural aspect-ratio, adn we harmonize the three together<br>
&lt;TabAtkins> iank_: so I think we should do the same when all three are specified but disagree<br>
&lt;TabAtkins> astearns: when you say you don't care, you example had us adjusting the block natural size<br>
&lt;TabAtkins> astearns: is the other option adjusting inline size...?<br>
&lt;TabAtkins> iank_: you could adjust block/inline/width/height<br>
&lt;TabAtkins> fantasai: or larger/smaller<br>
&lt;TabAtkins> iank_: mild preference for adjusting block size<br>
&lt;TabAtkins> fantasai: I think if we do this fixup, adjusting the block size makes sense<br>
&lt;TabAtkins> fantasai: in most layout algorithms block size is the dependent size<br>
&lt;TabAtkins> fantasai: aspect-ratio in general works that way, it prioritizes that dependency direction<br>
&lt;TabAtkins> oriol: yeah in my second comment, i say we adjust the block size when transferring. so i'd prefer to be analogous<br>
&lt;TabAtkins> +1<br>
&lt;TabAtkins> dholbert: makes sense about aspect-ratio proeprty<br>
&lt;TabAtkins> dholbert: without aspect-ratio i think this doesn't matter? SVG says to derive the intrinsic aspect-ratio from the intrinsic sizes if they're present, ignoring the view-box. Is that right, Ian?<br>
&lt;TabAtkins> iank_: I thought there was a case...<br>
&lt;TabAtkins> iank_: viewbox aspect ratio fo 1/1, width=10 height=0<br>
&lt;TabAtkins> iank_: in that case the natural sizes are 10/0<br>
&lt;TabAtkins> dholbert: right, the 0 is equivalent to not having a size, not worried about that corner case<br>
&lt;TabAtkins> iank_: okay, then yeah i think it's otherwise correct, we can discuss offline if necessary<br>
&lt;TabAtkins> iank_: a little icky with a 0 width or height, i think we have some compat for it rendering as 0 height, and this would change it to non-zero<br>
&lt;fantasai> TabAtkins: So ignoring SVG complications, we can limit this to just aspect-ratio property?<br>
&lt;TabAtkins> iank_: I think we want this for aspect ratios generally<br>
&lt;TabAtkins> iank_: this is part of the nromalization step, svg's a-r comes from the width/height, and only if that doesn't exist does it come from the viewbox<br>
&lt;TabAtkins> iank_: so now we'll take aspect-ratio property into account<br>
&lt;TabAtkins> iank_: this can also happen in contain-intrinsic-size, it gives a natural width/height<br>
&lt;TabAtkins> iank_: so this can't just be for the aspect-ratio property, need fixup to work consistently<br>
&lt;dholbert> this is the SVG spec text I'm remembering RE getting aspect-ratio from width/height (if present), and falling back to viewBox ( https://svgwg.org/svg2-draft/coords.html#SizingSVGInCSS ).   Just noting for reference; I'm on board with what IanK just described<br>
&lt;TabAtkins> astearns: so this just applies to repalced?<br>
&lt;TabAtkins> [some confusion, but yes]<br>
&lt;TabAtkins> iank_: proposed resolution: for the final step in determining natural sizes, use the determiend aspect-ratio to coerce the block size to match<br>
&lt;TabAtkins> astearns: questions? objections?<br>
&lt;TabAtkins> RESOLVED: for the final step in determining natural sizes, use the determined aspect-ratio to coerce the block size to match<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11236#issuecomment-2718502765 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 16:46:07 UTC