- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 27 Feb 2019 18:13:51 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-sizing] Rethinking how to prevent overflow in a container with an explicit aspect ratio`, and agreed to the following: * `RESOLVED: use min-height: auto to solve problem of content overflowing aspect-ratio` <details><summary>The full IRC log of that discussion</summary> <astearns> topic: [css-sizing] Rethinking how to prevent overflow in a container with an explicit aspect ratio<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/3268<br> <fremy> fantasai: so jensimmons_ filed this issue about how we are going to handle non-replaced element aspect ratio<br> <fremy> fantasai: it's possible that the content might overflow the element<br> <fremy> fantasai: so do we want to make sure the aspect ratio is a rigid ratio, or just a minimum ratio<br> <fremy> fantasai: there are multiple ways to do this<br> <fremy> fantasai: one would be to take advantage of min-height: auto then use min-content or aspect ratio, but otherwise use only the aspect ratio<br> <dbaron> Was having min/max-aspect-ratio one of the options?<br> <fremy> jensimmons_: we talked about it before, if you have paragraph with a couple of words an an aspect ratio<br> <fremy> jensimmons_: if the ratio allows for breathing room at the bottom, it's fine<br> <fremy> jensimmons_: but if it's smaller because the paragraph has lots of words, then it's overflowing<br> <fremy> jensimmons_: so we thought maybe the default behavior would to take min-content into account<br> <fantasai> Florian's proposal to use min-height: https://github.com/w3c/csswg-drafts/issues/3268#issuecomment-437731901<br> <fremy> fantasai: so, could we resolve and add this into the spec<br> <fremy> florian: min-content and max-content are the same in that direction<br> <fremy> florian: but if they wouldn't be in the future, which one would we want to use?<br> <fremy> florian: right now, we don't have mechanism to tweak it but it might come later<br> <fremy> dbaron: min-aspect-ratio/max-aspect-ratio<br> <fremy> dbaron: but width/height are defined in the other direction<br> <fremy> dbaron: (of priority?)<br> <fremy> fantasai: yes, but you can apply the ratio in both directions, because we do it in the direction that is auto<br> <fremy> dbaron: but if you worry about sizing of height, I guess by then the width has been set<br> <fantasai> jensimmons_: I don't know what min-aspect-ratio or max-aspect-ratio would mean, and I don't think we need a three-part aspect ratio system<br> <fremy> dbaron: the idea I was thinking is that you might want an aspect ratio, but that could be taller or wider, you could use min-aspect-ratio<br> <fremy> dbaron: well, ok, maybe I got this backwards<br> <fremy> dbaron: so it's fair to say that min and max might be confusing in this case<br> <fremy> dbaron: but it's more expressive<br> <fremy> jensimmons_: I don't think there is a use case for max-aspect ratio<br> <fantasai> jensimmons_: I think the desired behavior is that you set an aspect ratio, and if there's more content it grows bigger... or it overflows<br> <fremy> jensimmons_: you want the aspect ratio to either be strict<br> <fantasai> jensimmons_: It's not a minimum aspect ratio, it's the desired aspect ratio unless it gets overflowed<br> <fremy> jensimmons_: or allow for the box to grow<br> <rachelandrew> q+<br> <fantasai> jensimmons_: I don't know what the use case is for a maximum aspect ratio<br> <fantasai> jensimmons_: or a range of aspect ratios<br> <fantasai> jensimmons_: From authoring / film industry... doesn't make sense<br> <fantasai> jensimmons_: You want a particular target, or you let it slide because it's not a good idea (overflow)<br> <fantasai> jensimmons_: I'd rather do the 1st proposal not the 2nd, to summarize<br> <Rossen> q?<br> <florian> q+<br> <xfq> ack ra<br> <fremy> rachelandrew: maybe there are a couple of use cases that this doesn't solve<br> <fremy> rachelandrew: can we make a proposal statement, and try to get this out?<br> <fantasai> rachelandrew: Trying to think of a use case this doesn't solve. Would like something written up with an example, say to authors, "this is wha we're thinking of doing, behaves like this. Can you think of any use case it doesn't solve?"<br> <fremy> ScribeNick: fantasai<br> <fantasai> rachelandrew: Pple are doing this all over the web, so have an idea of what they need<br> <fantasai> rachelandrew: We could get htis out there and see if it'll solve the problems<br> <xfq> ack fl<br> <jensimmons_> q?<br> <fantasai> florian: agree with jensimmons_<br> <fantasai> florian: The thing you brought up, dbaron, is whta the proposal is trying to solve<br> <fantasai> florian: Want to grow by default if too much content<br> <fantasai> florian: min/max-aspect ratio is too confusing<br> <fantasai> florian: and the first one gets most of what you want, and you can enforce strictly if you need<br> <fantasai> jensimmons_: 2 use cases most common<br> <fantasai> jensimmons_: 1 - video or empty decorative box<br> <fantasai> jensimmons_: not a video element video, but iframe or object or something<br> <fantasai> jensimmons_: other use case is teaser cards or something like that<br> <fantasai> jensimmons_: Maybe you want them all squares<br> <fantasai> jensimmons_: but you don't want them to consrain height, because want to allow overflow<br> <bkardell_> q+<br> <fantasai> jensimmons_: Is anyone imagining a different class of use case<br> <fantasai> q+<br> <xfq> ack bk<br> <fantasai> bkardell_: I'm hesitant to even bring this up, because not sure it fits in conversation, but not that long ago I worked on a project that was CMS-oriented<br> <fantasai> bkardell_: It was very open to what authors could provide<br> <fantasai> bkardell_: There were maybe 2-3 different kinds of images with their own aspect ratios<br> <fantasai> bkardell_: there was some negotiation<br> <fantasai> bkardell_: wanting to deal with the actual spect ratio was the issue we had there<br> <fantasai> bkardell_: but seems the opposite of what jen's talking about<br> <fantasai> bkardell_: might not be relevant...<br> <fantasai> astearns: We're talking here to add an aspect ratio tonon-replaced elements<br> <fantasai> astearns: so behavior needs to be specified for when content can't match aspect ratio that was specified<br> <fantasai> astearns: images always can<br> <fantasai> jensimmons_: Images come in when you use object-fit: cover or contain<br> <fantasai> jensimmons_: and want ot give a particular aspect ratio<br> <fantasai> jensimmons_: but that's about interaction of explicit and implicit aspect ratios<br> <xfq> ack fan<br> <fremy> fantasai: one of the benfits of the min-height auto solution<br> <fremy> fantasai: is that we can easily turn off the grow behavior<br> <fremy> fantasai: for example when we have scrolling in place<br> <dholbert> q+<br> <fremy> fantasai: which I think is what we want by default<br> <fantasai> fantasai: this is what min-height: auto is for<br> <astearns> ack dholbert<br> <fantasai> dholbert: One thing to think about is the thing with aspect ratio is not itself scrollable<br> <fantasai> dholbert: but it has a scrollable child<br> <fantasai> dholbert: min-height: auto means be as tall as the thing inside the scrollable thing<br> <florian> q+<br> <fantasai> dholbert: because the scrollble content is one level belo<br> <fantasai> dholbert: fixable by setting min-height: 0<br> <fantasai> dholbert: but might be worth thinking about<br> <fantasai> q+<br> <fremy> fantasai: actually, that spec has a simple solution<br> <fremy> fantasai: the question is whether this is web-compatible<br> <fremy> fantasai: so we need to implement this and see in a canary build if that works<br> <fremy> cbiesinger: it's in the backlog, but only for width<br> <fremy> fantasai: well, you said you could only do this for width, but eventually we would want to try both<br> <xfq> ack florian, fantasai<br> <fremy> fantasai: but width is a good start<br> <fantasai> florian: Maybe this is one place where in the block axis we have a difference between min-content/max-content... maybe not<br> <xfq> q?<br> <xfq> ack florian<br> <xfq> ack fantasai<br> <fantasai> florian: max-content you expand all the ontent. min-content you don't...<br> <fantasai> Rossen: That's super weird<br> <florian> q-<br> <fantasai> q-<br> <fantasai> Rossen: I think it is super weird. It is also a beahvior that is desired.<br> <fantasai> Rossen: If we going to introduce something like this, let's not re-introduce max-width or something<br> <fantasai> Rossen: let's add another propert<br> <fantasai> florian: I did not mean the max-width prperty<br> <fantasai> florian: I meant themax-content keyword<br> <fantasai> florian: min-height: auto grows you beyond the auto height<br> <fantasai> florian: If you specified min-height: max-content you would grow and min-height: min-content you would not<br> <fantasai> jensimmons_: We started there, but decided to use auto instead<br> <fantasai> jensimmons_: You'd get the same result<br> <fantasai> florian: Thing I hadn't considered is what dholbert brought up, when it's the children of the thing with an aspect ratio that are scrollable<br> <fantasai> florian: Do you want control over that?<br> <fantasai> florian: ...<br> <fantasai> jensimmons_: My expectation is that if you assign an aspect ratio to a box and inside there's crollable contentn, then your desire is to keep that content at that spect ratio<br> <fantasai> jensimmons_: and then the content scrolls<br> <fantasai> jensimmons_: that would be awesome<br> <fantasai> jensimmons_: The fact that children is scrolling, want the container to grow?<br> <fremy> +1 to what fantasai said<br> <fremy> fantasai: I think this is one of the big mistake we made, and I really want this fixed<br> <fremy> fantasai: I am afraid of the webcompat<br> <fremy> fantasai: so I can't make this change just by myself<br> <Rossen> q?<br> <fremy> fantasai: but authors shouldn't have to set weird height:0 etc hacks to work around this<br> <fremy> astearns: but this is orthogonal to this issue, right?<br> <fremy> fantasai: yes<br> <tantek> +1 on fantasai's proposal from an authoring perspective. I hope we can do it and maintain compat!<br> <fantasai> proposal is to use min-height: auto to solve the problem of having the box grow past its aspect-ratio in order to accommodate content that would otherwise overflow<br> <fantasai> jensimmons_: [gives an example]<br> <fantasai> jensimmons_: If have 400px wide box with 1:1 aspect ratio and content is 700px heigh<br> <fantasai> jensimmons_: min-height: auto computes to 700px, therefore wins over the height calculated by aspect ratio<br> <fantasai> jensimmons_: author can set min-height: 0 to get that content ignored in the sizing<br> <fremy> dholbert: for both axes?<br> <fremy> fantasai: I think so, but not if both are auto<br> <fremy> dholbert: (example was about a very long word you can't break)<br> <xfq> q+ AmeliaBR<br> <fantasai> AmeliaBR: object-fit?<br> <xfq> ack AmeliaBR<br> <fantasai> fantasai: this is about non-replaced elements, doesn't apply<br> <fantasai> astearns: objectiosn to proposed resolution?<br> <fantasai> RESOLVED: use min-height: auto to solve problem of content overflowing aspect-ratio<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/1865<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3268#issuecomment-467970982 using your GitHub account
Received on Wednesday, 27 February 2019 18:13:54 UTC