We were all introduced to the
env() function in CSS when all that drama about “The Notch” and the iPhone X was going down. The way that Apple landed on helping us move content away from those “unsafe” areas was to provide us essentially hard-coded variables to use:
padding: env(safe-area-inset-top) env(safe-area-inset-right) env(safe-area-inset-bottom) env(safe-area-inset-left);
Uh ok! Weird! Now, nine months later, an “Unofficial Proposal Draft” for
env() has landed. This is how specs work, as I understand it. Sometimes browser vendors push forward with stuff they need, and then it’s standardized. It’s not always waiting around for standards bodies to invent things and then browser vendors implementing those things.
Are environment variables something to get excited about? Heck yeah! In a sense, they are like a more-limited version of CSS Custom Properties, but that means they can be potentially used for more things.
CSS environment variables are getting standardized:https://t.co/QKFBM3WFT2
Allow to get and use the browser- and author-defined variables: typography, colors, notch and other specific layout/device values.
They work in Media Queries, where CSS Custom Properties cannot be used. pic.twitter.com/FWrPiBiAqp
— Serg Hospodarets (@malyw) April 29, 2018
👀 Brand new spec for global env() variables in CSS: https://t.co/6YfXWFTyhN
Forget notches, the important thing here is the ability to separate CSS variables from the cascade. Cool ① for perf/code organization ② because you might be able to use them in media queries!
— Eric Portis (@etportis) April 30, 2018
Eric also points out some very awesome early thinking:
ISSUE 4 – Define the full set of places
env()can be used.
- Should be able to replace any subset of MQ syntax, for example.
- Should be able to replace selectors, maybe?
- Should it work on a rule level, so you can insert arbitrary stuff into a rule, like reusing a block of declarations?
If you’re into the PostCSS thing, there is a plugin! But I’d warn… the same issues that befall preprocessing CSS Custom Properties applies here (except the first one in that article).
I don’t really understand why it wasn’t possible to modify var() to also read any non-custom property. That alone would enable a lot of useful stuff.
For media queries, is the problem that they are always at the root? Maybe allow them to be scoped to a selector then, like Sass/Less do.
The notch on smartphones will becone mainstream this year and we have to find a solution for it. This is interesting stuff. Thanks for sharing!
This would be great for getting the browser font size setting and taking away the “most users are set to 16px” mentality.
CSS looks like slowly becoming a little programming language of its own.
env(scrollbar-size)would be great