- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 15 Sep 2022 23:20:46 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Change content-size suggestion to min-intrinsic instead of min-content?`, and agreed to the following: * `RESOLVED: use the transferred size suggestion in preference to the content size suggestion, where that exists, for replaced elements` <details><summary>The full IRC log of that discussion</summary> <heycam> Topic: Change content-size suggestion to min-intrinsic instead of min-content?<br> <heycam> github: https://github.com/w3c/csswg-drafts/issues/6794<br> <heycam> dgrogan: this is about how the automatic minimum sizing for flex items works with items that have an aspect-ratio<br> <heycam> ... non-replaced items with an aspect-ratio<br> <heycam> ... Elika summarized it nicely<br> <heycam> ... ultimately it's a conflict between when an aspect-ratio item, would overflow the container, do we want to destroy the aspect-ratio and let flex's shrinking properties override it<br> <heycam> ... or preserve the aspect-ratio, with potentially some overflow<br> <dgrogan> https://jsfiddle.net/dgrogan/zcL7qs2v/5<br> <heycam> dgrogan: I would argue that we want to preserve the aspect-ratio, in part because authors seem to want their aspect-ratios preserved<br> <heycam> ... I just looked on Stack Overflow, I looked at the first 10-15 aspect ratio questions, mostly they're about flex destroying their aspect-ratio<br> <heycam> ... if they want it destroyed because they don't want overflow, they can specify min-width:0<br> <heycam> ... this issue is only about what we want in the default case<br> <Rossen_> ack fantasai<br> <heycam> fantasai: the initial value of min-width is auto, to prevent overflow when the author wasn't expecting the screen to be as narrow as it is<br> <heycam> ... the case here is the flex item is shrinkable, and is in a container that's smaller than its aspect-ratio derived size, but larger than its min-content width<br> <heycam> ... do we want it to shrink right down to the min-intrinsic size?<br> <heycam> ... setting min-width to 0 is more extreme, it shrinks to the point where the item no longer overlfows the container, but the item's contents overflows the item<br> <heycam> ... it prevents one kind of overflow but causes another<br> <heycam> ... if authors don't want a box to shrink below its specified size, whether it's specified through width or aspect-ratio, they shouldn't be having the box be a shrinkable flex item<br> <heycam> ... the purpose of min-width is a safety mechanism. preferred size is expressed through the width property<br> <heycam> dgrogan: I don't follow the argument about min-width no being the way to set a preferred size<br> <heycam> fantasai: if your preferred size is something with an aspect-ratio, and you set it width width/height, then min-width is a stopgap to prevent bad cases of overflow<br> <heycam> ... the aspect-ratio breaking, it might not look the way you wanted, but we're trying to optimize for the case being usable<br> <heycam> ... not to make your design look perfect, which is what width expresses<br> <heycam> dgrogan: I see what you're saying. I can take the other way symmetrically, specifying the preferred main size through the aspect-ratio and the height<br> <heycam> ... when we let the author set an aspect-ratio and a cross size, we're kind of promising that we'll respect that, they went out of their way to set that<br> <heycam> fantasai: same when the author says width:100px, but we break that when the item is shrinkable. since you've asked it to be shrinkable<br> <heycam> ... don't think aspect-ratio is less of a constraint than width<br> <heycam> dgrogan: authors seem to really hate when their aspect-ratios are broken<br> <heycam> ... I don't think it's obvious that aspect-ratio is the same strength as width<br> <heycam> ... it's not clear they're setting something as flimsy as a width, when they set aspect-ratio<br> <heycam> IanK: I think more opinions might be good from the author side of things<br> <heycam> dholbert: I'd question analagous situations. are there other cases where you set an aspect-ratio, and you stretch in both driections, like a grid cell?<br> <heycam> fantasai: when you set width/height on an element we ignore aspect-ratio completely<br> <heycam> IanK: the trick with flexbox is that it has a strong explicit stretch in the cross axis, by default<br> <miriam> q+<br> <Rossen_> ack miriam<br> <heycam> miriam: I can see use cases where I want it to shrink, and others where not<br> <heycam> ... how easy is it for the author to specify that?<br> <heycam> ... wondering if adding flex:0 is clear<br> <heycam> fantasai: that would cause it not to shrink. initial value allows shrinking but not growing<br> <heycam> miriam: I'm wondering if we were going with the other default, what would be the counter author solution to say, allow shrinking?<br> <heycam> IanK: flex:0 will still allow shrinking<br> <heycam> dholbert: flex:none is what you want<br> <heycam> fantasai: they're the same<br> <heycam> IanK: no<br> <heycam> fantasai: initial value is "1 0"<br> <heycam> dgrogan: I think we all agree on flex:none<br> <heycam> ... if we go with the opposite default, you'd have to go out of your way to say min-width:0<br> <heycam> dholbert: min-width:0 would cause more overflow than the opposite<br> <TabAtkins> Right, `flex: 0` is equivalent to `flex: 0 1 0px`<br> <heycam> ... it doesn't precisely undo it. that would allow things to compress to 0.<br> <heycam> dholbert: min-content or min-instrinsic<br> <heycam> IanK: min-content would do the right thing<br> <heycam> fantasai: it's not quite exactly that<br> <heycam> ... min-content will win<br> <heycam> ... auto minimum size, because it's trying to be a non-intrusive safety mechanism, if you have some explicit size on it, it'll take the minimum of that and the min-content size<br> <heycam> ... so you can't get the auto behavior by setting min-content<br> <heycam> miriam: I don't have an immediate sense of which one I want more often<br> <heycam> ... flex:none seems the simpler fix though<br> <heycam> fantasai: it also resolves to 0 if you're a scroll container<br> <heycam> ... there's a lot of magic in min-width:auto, to make it weaker than other author expressed constraints<br> <heycam> ... it's always trying to find what's the smallest size to prevent overflow and also not interfere with other constraints<br> <heycam> dgrogan: glad you brought up min-width:auto magic<br> <heycam> ... one proposal in the bug, from Ian in March, is redefining min-content for non-replaced aspect-ratio items to incorporate the auto min width from the aspect-ratio in css-sizing-4<br> <heycam> ... if we did that, we'd end up with the asepct-ratio preserving behavior in this case<br> <heycam> ... but it would do so in a way that would 1. a lot of magic would go away, min-width:auto becomse simpler to spec, and 2. it becomes easier to implement, and the auto min width for aspect-ratio items totally ignoring flexboxes also gets easier to implement<br> <heycam> ... in the 2 years this has been specced, it's been really hard to implement<br> <heycam> ... Ian has a big test case that shows some of this<br> <heycam> ... I think based on my knowledge of Blink/WebKit/Gecko, if we did Ian's proposal, implementation becomes simpler, and we'd be way more likely to get interop<br> <heycam> ... if we stuck with the magic in auto min-width, we're not going to get interop on a lot of this for a long time<br> <heycam> ... if ever<br> <heycam> ... we've all had a really hard time implementing this, and got lots of bug reports<br> <heycam> Rossen: becoming a bit more pragmatic, rather than chasing spec purity<br> <heycam> ... can we do that moving forward? if we can, do we have enough buy in from implementors?<br> <heycam> dholbert: what's Ian's proposal?<br> <heycam> Ian: effectively, instead of having a separate min intrinsic and min content size, you incorporate the min-width:auto behavior in min-content<br> <heycam> ... currently, we're the only implementation that explicitly created a separate min intrinsic size<br> <heycam> ... and effectively, that would disappear, and when you're calculating min-content for the box, you also apply the min-width:auto logic on top of the aspec-ratio logic<br> <heycam> fantasai: not following. we explicitly wanted to say min-width:auto would break aspect-ratio<br> <heycam> ... having min-height break but not min-width ...<br> <heycam> IanK: min-width:auto would still encompass this, it just wouldn't shrink<br> <heycam> dgrogan: I think Safari does this today<br> <heycam> Ian: Safari's min-content implementation basically does this already<br> <heycam> ... in some of the complicated test cases, Safari kind of does what I'm suggesting<br> <heycam> dgrogan: but we all have many bugs in this area<br> <heycam> Ian: engines also struggle with width:100% and width stretch being different<br> <heycam> Rossen: what's the proposal here?<br> <fantasai> https://jsfiddle.net/dgrogan/zcL7qs2v/5<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/6794#issuecomment-1218597495<br> <heycam> fantasai: we walked through a bunch of cases ^<br> <heycam> Ian: I also wanted to note, we can't change replaced elements. they have to stay at min-content<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/6794#issuecomment-1220038900<br> <heycam> ... there's too much of the web that relies on them preserving aspect-ratio<br> <fantasai> latest proposal from me and TabAtkins ^<br> <heycam> ... we accidentally broke this recently and got bug reports quickly<br> <heycam> ... can't shrink replaced elements below their min-content size<br> <heycam> dgrogan: I think your point Ian is that if we can't change replaced elements, they currently do what non-replaced elements currently do<br> <heycam> Ian: replaced elements will always pass through their aspect-ratio, and we can't change that<br> <heycam> dgrogan: so, incorporate the current min-width:auto magic into the min-content algorithm itself<br> <heycam> ... the min-width for these aspect-ratio items would be largest of their min intrinsic width, or their aspect-ratio derived width<br> <heycam> fantasai: Tab and I don't really like the idea of incorporating min-width:auto into min-content definition<br> <heycam> ... because it really should be the other way around<br> <heycam> ... if you set width:min-content, you're proposing that the resolution of that min-content value to a concrete value, looks at the min-width value, and if it is auto, incorporates some extra magic<br> <heycam> ... if it's not auto, does not have magic<br> <heycam> ... but if you set min-width:min-content, it cannot depend on the min-width property itself<br> <heycam> ... so the min-content keyword means two different things, depending on where you set it<br> <heycam> ... we think this should be more consistent, and independent of what sizing property you set it on<br> <heycam> ... whether it's on width or min-width, its used value is the same<br> <heycam> Ian: we already look at the width properties in the min-content algorithm. there's already a bunch of compressibility stuff, special table stuff<br> <heycam> ... this is fine from an engineering point of view<br> <heycam> dholbert: I'm a bit confused about that stating of the propsoal<br> <heycam> ... it sounds like we're talking about what should happen when you have an element with an asepct-ratio that's forced to shrink<br> <heycam> ... sounds like that's talking about what the magic is behind min-width:auto. not about how it gets incorporated<br> <heycam> fantasai: the compressibility stuff affects the min-content contribution, which is not hte same as the min-content size<br> <heycam> dgrogan: I think Ian's saying it's fine from an implementation PoV<br> <heycam> dgrogan: I think of this as how the min-content:auto magic is incorporated<br> <heycam> dholbert: min-width:auto resolves to come length<br> <heycam> s/min-content/min-width/<br> <heycam> ... sounds like the proposal is to resolve it to a different length<br> <heycam> ... that takes into account the aspect-ratio more eagerly<br> <heycam> dgrogan: I'm not talking about the min-content alg more eagerly taking it into account<br> <heycam> ... right now, it ignores min intrinsic size and only looks at aspect-ratio<br> <heycam> ... so if anything this proposal is to do it less eagerly<br> <heycam> Ian: we also look at asepct-ratio for the min intrinsci size, because we transfer through the max height and min height<br> <heycam> ... and that affects the min intrinsic size<br> <heycam> ... min-intrisc and min-content are almost always the same<br> <heycam> Rossen: still not seeing something we can resolve on<br> <heycam> ... sentiment here is clear, but I still don't see what to resolve to move forward, that satisifies implementability and the developer point<br> <heycam> ... Elika's pointing out another part of the issue, that articulates what we should and can do for replaced elements, and for non-replaced elements the explanation here still doesn't give enough specifiy that suggests a change<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/6794#issuecomment-1220038900<br> <heycam> fantasai: we are suggesting several specific changes<br> <heycam> fantasai: Tab and I are saying it shouldn't be considering aspect-ratio<br> <heycam> ... when we originally wrote the text for min-width:auto, there wasn't aspect-ratio on anything excpet replaced elements<br> <heycam> ... in that context, it doesn't make sense to incorporate aspect-ratio<br> <heycam> ... so we really meant min-intrinsic size despite not having that term yet<br> <Rossen_> a/developer point/developer pain/<br> <heycam> ... [the other two points are there in the link above]<br> <heycam> fantasai: in flex/grid when you have a transferred size, it's different in grid the transferred size takes precedence<br> <heycam> ... but in flex it takes the min of the two<br> <heycam> ... it seems that would probably not be a good idea for compat, given where implementations are right now<br> <heycam> Ian: that's something we can resolve on. for replaced elements, for compat, we need to keep it as min-content<br> <heycam> fantasai: I'd phrase that as "use the transferred size suggestion in preference to the content size suggestion, where that exists, for a replaced element<br> <heycam> Ian: for us they're basically equivalent<br> <heycam> ... when do they differ?<br> <heycam> fantasai: because the content size suggestions do not take aspect-ratio into account<br> <heycam> ... if it did, then there wouldn't have been a transferred size suggestion in the first place<br> <heycam> Ian: this is flex box's content size suggestion, not min-content size we use elsewhere<br> <heycam> RESOLVED: use the transferred size suggestion in preference to the content size suggestion, where that exists, for replaced elements<br> <heycam> fantasai: there was a comment in the thread about how transferring the max size from the opposite axis didn't make much sense<br> <heycam> dgrogan: in the content size suggestion?<br> <heycam> fantasai: for non-replaced<br> <heycam> ... right now we transfer a max size constraint from the opposite axis to clamp the min in this axis<br> <heycam> ... that probably doesn't make sense<br> <heycam> dgrogan: we still have a fundamental disagreement about the main point<br> <heycam> ... I just want to fall back, all 3 engines tried and we're in the place where we don't have much interop<br> <heycam> ... the suggestion of incorporating hte auto min width into the min-content calculation, it's not great, but it's practical, pretty sure all engines can do it easily, and we'd get interop way easier<br> <heycam> chrishtr: you also said impl difficulty and web compat prevented you from implementing the altnerative?<br> <heycam> Rossen: no that's for replaced elements<br> <heycam> dgrogan: it's related<br> <heycam> ... we're talking about changing the rules. and one of them would've changed replaced, but we can't do that<br> <heycam> chrishtr: so we special case replaced elements, for compat<br> <heycam> dholbert: to be fair, non-replaced elements do have a meaningful smaller min width<br> <heycam> Ian: I'd still like to hear from more web devs about what they expect of the default<br> <heycam> ... and how they'd work around that<br> <heycam> ... heard from Miriam<br> <heycam> dgrogan: it's not just implementation. if we resolve on Ian's March proposal, it becomes easier to implement, and we think it doesn't break user expectations<br> <heycam> ... Adam Argyle weighed in on that<br> <heycam> miriam: I have use cases that I'd want to go either way, so more important to me is that I have the tools to get non-defautl behavior when I need it<br> <heycam> ... flex:none, to say "preserve my aspect-ratio" worked for me<br> <heycam> ... if there's a similar swtich from the other side, then it'd work for me too<br> <heycam> fantasai: but there isn't one from the other side<br> <heycam> ... flex:none is the thing to use to prevent it from going below its minimum size<br> <heycam> chrishtr: do we need something for the other case?<br> <heycam> fantasai: that's what min-width:auto is for<br> <heycam> chrishtr: is there some other way to get this use case that Miriam says is legit?<br> <heycam> dgrogan: I don't really understand why some fixe value of min-width wouldn't work well<br> <heycam> ... even if it doesn't cover all cases, I think it'd be close enough<br> <heycam> ... don't understand why min-width is not enough<br> <heycam> miriam: it might be for my cases, would have to look more<br> <heycam> fantasai: would point out that it's a strong constraint<br> <heycam> ... if you put min-width:min-content that's winning over all other size constraints<br> <heycam> ... min-width:auto is a weak constraint<br> <heycam> ... everything else will win over it<br> <heycam> ... so if you want to set some kind of minimum, you want it to be a weaker one than other constraints? like max-width? you can't do that with min-content, because that will win over everything else<br> <heycam> dgrogan: you can do min-width:10px<br> <heycam> fantasai: is an arbitrary length value what you want?<br> <heycam> ... or something based on the content?<br> <heycam> dgrogan: I don't know where we go from here<br> <heycam> miriam: would also say that the fact it's not flexing to grow ... would it maintain the aspect-ratio?<br> <heycam> ... I'd expected it to do the same thing growing as shrinking<br> <heycam> ... if flex-grow:1, it will trash the aspect-ratio<br> <heycam> s/...if flex/Ian: if flex/<br> <heycam> miriam: I'd expect them to work the same way<br> <heycam> Ian: the problem we get into is that flex-shrink being 1 everywhere is ...<br> <heycam> fantasai: being the default is what's throwing people for a loop<br> <heycam> ... if they also set width:100px on it and notice that shrinks but doesnt grow, that's consistent<br> <heycam> ... whatever width you have preferred, it will shrink but not grow, by default, in flex<br> <heycam> Rossen: still not hearing a concrete path forward here<br> <heycam> ... I think this would benefit from some whiteboarding<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6794#issuecomment-1248742930 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 15 September 2022 23:20:49 UTC