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-env] Adding custom env() variables #2627

jonathantneal opened this Issue Apr 30, 2018 · 5 comments


None yet
5 participants
Copy link

jonathantneal commented Apr 30, 2018

What are the current ideas being pitched to add custom env() variables via CSS?

To add custom env() variables, could a similar syntax be used as seen in custom media and custom selectors?

@custom-env --some-width 30em;

Or what other issues might there be?

Should it work on a rule level, so you can insert arbitrary stuff into a rule, like reusing a block of declarations?

While I feel like the answer should be “not yet”, if the answer to this question is yes, could syntax like @media (curly braces) be used?

@custom-env --some-centering {
  align-items: center;
  justify-content: center;

As for JS, I hope that can be resolved separately via Houdini, because I’m under the impression there are still many things to work out with the similar concept of custom properties (as well as shorthands which apply to both, or selectors and rulesets that could apply to env()) .

@jonathantneal jonathantneal changed the title [css-env] custom env() variables [css-env] Adding custom env() variables Apr 30, 2018

@tabatkins tabatkins added the css-env-1 label Apr 30, 2018


This comment has been minimized.

Copy link

upsuper commented May 7, 2018

I think the general idea is to allow script to set them. But it's probably a good idea to allow stylesheets specify default values to them. Probably something like

@env {
    --some-width: 30em;
    --some-color: #000;



This comment has been minimized.

Copy link

tomhodgins commented May 7, 2018

What would the advantage of 'custom env() variables' be compared to using the CSS custom properties we already have?

These env() values could potentially be things the browser user has influenced (like if they have a setting for 'prefer low motion' or 'high contrast' that gets exposed as an env(), or information about the device, OS, and browser it's being displayed in) but if they're settable by CSS authors that seems like it defeats the purpose of them—if it's the case that we want custom settable variables and special variables with reserved names that the browser supplies to value to why not expose these values as some kind of reserved default CSS custom property, what would we even need env() for?


This comment has been minimized.

Copy link

tabatkins commented May 7, 2018

env() is guaranteed global, which means you can store them in a much more memory-efficient whole-page data structure, rather than on each individual element like currently. (Chrome, at least, attempts to detect custom props that are set on the root element and not set anywhere else, and automatically upgrade them to such a data structure.)

env() also should be usable in further contexts outside of properties on elements, such as in MQs. This is fundamentally impossible with var().


This comment has been minimized.

Copy link

jonjohnjohnson commented May 7, 2018


but if they're settable by CSS authors that seems like it defeats the purpose

#2629 (comment)


This comment has been minimized.

Copy link

jonjohnjohnson commented Nov 6, 2018

I hope this is the place for ideas to prevent use of author-defined env() causing FOUC.

In #3285 (comment) @tabatkins says...

Setting a new env() value would trigger a reparse in this idea.

Any thoughts on what @upsuper points out in #2627 (comment)?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment