- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 08 Jul 2020 16:54:08 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-sizing-4] Should aspect-ratio affect the intrinsic size?<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/5032<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/5032#issuecomment-639874263<br> <dael> fantasai: Here's summary comment for Tab and I ^<br> <dael> fantasai: I guess people should read it<br> <dael> stearns: I think people can read and listen to a summary<br> <dael> fantasai: Question was for min-content and max-content size does a-r impact what they resolve to<br> <dael> 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.<br> <dael> fantasai: Take a 1x1 image naturally 200px. If you make it 100px tall it's 100px wide with auto width<br> <dael> 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.<br> <dael> 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<br> <dael> 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<br> <dael> 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<br> <Rossen_> q?<br> <dael> fantasai: Those are design constraints.<br> <dael> 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<br> <Rossen_> q+<br> <dael> 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.<br> <dael> fantasai: Thought through the constraints.<br> <stearns> ack Rossen_<br> <dael> 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.<br> <dael> 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<br> <dael> 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.<br> <dael> Rossen_: But that's me talking before you spoke of conclusion<br> <dael> 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.<br> <dael> 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<br> <dael> fantasai: We cannot change that. This is about what is size returned when you as for the keyword<br> <dael> Rossen_: Prop to separate behavior or keep consistent?<br> <jensimmons> Can we go back to fantasai's explantation, and get off the detour?<br> <Rossen_> jensimmons, how is that a detour?<br> <dael> 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.<br> <dael> 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<br> <dael> 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<br> <dael> 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<br> <dael> AmeliaBR: You talked with people on impl teams and people are willing to change?<br> <dael> fantasai: Talked to Blink and Gecko and they seemed to believe it's possible<br> <dael> AmeliaBR: Webket devs on call that disagree?<br> <dael> smfr: Probably happy to, don't know enough to say definitively<br> <dael> 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<br> <dael> 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<br> <dael> 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?<br> <dael> Rossen_: Or is it only when height or min-height is defined<br> <dael> ??: IN block min and max content don't do anything. THere's an issue to change that pending dbaron input<br> <fantasai> s/??/cbiesinger/<br> <dael> Rossen_: So only time this takes effect is if cross-axis is fixed<br> <dael> cbiesinger: Yes<br> <dael> Rossen_: Reasonable<br> <dael> fantasai: Do we want to pause and resolve on that before we go to second part of issue?<br> <florian> +1<br> <dael> stearns: I'm hearing a lot of this sounds possible. Can you summerise?<br> <dael> 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<br> <dael> stearns: And it would match contraint when taking specified aspect ratio into account<br> <dael> fantasai: Yes<br> <dael> dbaron: Starting to think, does this introduce problems when both width and height use these keywords?<br> <dael> 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<br> <dael> 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<br> <dael> cbiesinger: And it's because that we don't support min-content in block axis<br> <dael> fantasai: One of the rules we thought of is when you transfer sizing constraint through a-r you don't transfer an indefinite size<br> <dael> fantasai: That's not yet explicit in spec<br> <stearns> cbiesinger do you have an issue number for this?<br> <dael> fantasai: I think we need that regardless<br> <dael> dbaron: If you think it's okay that's fine. Haven't thought through fully<br> <dael> 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<br> <dael> stearns: Other discussion about the resolution or objections?<br> <dael> AmeliaBR: Sounds like second possible resolution about a-r is ignored if transferring indefinite size<br> <dael> AmeliaBR: Just saying 2 resolutions<br> <dael> stearns: Not hearing objections to first<br> <dael> 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<br> <dael> stearns: Do you want to talk about AmeliaBR second item or something else on this?<br> <dael> fantasai: Something else on this issue.<br> <dael> fantasai: Now we'll get into instractions with other resolution<br> <dael> fantasai: We have definitions but we also have 2 different behaviors<br> <dael> fantasai: I have a non-replaced element with fixed width 100px and a-r of 1 to 1.<br> <dael> fantasai: If content is too much I want it to stretch out the size of the box and not be 1x1<br> <dael> fantasai: #3268 we said you get that when min-height is auto<br> <dael> 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<br> <dael> 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<br> <dael> fantasai: Also have concept that's different than min/max-content<br> <dael> fantasai: May or may not need separate keyword. Definitely need concept in spec.<br> <dael> 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.<br> <dael> fantasai: Given we use intrinsic in contain-intrinsic-size we propose min/max-intrinsic.<br> <florian> q+<br> <dael> fantasai: Could be a keyword to width and height properties. Certainly need terms in the specs and audit all the layout specs<br> <dael> fantasai: That's the direction we're going in and wanted to ask WG what they think.<br> <stearns> ack florian<br> <dael> 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?<br> <dael> 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.<br> <dael> florian: What does it mean for non-replaced to honor a-r on block axis min-content<br> <dael> fantasai: Have a-r. Apply to non-replaced block it should apply a-r to that<br> <dael> 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<br> <AmeliaBR> q+<br> <dael> 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<br> <dael> 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<br> <dael> 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<br> <stearns> ack dbaron<br> <dael> 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<br> <dael> 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.<br> <dael> 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.<br> <dael> fantasai: Could for with natural-size which I think is in HTML<br> <stearns> ack AmeliaBR<br> <florian> q+ to disagree with AmeliaBR<br> <dael> 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<br> <dael> 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<br> <stearns> ack florian<br> <Zakim> florian, you wanted to disagree with AmeliaBR<br> <dael> 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<br> <dael> 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<br> <Iank> I joined a little late which issue are we currently on?<br> <dael> 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<br> <stearns> Iank: 5032<br> <dael> 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<br> <dael> 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<br> <dael> AmeliaBR: fantasai talked about auding specs to see which uses should or shouldn't be a-r dependent. Nice to have that list<br> <dael> 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<br> <dael> florian: I would argue against intrinsic b/c I would expect the inverse between intrinsic and content.<br> <fremy> +1 to what florian just said<br> <dael> 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.<br> <dael> cbeis...: Previous was to change min-content definition<br> <dael> fantasai: Keep it as is in spec right now<br> <dael> stearns: Let's close this discussion.<br> <fantasai> s/Keep/Prop was to keep/<br> <dael> stearns: Should we go back to transfering sizes?<br> <dael> 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<br> <dael> 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<br> <florian> s_b/c I would_b/c if we have both, I would_<br> <dael> AmeliaBR: Okay. We'll follow up<br> <dael> stearns: Anything more on this issue?<br> <fantasai> s/fit/fit with everything initial value,/<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5032#issuecomment-655637111 using your GitHub account
Received on Wednesday, 8 July 2020 16:54:11 UTC