Re: [csswg-drafts] [css-sizing] Import aspect-ratio from child image (#5269)

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

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [css-sizing] Import aspect-ratio from child image<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/5269<br>
&lt;dael> TabAtkins: Two big use cases people run into that make a-r not work how they want<br>
&lt;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<br>
&lt;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<br>
&lt;dael> TabAtkins: I don't think needs to grab other intrinsic sizes, but we can think about that. Flexbox only cases about ratio.<br>
&lt;dael> TabAtkins: Some unanswered questions. What do you want to do with m/b/p which change render size<br>
&lt;dael> TabAtkins: We can probably resolve in futher issues<br>
&lt;AmeliaBR> q+<br>
&lt;emilio> q+<br>
&lt;dael> TabAtkins: General case to pull a-r from single child do people think this is reasonable?<br>
&lt;cbiesinger> q+<br>
&lt;Rossen_> ack fantasai<br>
&lt;Zakim> fantasai, you wanted to ansewr that and to<br>
&lt;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<br>
&lt;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<br>
&lt;dael> fantasai: You can have positioned caption on top of picture which makes sense<br>
&lt;dael> TabAtkins: One inflow child than<br>
&lt;dael> AmeliaBR: That's my point, one inflow child for case of figure with caption on top of image.<br>
&lt;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<br>
&lt;dael> fantasai: Not specifically a-r. I think some property in svg grabs info from children<br>
&lt;Rossen_> ack AmeliaBR<br>
&lt;dael> AmeliaBR: title and description?<br>
&lt;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<br>
&lt;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<br>
&lt;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.<br>
&lt;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<br>
&lt;dael> fantasai: Or some new syntax<br>
&lt;dael> fantasai: new keyword or something else<br>
&lt;Rossen_> ack emilio<br>
&lt;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<br>
&lt;dael> TabAtkins: How weird if we did ignore collapsed whitespace<br>
&lt;dael> emilio: Somewhat. I don't have strong opinions. Direction with single box is odd.<br>
&lt;dael> fantasai: I would have said first child element<br>
&lt;dael> Rossen_: In doc order?<br>
&lt;dael> emilio: Right<br>
&lt;dael> fantasai: Yes<br>
&lt;dael> TabAtkins: If you take first child element it exculdes text. Non-whitespace text would be ignored too so should trigger no a-r<br>
&lt;AmeliaBR> So… if the container has exactly one in-flow, non-collapsed-ws child box…, then `aspect-ratio: from-contents` works<br>
&lt;Rossen_> ack cbiesinger<br>
&lt;fantasai> I think we can let the author not specify the keyword if there's other content they want to ignore<br>
&lt;dael> cbiesinger: I'm also concerned it's a lot of magic. A lot like emilio comments<br>
&lt;dael> cbiesinger: Have to be careful to not add something that will break this<br>
&lt;dael> cbiesinger: Use cases I've heard from webdev is they wanted a-r and they were happy. Didn't ask for this<br>
&lt;dael> cbiesinger: Final, picture elmenet should probably take a-r from img tag<br>
&lt;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<br>
&lt;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 &lt;path style="marker-end: from-child">&lt;marker>.  but that didn't really go anywhere beyond an idea.  (might be fantasai is thinking about this)<br>
&lt;dael> cbiesinger: Getting a-r from child makes most sense<br>
&lt;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<br>
&lt;dael> cbiesinger: Careful about lin breaks between a and img<br>
&lt;dael> TabAtkins: Unless we do something about collasable whitespace<br>
&lt;dael> fantasai: Collapsable whitespace doesn't generat box right?<br>
&lt;dael> emilio: Maybe. In Gecko we don't when we can prove it doesn't have to. But we need to deal with it.<br>
&lt;Rossen_> q?<br>
&lt;dael> TabAtkins: Unsure if it's clear if box is generated.<br>
&lt;dael> fantasai: If it did it would interrupt margin collapsing.<br>
&lt;dael> TabAtkins: Yeah, okay. Great observation. In that we observe this with margin collapising shoudl be able to observe without being particularly weird<br>
&lt;dael> Rossen_: Looking through issue this is mostly to introduce and feel room<br>
&lt;dael> Rossen_: Sounds like some level of anxiety but also use cases which are supported.<br>
&lt;dael> Rossen_: What's next step? Work more for concrete proposal?<br>
&lt;dael> TabAtkins: I was seeking if objections. Info is useful. We can put a proposal in spec and bring it to WG<br>
&lt;dael> Rossen_: Anything else on this?<br>
</details>


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

Received on Monday, 27 July 2020 22:29:54 UTC