mozilla/standards-positions

[css-sizing-4] `stretch` keyword for sizing properties

dholbert opened this issue · 10 comments

Request for Mozilla Position on an Emerging Web Specification

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.

@dholbert do you want to leave this open until you have filed those issues?

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.

image

@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. :)