[css-sizing] Import aspect-ratio from child image

[fantasai]

A very common patter is to wrap images in a link tag (or some other tag). If the wrapper is going to behave properly for layout purposes (such as being a flex or grid item) then it will want to have the size and aspect ratio of the image. So we might want some way of pulling up a descendant element’s aspect-ratio into such a wrapper element.

(Tagging against Sizing 4, but might defer to later.)

[tabatkins]

Strong agree with this - in particular, it would be very useful to let <picture> pick up the aspect ratio of the chosen source for its child img.

So I guess this should only work if it contains only a single child box (this works for picture, which only contains display:none source elements and one img). Multiple boxes don't make sense here; what possible relevance could the aspect-ratio of one of them have if you have more content that is thus, by definition, making the content not be that aspect-ratio?

Should mbp of the child matter? A 4:3 img child with margin: 10px; won't be exactly 4:3 anymore - do we want the picture to still be 4:3 or be whatever the resulting aspect-ratio is when you inflate the box by 10px?

Agenda+ to introduce the subject and spark discussion/thought; not looking for a final solution here yet.

[tabatkins]

I think we should not factor in the mbp of the child. This would make the behavior different from a plain ratio-using element; when we care about their a-r, we don't care about their mbp.

[css-meeting-bot]

The CSS Working Group just discussed [css-sizing] Import aspect-ratio from child image.

The full IRC log of that discussion

<dael> Topic: [css-sizing] Import aspect-ratio from child image
<dael> github: https://github.com//issues/5269
<dael> TabAtkins: Two big use cases people run into that make a-r not work how they want
<dael> TabAtkins: In block layout if you have image with a-r and wrapper doesn't effect, but in flexbox or grid there is special code that is defeated by wrapper. Incl link or picture element which are common
<dael> TabAtkins: Req is for a parent element to get a-r from child but only if it has a single child with a-r. In all other cases acts like a-r none
<dael> TabAtkins: I don't think needs to grab other intrinsic sizes, but we can think about that. Flexbox only cases about ratio.
<dael> TabAtkins: Some unanswered questions. What do you want to do with m/b/p which change render size
<dael> TabAtkins: We can probably resolve in futher issues
<AmeliaBR> q+
<emilio> q+
<dael> TabAtkins: General case to pull a-r from single child do people think this is reasonable?
<cbiesinger> q+
<Rossen_> ack fantasai
<Zakim> fantasai, you wanted to ansewr that and to
<dael> fantasai: Not sure we want to take from an only child. A lot of cases where we pull something like this where you grab first child. Whatever we do for grab info from child should be conssitent. Not sure it should be check for only one child
<dael> TabAtkins: I don't think svg is useful for examples b/c it doesn't have layout. Further children don't effect. In this case if you have an element with image and fit caption if you take from image it's meaningless
<dael> fantasai: You can have positioned caption on top of picture which makes sense
<dael> TabAtkins: One inflow child than
<dael> AmeliaBR: That's my point, one inflow child for case of figure with caption on top of image.
<dael> AmeliaBR: I'm not sure what fantasai was thinking on svg but I can't think of a case where it gets a-r from children. SVG in a CSS layout having these behaviors is useful
<dael> fantasai: Not specifically a-r. I think some property in svg grabs info from children
<Rossen_> ack AmeliaBR
<dael> AmeliaBR: title and description?
<dael> AmeliaBR: Either way, need to think about would it be web compat to make this default change? We have lots of flex and grid layouts where if this was available authors would have loved but they have made adjustments and doing by default is problem
<dael> AmeliaBR: Could make keyword for a-r property. On you picture element have an a-r from content that would have this special behavior
<dael> AmeliaBR: If it's web compat to make it default where if you have one inflow child with an a-r container is a-r it would be great to be automatic.
<dael> TabAtkins: I strongly suspect its not web compat. I'd like to run on that assumption that this is specific property. an a-r keyword that does it
<dael> fantasai: Or some new syntax
<dael> fantasai: new keyword or something else
<Rossen_> ack emilio
<dael> emilio: I was going to say behavior will be weird with applied whitespace. Children create boxes which can be collapsed or suppressed but htat's optimization. Bit weird that whitespace around image this trick doesn't work
<dael> TabAtkins: How weird if we did ignore collapsed whitespace
<dael> emilio: Somewhat. I don't have strong opinions. Direction with single box is odd.
<dael> fantasai: I would have said first child element
<dael> Rossen_: In doc order?
<dael> emilio: Right
<dael> fantasai: Yes
<dael> TabAtkins: If you take first child element it exculdes text. Non-whitespace text would be ignored too so should trigger no a-r
<AmeliaBR> So… if the container has exactly one in-flow, non-collapsed-ws child box…, then `aspect-ratio: from-contents` works
<Rossen_> ack cbiesinger
<fantasai> I think we can let the author not specify the keyword if there's other content they want to ignore
<dael> cbiesinger: I'm also concerned it's a lot of magic. A lot like emilio comments
<dael> cbiesinger: Have to be careful to not add something that will break this
<dael> cbiesinger: Use cases I've heard from webdev is they wanted a-r and they were happy. Didn't ask for this
<dael> cbiesinger: Final, picture elmenet should probably take a-r from img tag
<dael> TabAtkins: I don't think just a-r is usable b/c of picture. Different source could provide different a-r and you can't easily predict
<heycam> in SVG we did at one point discuss allowing properties that refer to elements by URL to have a "from-child" or something keyword, e.g. so you could do <path style="marker-end: from-child"><marker>. but that didn't really go anywhere beyond an idea. (might be fantasai is thinking about this)
<dael> cbiesinger: Getting a-r from child makes most sense
<dael> TabAtkins: Don't see reasont o differentiate between picture and a. Picture into link is common and easy and I would prefer it didn't break layout
<dael> cbiesinger: Careful about lin breaks between a and img
<dael> TabAtkins: Unless we do something about collasable whitespace
<dael> fantasai: Collapsable whitespace doesn't generat box right?
<dael> emilio: Maybe. In Gecko we don't when we can prove it doesn't have to. But we need to deal with it.
<Rossen_> q?
<dael> TabAtkins: Unsure if it's clear if box is generated.
<dael> fantasai: If it did it would interrupt margin collapsing.
<dael> TabAtkins: Yeah, okay. Great observation. In that we observe this with margin collapising shoudl be able to observe without being particularly weird
<dael> Rossen_: Looking through issue this is mostly to introduce and feel room
<dael> Rossen_: Sounds like some level of anxiety but also use cases which are supported.
<dael> Rossen_: What's next step? Work more for concrete proposal?
<dael> TabAtkins: I was seeking if objections. Info is useful. We can put a proposal in spec and bring it to WG
<dael> Rossen_: Anything else on this?

[tabatkins]

Comments during the f2f pointed out a few wrinkles we need to worry about:

• out-of-flow elements shouldn't prevent this (a figure with an abspos figcaption, for example)
• collapsed whitespace shouldn't prevent this (it shouldn't matter whether the <a> and <img> tags are on a separate line in the source)

@emilio and @cbiesinger thought it would be kinda weird for this to care about collapsed whitespace specifically. @fantasai pointed out that we already care about this for margin-collapsing, for instance - collapsed whitespace between the container and the first child element doesn't prevent collapsing. Given this, I think it's okay to rely on the same behavior?