Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-sizing-4] stretch keyword for sizing properties #1054

Closed
dholbert opened this issue Jul 25, 2024 · 10 comments
Closed

[css-sizing-4] stretch keyword for sizing properties #1054

dholbert opened this issue Jul 25, 2024 · 10 comments
Assignees
Labels

Comments

@dholbert
Copy link
Contributor

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

@dholbert
Copy link
Contributor Author

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

@bfgeek
Copy link

bfgeek commented Jul 25, 2024

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

@yisibl
Copy link

yisibl commented Aug 6, 2024

Is the stretch keyword stable enough in the specification?

@dholbert
Copy link
Contributor Author

dholbert commented Aug 6, 2024

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.

@zcorpan zcorpan added venue: W3C Specifications in W3C Working Groups topic: CSS team: Layout labels Aug 15, 2024
@zcorpan zcorpan moved this from Unscreened to Needs position in standards-positions review Aug 15, 2024
@zcorpan zcorpan moved this from Needs position to Position identified in standards-positions review Aug 15, 2024
@zcorpan
Copy link
Member

zcorpan commented Aug 15, 2024

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

@dholbert
Copy link
Contributor Author

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

@yisibl
Copy link

yisibl commented Sep 24, 2024

@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

@dholbert
Copy link
Contributor Author

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

@yisibl
Copy link

yisibl commented Sep 24, 2024

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.

@dholbert
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Archived in project
Development

No branches or pull requests

4 participants