- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 18 Jun 2025 16:18:12 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-sizing][css-flexbox] It's false that `stretch` size behaves as `stretch` alignment``, and agreed to the following: * `RESOLVED: In a flex container's cross axis, stretch sizing keyword resolves initially against the container, then re-resolves against the line once the line's size is determined.` <details><summary>The full IRC log of that discussion</summary> <kbabbitt> oriol: problem here is that the stretch keyword says that it should have the same effect as stretch alignment<br> <kbabbitt> ... but this is not the case in any browser<br> <kbabbitt> ...behavior all browsers were having is that: while computing cross values of flex lines<br> <kbabbitt> ... stretch size would stretch against CB<br> <kbabbitt> ... but once you know line size, stretch size would keep stretching against CB, stretch align would stretch against align<br> <kbabbitt> ... there was some discussion of stretch align, proposal from ?? was: while computing cross align of flex size, stretch align stretches against size of container<br> <kbabbitt> ... once it's known, stretches to size of line<br> <kbabbitt> ... another constraint, while you are computing size of flex lines, ?? would behave as stretch content<br> <kbabbitt> ... once it's known, stretch to size of line<br> <kbabbitt> ... blink has already implemented<br> <kbabbitt> ... I think it will be shipping next week<br> <kbabbitt> ... behavior you get is reasonable, maybe a bit more complex to implement<br> <kbabbitt> ... but seems fine<br> <kbabbitt> ... servo is not there yet but close<br> <kbabbitt> ... main concern is that this is not just affecting min keyword, also affecting min content keyword<br> <iank_> q+<br> <kbabbitt> s/min keyword/new keyword/<br> <kbabbitt> s/min content/fit-content/<br> <kbabbitt> ... if you use fit-content explicitly or also if align-self property is not stretch, auto size will be fit-content<br> <kbabbitt> ... behavior change there<br> <kbabbitt> ... may be a compat risk<br> <kbabbitt> ... but I guess Blink will find out soon<br> <Rossen6> q?<br> <kbabbitt> fantasai: question I have is: what is the impact from user perspective<br> <Rossen6> ack fantasai<br> <kbabbitt> ... what are the use case we're trying to enable or not enable?<br> <kbabbitt> ... sounds great from a theoretical perspective but is the behavior we're specing the one that will be most useful?<br> <kbabbitt> oriol: not sure about useful or not<br> <kbabbitt> fantasai: we can write testcase for any behavior, why is this one better?<br> <kbabbitt> iank_: it minimizes compat risk with shipping stretch keyword in all browsers<br> <kbabbitt> ... old behavior was clearly bad in my opinion<br> <kbabbitt> ... stretching initially should contain it<br> <kbabbitt> ... minimizes compat risk, we'll find out what happens next week when we try and ship<br> <kbabbitt> ... I can go into concrete constraints here<br> <kbabbitt> ... what this comes down to is, when you lay out a child, you need to give an availabile size<br> <kbabbitt> ... e.g. in grid we set an indefinite size for the axis<br> <kbabbitt> ... even if you have align stretch it's going to behave like fit content<br> <kbabbitt> ... not the same as in flex, we give a definite size and treat auto as fit-content in that case<br> <kbabbitt> ... constraint is we need one available size tha fit-content and stretch both use consistently<br> <kbabbitt> ... you need one available size because you might have min-width stretch and ?? fit-content and they can't use different sizes<br> <kbabbitt> fantasai: makes sense that those two need to match<br> <kbabbitt> iank_: given that, we have constraint that when you measure in row direction...<br> <kbabbitt> ... you pass in the container's inline size<br> <kbabbitt> ... and then you work out size of line<br> <Rossen6> iank_ can you stay closer to the mic pls<br> <kbabbitt> s/row direction/column direction/<br> <kbabbitt> ... pass in flex line's available size<br> <kbabbitt> ... that and container available size are the sizes we're working with<br> <kbabbitt> ... so if you stretch to those available sizes you get the behavior we've currently implemented<br> <kbabbitt> ... we do have the option of coercing stretch to be fit-content<br> <kbabbitt> ... but in my opinin that carries more compat risk<br> <kbabbitt> Rossen6: fantasai does that answer your question?<br> <kbabbitt> fantasai: I think so<br> <kbabbitt> ... so the proposal is we compute align stretch against CB initially<br> <kbabbitt> .. and once we have height align we compute against line?<br> <kbabbitt> iank_: stretch keyword stretches to available space<br> <kbabbitt> ... and then stretches to the line<br> <kbabbitt> fantasai: in a multiline container will always be at least as big as initial computation<br> <kbabbitt> iank_: yes, common case is they will all be the same<br> <Rossen6> q?<br> <kbabbitt> Rossen6: anything else?<br> <Rossen6> ack iank_<br> <fantasai> PROPOSED: In a flex container's cross axis, stretch sizing keyword resolves initially against the container, then re-resolves against the line once the line's size is determined.<br> <kbabbitt> iank_: looks right to me<br> <kbabbitt> Rossen6: objections?<br> <kbabbitt> fantasai: I think this is more correct than using fit-content, because stretch is not supposed to be an intrinsic size<br> <kbabbitt> RESOLVED: In a flex container's cross axis, stretch sizing keyword resolves initially against the container, then re-resolves against the line once the line's size is determined.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11784#issuecomment-2984894646 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 18 June 2025 16:18:13 UTC