[css-sizing-4] Should aspect-ratio affect the intrinsic size?

[cbiesinger]

https://drafts.csswg.org/css-sizing-4/#aspect-ratio

If an aspect-ratio is used, should it also affect the intrinsic size of a box? That is, should:

be 0px wide or 100px?

@bfgeek @tabatkins @fantasai

[AmeliaBR]

For SVG, the intrinsic aspect ratio is defined as distinct from the intrinsic width and height. An element can have an intrinsic height, an intrinsic aspect ratio, and still no intrinsic width:

https://svgwg.org/svg2-draft/coords.html#SizingSVGInCSS

However, in that case, the CSS default sizing algorithm kicks in to calculate the size of the other dimension. But different sizing algorithms can apply in other contexts (e.g., flexbox).

Also see this HTML issue about how browsers don't currently expose intrinsic / “natural” sizes consistently for images: whatwg/html#3510

[cbiesinger]

Looks like images don't let the aspect ratio affect the intrinsic size, so aspect-ratio probably shouldn't either:
http://plexode.com/eval3/#s=aekVQXANJVQMbAx1KTkgBVFNEHj2PVVVRVBsQEFdKQg9RTUJERklQTUVGUw9EUE4QEhYRngGDHrwRAXidA05CWQ6CGwFOSk8Ot09VRtSeHwNeAA==

[fantasai]

It should be 100px wide. Both the min-content and max-content size of an image with one fixed dimension and an aspect ratio are calculated from those two measures. See https://www.w3.org/TR/CSS2/visudet.html#inline-replaced-width and https://drafts.csswg.org/css-sizing-3/#intrinsic-sizes

[fantasai]

The fact that the image is wider than its max-content size when shrinkwrapped proves that the max-content size currently returned in layout is wrong. A shrinkwrapped box should never be wider than its max-content size, that is the maximum size of the formula.

[AmeliaBR]

I agree that the definition of “intrinsic sizes” in https://drafts.csswg.org/css-sizing-3/#intrinsic-sizes is rather confusing, because we've got a bit of circular logic:

• First it says “ min-content size and max-content size are collectively referred to as the intrinsic sizes”
• Then it gives instructions for how to calculate max-content size for an element that doesn't have a defined intrinsic size.

It might be better to rewrite so the initial definitions is the “intrinsic max-content size” (which would be independent of aspect ratio), and then say the actual max-content size is that value if it is a definite value, or the result of the algorithm otherwise.

That would also re-align the definition of “intrinsic size” for layout with the one from CSS images & SVG.

[fantasai]

@AmeliaBR I think your comment is #4961

[tabatkins]

Thinking about this and having off-list discussions with some implementors, @fantasai and I have come to some conclusions that we'd like to get WG review on.

First, some design constraints:

• Intention of 'stretch' and 'fit-content' was to replicate the fill-container and shrink-to-fit behavior of CSS2.
• 'min-content' and 'max-content' were defined to be the minimum and maximum range of 'fit-content', respectively.
• From authoring perspective, barring any overriding sizing constraints, having 'width: min-content' yield the same size as sizing under a min-content constraint makes sense.
• 'aspect-ratio' + 'min-size: initial' on a replaced element should replicate the current behavior of replaced elements with that intrinsic aspect ratio

Additionally, we want 'aspect-ratio' + 'min-size: auto' to have 'auto' resolve to the content height of a non-replaced element per #3268 (see minutes), so that the used height/width can violate the specified aspect-ratio if needed to prevent overflow.

However, current implementations treat 'min-content' and 'max-content' as the natural size of an image, which is not consistent with the design constraints above:

>
<img class=float src="https://placehold.it/50x50">
<img class=min-content src="https://placehold.it/50x50">
<style>
body { width: 1px; }
.float { height: 100px; float: left; }
.min-content { height: 100px; width: min-content; }

An image with a naturalWidth of 50px, a 1:1 ratio, and "height: 100px" has, in implementations, a different width when floated in a zero-width container vs when it's assigned "width: min-content", which is wrong per the principles above, and not the behavior we'd want for non-replaced elements with 'aspect-ratio'.

Implementors we discussed with from Blink and Gecko are optimistic that this behavior could be changed: replaced elements relying on an explicit non-prefixed 'min-content' or 'max-content' should be rare-to-nonexistent, since these relatively-obscure keywords grant no new abilities to replaced elements. So first, we want to verify with the CSSWG that this behavior can be changed, and that the spec is fine as-is.

---

Assuming the existing definitions are acceptable, we are missing the ability to explicitly restrain one axis of a non-replaced element with an aspect-ratio to its widest atomic inline (min) or longest line of unforced content (max) or, more significantly, its content-based block size. We have defined 'min-height/width: auto' to have this functionality (see earlier remarks about #3268), but it has additional magic such as resolving to zero on scroll containers, so some additional keyword is still needed if we want to represent this behavior unconditionally.

If we agree that such keywords would be useful for authors, we propose 'min-intrinsic' and 'max-intrinsic' for these keywords. These would match the concept already named “intrinsic” in 'contain-intrinsic-size' as well (since it is also prior to applying aspect-ratio). Either way, we can adopt such distinct terminology in the specs at least, to resolve #4961.

~ @tabatkins + @fantasai

[bfgeek]

What does:

<div id="target" style="
    min-width: max-content;
    height: 100px;
    overflow: hidden;
    aspect-ratio: 1/1;">
  <div style="width: 150px;">div>
div>

... target resolve to above? 150px or 100px ?

[bfgeek]

(above is conditioned on):

<div style="
    min-width: max-content;
    height: 100px;
    aspect-ratio: 1/1;">
  <div style="width: 150px;">div>
div>

Resolving to 150px.

[fantasai]

overflow does not change the interpretation of max-content, so the two of them are necessarily the same.

Going from the notes in #5032 (comment) ...

If we had width: max-content; height: 100px; aspect-ratio: 1/1, max-content would resolve to 100px, because max-content is the upper bound of the shrink-to-fit (fit-content) width, and setting the width value aside because we're calculating it, the width range of shrink-to-fit is 100px to 100px here. So min-width: max-content; height: 100px; aspect-ratio: 1/1 would have to be the same: both the width (which is auto) and the min-width (which is max-content) resolve based on the aspect ratio.

I think that's the correct logic? We can consider some other logic, but, afaict that's what's outlined in #5032 (comment)

[cbiesinger]

(I think the overflow comment was in regards to https://drafts.csswg.org/css-sizing-4/#aspect-ratio-minimum)

[bfgeek]

So there are two different potential models min-content, and max-content sizes, currently both definitions resolve to the same thing (I believe) but will different when considering aspect ratio.

1. An element with width: min-content is the same size the element under a min-content constraint.
2. The value of min-content is the same size as the element under a min-content constraint.

<div style="height: 100px; aspect-ratio: 1 / 1; width: max-content;">
  <div style="display: inline-block; width: 150px;">div>
  <div style="display: inline-block; width: 150px;">div>
div>


<div style="height: 100px; aspect-ratio: 1 / 1; width: max-content; min-width: 0;">
  <div style="display: inline-block; width: 150px;">div>
  <div style="display: inline-block; width: 150px;">div>
div>


<div style="height: 100px; aspect-ratio: 1 / 1; min-width: max-content;">
  <div style="display: inline-block; width: 150px;">div>
  <div style="display: inline-block; width: 150px;">div>
div>


<div style="height: 100px; aspect-ratio: 1 / 1; min-width: max-content;">
  <div style="display: inline-block; width: 75px;">div>
div>

Option 1

min-content and max-content just consider the aspect-ratio (not their children) in this case.

For this to work the current definition of the aspect-ratio-minimum is incorrect it likely wants to refer to the min-intrinsic size instead (described above).

Things like flexbox etc, will also potentially need to refer to the min-intrinsic size instead? E.g. here?

	max-content	width	min-width	final size
Case A	100px	100px	150px	150px
Case B	100px	100px	0px	100px
Case C	100px	100px	100px	100px
Case D	100px	100px	75px	100px

Option 2

min-content and max-content consider both the aspect-ratio and their children if the aspect-ratio-minimum applies.

E.g. if there is an aspect-ratio present, the min-content, and max-content sizes are the resolved size from the aspect-ratio, then apply the content sizes.

	max-content	width	min-width	final size
Case A	300px	300px	150px	300px
Case B	300px	300px	0px	300px
Case C	300px	100px	300px	300px
Case D	75px	100px	75px	100px

The aspect-ratio-minimum can still use the min-content definition here, (and likely other places like flex?)

(I might update this in the morning, some things might be wrong).

[cbiesinger]

And another question: Should min-content be affected by the aspect-ratio even if there is an explicit size in that axis? E.g.:

<div style="width: 100px; height: 100px; aspect-ratio: 1/1; min-width: min-content;">
  <div style="width: 200px;">div>
div>

Should the width be 100px (from the aspect-ratio), or 200px (from the contents)?

[fantasai]

@cbiesinger In that example if we go with the logic in #5032 (comment) then min-width: min-content will resolve as the size under min-content constraint, which considers height: 100px and the aspect ratio to yield min-width: 100px. The final width would then be 100px. (If we decide instead that min-content always takes the content’s size, then it would be 200px.)

I think one principle we need to make more explicit here is that resolving keyword sizes in a given axis requires ignoring all sizing properties in that axis, but might take into account sizing properties in the other axis due to an interdependency caused by layout rules or aspect-ratio. The min/max clamps are applied after all sizing properties in that axis are resolved to a length.

[fantasai]

@bfgeek So wrt Option 2... if we take the natural size of an image as analogous to the content size of a non-replaced element and maintain the correspondendance of min-content/max-content to the min/max extremes of shrink-to-fit, then Option 2 would break the current handling of floating images. Assuming we want to maintain the shrink-to-fit correspondence, we could take your interpretation only if we decide to break the content-size=natural-size analogy. Which is an interesting possibility! So, if I'm understanding correctly, option 2 could be:

• min-content/max-content/fit-content on replaced elements defers to the aspect ratio rather than maxxing with natural size, to maintain consistency with current shrink-to-fit behavior.
• min-content/max-content/fit-content on non-replaced elements takes the larger of the aspect-ratio-derived size (if applicable) and the content-based size

But the problem with this is that it would give unexpected results for shrink-to-fit boxes. Consider your cases A-D as a float. The min-content size of the float would be 150px: if we put the float in a narrow box, it would not shrink below 150px, the size of its largest unbreakable content. This is fine, and probably what an author would expect. But if we place the float into a large container, it takes its max-content size, which would be 300px. This is not what an author would expect: they would expect the float to be its aspect-ratio-constrained width (floored by the min-content width if necessary), but no larger than that.

This suggests that either (a) both min-content and max-content work off the min-content size and AR (probably confusing?) or (b) we give up and go back to Option 1, where the shrink-to-fit size of a non-replaced ratio-having element is solely determined by its ratio and the size in the other dimension (tho still floored by the 'min-width: auto', giving a width of 150px in this case) or (c) max-content no longer represents the max extreme of shrink-to-fit/fit-content, but is something else entirely??

[In both of (a) and (b) the behavior of min-content and max-content are identical to each other for any element with an aspect-ratio, but we can't figure out a way to make them different without falling to the unintuitive behavior outlined above.]

Fwiw, our current inclination is to stick with Option 1 / #5032 (comment) Further thoughts?

~@fantasai and @tabatkins

[css-meeting-bot]

The CSS Working Group just discussed [css-sizing-4] Should aspect-ratio affect the intrinsic size?, and agreed to the following:

• RESOLVED: Min-content and max-content keywords represent size of element at top and bottom extremes of fit-content or shrink-to-fit sizing and therefore match size it would take under a min or max constraint when taking aspect-ratio into account

The full IRC log of that discussion

Topic: [css-sizing-4] Should aspect-ratio affect the intrinsic size?
github: https://github.com//issues/5032
https://github.com//issues/5032#issuecomment-639874263
fantasai: Here's summary comment for Tab and I ^
fantasai: I guess people should read it
stearns: I think people can read and listen to a summary
fantasai: Question was for min-content and max-content size does a-r impact what they resolve to
fantasai: We went through what are the design constraints. One is currently on an image with a-r if you spec size as auto and height in one axis other axis responds.
fantasai: Take a 1x1 image naturally 200px. If you make it 100px tall it's 100px wide with auto width
fantasai: Intention of the stretch and fit keywords was replicate behavior of css 2 blocks. Fit-content is shrink to fit and stretch is fill the box. Tables were shrink and now can ask to fill container.
fantasai: We then added min and max-content which is min and max range of fit-content. There's a min and max content range. Intended to map to extremes of fit content size
fantasai: Authoring PoV seems having width min-content has same sizing as if sized under min-content constraint. Float is shrink to fix in a 0 size container it's as small as it can be and that's min-content size. width:min-content is same result
fantasai: Last constraing is a-r property if you apply to replaced element it should have same behavior. An iframe with a-r behaves same as SVG with an a-r
q?
fantasai: Those are design constraints.
fantasai: Resolution of #3268 which was how to have strict a-r vs allow content to stretch box. Example is you have 1x1 cards, fill with text, text is too big and want card to grow. BUt sometimes you want strict. Author an choose if they want strong contraint
q+
fantasai: Current resolution to do that is when you spec a-r initial value of min-width or min-height being auto, auto resolves to content-height. That allows it to like any min-size blow out a-r. That's in #3268 so assuming we want that to continue it's a constraint.
fantasai: Thought through the constraints.
ack Rossen_
Rossen_: I don't want to cut in front of the solution. but as I'm getting up to speed I'm a strong advocate to keep a-r or the dependencies of min or max content on the cross axis; keep a-r away from contributions to min or max content.
Rossen_: Instead threat similar to the way we do % in a shrink to fit case where resolve to 0 and only content contribution is those that are computable
Rossen_: To me a-r is another form of % where insead of looking at container, example width axis, you're looking at cross axis. So we don't take other dependencies like this one for max-content.
Rossen_: But that's me talking before you spoke of conclusion
fantasai: Taking that comment; there's 2 sizing concepts. Min-content size of item which is size it reports when you give it a min-content keyword. Other is min-content contribution which is what it contributes tot he parent. If it's insid ea float what size does it ask the float to be.
fantasai: Take. png image that's 100x100, height is set to 50px. We can argue what width:min-content is but we can't argue if it contributes 100px b/c breaks the web. TO be consistent with what images do right now has to account for a-r
fantasai: We cannot change that. This is about what is size returned when you as for the keyword
Rossen_: Prop to separate behavior or keep consistent?
Can we go back to fantasai's explantation, and get off the detour?
jensimmons, how is that a detour?
fantasai: Consistent. Back tot he image example if you ask for width-min-content on the image. The min-content contribution is 50px b/c that's what it has to be. Question is does it return 100px with is natural or 50px which is size it would have to take.
fantasai: Currently impl return 100px. We're aguring should be 50px to match size it would take if sized under min-content constraint and reported contribution
AmeliaBR: Argument is this is a breaking change but b/c min and max content keywords are fairly new and this is a bit of an edge case it should be okay to correct this as if it was a bug in original spec impl
fantasai: Yeah. Spec is clear that's intented output. This change would only effect replaced elemetns with an a-r. Current before on non-replaced elements doesn't change. For images with an a-r whatever behavior you wanted from min or max content you would get from auto so author has no reason to use this keyword
AmeliaBR: You talked with people on impl teams and people are willing to change?
fantasai: Talked to Blink and Gecko and they seemed to believe it's possible
AmeliaBR: Webket devs on call that disagree?
smfr: Probably happy to, don't know enough to say definitively
AmeliaBR: For basic spec I agree having these keywords behave same way as logical concept where they respect a-r that's the ideal spec definition. Unless web-compat concern I'd say change
Rossen_: I think I'm okay with proposal and it aligns with my previous description. Question; what happens for align-stretch cases or align-height:min-content
Rossen_: Are there cases where you will be asked to comput a-r in current constraint while looking at cross size in order to compute defined height and get a-r out of it?
Rossen_: Or is it only when height or min-height is defined
??: IN block min and max content don't do anything. THere's an issue to change that pending dbaron input
s/??/cbiesinger/
Rossen_: So only time this takes effect is if cross-axis is fixed
cbiesinger: Yes
Rossen_: Reasonable
fantasai: Do we want to pause and resolve on that before we go to second part of issue?
+1
stearns: I'm hearing a lot of this sounds possible. Can you summerise?
fantasai: Prop: Min-content and max-content keywords represent size of element at top and bottom extremes of fit-content or shrink-to-fit sizing and therefore match size it would take under a min or max constraint
stearns: And it would match contraint when taking specified aspect ratio into account
fantasai: Yes
dbaron: Starting to think, does this introduce problems when both width and height use these keywords?
fantasai: Currently the rules; need to clarify how the interact. auto, auto for example a-r only take effect in block axis. Fixed height and auto width a-r does width. If both are auto or a content keyword we resolve width and use a-r to get height
dbaron: A little worried about interesting cases where height is fixed but max-height that's min-content and could constrain off of fixed value. DOn't nkow
cbiesinger: And it's because that we don't support min-content in block axis
fantasai: One of the rules we thought of is when you transfer sizing constraint through a-r you don't transfer an indefinite size
fantasai: That's not yet explicit in spec
cbiesinger do you have an issue number for this?
fantasai: I think we need that regardless
dbaron: If you think it's okay that's fine. Haven't thought through fully
fantasai: If some kind of difficutly in a combination of keywords and a-r we should address it there instead of changing global. I haven't thought through every possible combo of sizing algo. I think we should start here
stearns: Other discussion about the resolution or objections?
AmeliaBR: Sounds like second possible resolution about a-r is ignored if transferring indefinite size
AmeliaBR: Just saying 2 resolutions
stearns: Not hearing objections to first
RESOLVED: Min-content and max-content keywords represent size of element at top and bottom extremes of fit-content or shrink-to-fit sizing and therefore match size it would take under a min or max constraint when taking aspect-ratio into account
stearns: Do you want to talk about AmeliaBR second item or something else on this?
fantasai: Something else on this issue.
fantasai: Now we'll get into instractions with other resolution
fantasai: We have definitions but we also have 2 different behaviors
fantasai: I have a non-replaced element with fixed width 100px and a-r of 1 to 1.
fantasai: If content is too much I want it to stretch out the size of the box and not be 1x1
fantasai: #3268 we said you get that when min-height is auto
fantasai: Means min-height:auto can't respect a-r. It's job is not to in order to create min-height value that's larger
fantasai: So keyword auto sometimes has this functionality. When it has this functionality no keyword except auto grants it. We have behavior we can't represent unconditionally
fantasai: Also have concept that's different than min/max-content
fantasai: May or may not need separate keyword. Definitely need concept in spec.
fantasai: tabatkins and I suggested we should go through specs and split concept of while respecting a-r and while not b/c we have min/max-content after keywords. Introduce 2 new terms to ignore the constraint.
fantasai: Given we use intrinsic in contain-intrinsic-size we propose min/max-intrinsic.
q+
fantasai: Could be a keyword to width and height properties. Certainly need terms in the specs and audit all the layout specs
fantasai: That's the direction we're going in and wanted to ask WG what they think.
ack florian
florian: As you stated, this is complicated. I thought previous resolution only made difference for replaced. This only matters for non-replaced elements. Therefore I'm not sure why separate keywords. Do we?
fantasai: There is slightly different behavior. I'm not sure if we need one. Behavior difference is in non-replaced case in order to be consistent with replaced min/max-content keywords have to respect a-r.
florian: What does it mean for non-replaced to honor a-r on block axis min-content
fantasai: Have a-r. Apply to non-replaced block it should apply a-r to that
fantasai: Supposing I have 1x1 box. Have too much content give a fixed width of 100. Height is auto which means takes height from a-r width. Sees it's 1x1 with 125px so height is 125px. Min-height looks up height of content. min-height wins. Will be 125px tall. In order to get that auto has to resolve to content height which is not same as min or max height b/c they're using the a-r
q+
fantasai: Height:min-content or max-content would resolve to 100px. min-height min-content will not give you the behavior of grow to fit. min-height: auto we decided should
fantasai: Two concepts. Min-height:auto has the extra magic. If we want a content for always the content-baseline height we need a keyword
florian: I thought about previous for only replaced elements. If we're not doing that we need what you said at least as a concept and maybe a keyword
ack dbaron
dbaron: Haven't fully processed layout. Naming aspect comment. Way we ended up with min/max-content was there was originally a concept in spec we called intrinsic-size and impl called that. I prop min-intrinsic size, people thought too complex and we used content instead of intrinsic
dbaron: Then seems weird to me is that they meant the same thing but then we introduced contain-instrinsic-sze when we had named it out of the language. Seems odd for intrinsic to mean something different instead of a word to describe the difference.
fantasai: I'm happy to take alternative names. I think it makes sense to make sure contain-intrinsic-size renamed accordingly. Another name would make it easier to audit spec. Would be great to have another term.
fantasai: Could for with natural-size which I think is in HTML
ack AmeliaBR
q+ to disagree with AmeliaBR
AmeliaBR: Leaving aside naming issue; I think to get this behavior where a-r is ignored in order to contain overflow- I don't think that should be default of min-height and not what min-height:auto does. Would be cnofusing for those starting to use a-r. Works fine with small text but once have real world text you have an element stretching out to contain overflow
AmeliaBR: I think that's confusing default behavior that a-r is ignored. Regarding min-height it would mean auto does respect the a-r and we need a new keyword for min-height to contain the content
ack florian
florian, you wanted to disagree with AmeliaBR
florian: I disagree I think. We have had that discussion and previously resolved. I think we can continue on this topic without re-opening. If we're re-opening I disagree because it means you get overlapping content by default and authors need to deal with people resizing text. It's much safer
AmeliaBR: We have this with abs height. A min-height:auto doesn't override that. If you define height in terms of width and a-r that's less powerful then define height
I joined a little late which issue are we currently on?
florian: If we're going to add a keyword we can discuss that separately. Maybe we re-open the other issue. I disagree but I don't want to hijack. Topic is getting a keyword that would do this. You're wanting a keyword to do this, if it's the default or not is separate
Iank: 5032
fantasai: Depends on if you set overflow. If it's visible we have the content behavior. If you have scroll it resolves to 0. But that's the other issue, as florian said. #3268
stearns: Make sense to open a sep issue about these keywords, do research on these keywords in various layout models, and not resolve today. This prop doesn't seem quite fleshed out for a resolution. not hearing objections to direction
AmeliaBR: fantasai talked about auding specs to see which uses should or shouldn't be a-r dependent. Nice to have that list
fantasai: If we add keywords or not key is to name them becuase we do have two concepts. Here it's about we need terms. I think term proposals are min/max-intrinsic and min/max-natural. We can open sep on terms
florian: I would argue against intrinsic b/c I would expect the inverse between intrinsic and content.
+1 to what florian just said
stearns: Let's open a new issue and discuss what names we might use on GH and discuss if we need to add them as values in CSS or in spec terms.
cbeis...: Previous was to change min-content definition
fantasai: Keep it as is in spec right now
stearns: Let's close this discussion.
s/Keep/Prop was to keep/
stearns: Should we go back to transfering sizes?
AmeliaBR: Nothing to argue on that. fantasai said something isn't currently clear in spec. Up to her about if it should be clarified at this point
fantasai: Transfering in general I think content-base size shouldn't go through a-r. But I think if you have shrink to fit a-r should have some effect. I have to come up with wording but i can open an issue
s_b/c I would_b/c if we have both, I would_
AmeliaBR: Okay. We'll follow up
stearns: Anything more on this issue?
s/fit/fit with everything initial value,/

[bfgeek]

@fantasai @tabatkins

But if we place the float into a large container, it takes its max-content size, which would be 300px. This is not what an author would expect: they would expect the float to be its aspect-ratio-constrained width (floored by the min-content width if necessary), but no larger than that.

So the difference with "Option 2" is that we aren't actually using STF sizing in the float case. If we have a width: auto, with an aspect-ratio, and a definite height, STF doesn't apply. I.e.

1. width: auto (which wouldn't be STF as it has an aspect ratio with a definite height) would resolve to 100px.
2. min-width: auto would be 150px (applying the minimum automatic size rule).

Thoughts?

[fantasai]

@bfgeek Right; the idea of width: fit-content is that it gives the same results as width: auto on a float. And width: auto on the float, as you note, should be exactly aspect-ratio x height in this case. If min-content and max-content are to represent the extremes of fit-content’s size range, they can't be based on the content sizes, since the fit-content range is a single point equal to aspect-ratio x height (which may well even be outside the range of the minimum/maximum content-based sizes, as they are in this case).