[css-sizing-4] `stretch` keyword for sizing properties
dholbert opened this issue · 10 comments
Request for Mozilla Position on an Emerging Web Specification
- Specification title: CSS Box Sizing Module Level 4 (specifically the section on
stretch
) - Specification or proposal URL (if available): https://drafts.csswg.org/css-sizing-4/#valdef-width-stretch
- Explainer URL (if available): N/A
- Proposal author(s) (
@
-mention GitHub accounts): @tabatkins, @fantasai, @jensimmons - Caniuse.com URL (optional): https://caniuse.com/mdn-css_properties_width_stretch
- Bugzilla URL (optional): https://bugzilla.mozilla.org/show_bug.cgi?id=1789477
- Mozillians who can provide input (optional): myself, @emilio
- WebKit standards-position: None filed yet that I could find.
Other information
The stretch
keyword is a standardized version of the behavior that's traditionally been exposed by the prefixed -moz-available
and -webkit-fill-available
CSS keywords. (Minor caveat: -moz-available
only works in the inline axis for now, but stretch
and -webkit-fill-available
work in both axes.) We've observed that there are webcompat requirements for us to implement -webkit-fill-available
, and it seems the best way forward is to implement the standardized stretch
behavior and use -webkit-fill-available
as an alias for it (while recommending that sites use the standard keyword from here on out).
(@bfgeek noted in web-platform-tests/interop-2022-viewport#18 (comment) that Chromium at least has been moving towards making -webkit-fill-available
the same as the standardized stretch
behavior.)
We're positive on this feature; it's a reasonably elegant way of expressing a common sizing behavior. (And it's something that's really been implemented in browsers ~forever, just using vendor-prefixed keywords and with certain legacy limitations in our case.)
Yeah Blink's -webkit-fill-available
behaviour is basically stretch
at this point.
It'd be good to do this as it "explains" the other half of auto
(on width
/height
), e.g. depending on the parent formatting context and a few other things auto
either maps to fit-content
or stretch
. We do this internally for all auto
values on width
/height
(if people want it to do something other than this we should talk).
An important note is that -webkit-fill-available
in webkit does incorrect things (similar to quirky percentage heights, it'll skip over auto height elements). This was being exploited by web developers trying to simulate dvh
in webkit. We managed to change our (blink's) behaviour just as this technique was becoming popular, e.g. https://css-tricks.com/css-fix-for-100vh-in-mobile-webkit/ , https://github.com/postcss/postcss-100vh-fix/tree/master?tab=readme-ov-file#postcss-100vh-fix and https://www.bram.us/2021/07/08/the-large-small-and-dynamic-viewports/#but-why
So webkit might have a little more trouble performing a straight unprefix of -webkit-fill-available
to stretch
and likely would need two codepaths (but that is up to webkit to decide :) ).
Is the stretch keyword stable enough in the specification?
At first glance, I think it probably is. If I find unexplained edge-cases in the spec text when I'm implementing (or cases where Chromium's -webkit-fill-available
differs from the spec text for stretch
), I'll file issues to resolve those.
No, I think we can close this with a 'positive' inclination (and I haven't run into any issues yet, and don't anticipate any substantial trouble).
@dholbert
According to my tests, Chrome doesn't support flex-basis: -webkit-fill-available
, but it does unexpectedly when the layout.css.webkit-fill-available.enabled
flag is turned on in Firefox, which I think should be removed from flex-basis
.
@yisibl thanks, good catch! https://drafts.csswg.org/css-sizing-4/#sizing-values has a list of properties that should accept stretch
, and indeed flex-basis
is not there in the list.
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1920633 to fix this.
Actually, Firefox already supports flex-basis: -moz-available
, and I think the spec should improve it by allowing flex-basis: stretch
. Because this keyword makes up for the missing feature of flex-basis
.
I made the same request at Blink-dev.
Looking closer at the specs, I think the spec does actually already call for the keyword to be supported (though it could be clearer) - more details in https://bugzilla.mozilla.org/show_bug.cgi?id=1920633#c1 where I closed-as-invalid the bug that I just filed about this. :)