[css-env] should we be requiring all env() variables in the spec to be implemented simultaneously?

[heycam]

https://drafts.csswg.org/css-env-1

Currently the spec says:

The following UA-defined environment variables are officially defined and must be supported [...]

Should we be making this requirement? I think we generally don't require implementation of specific sets of CSS features. We allow implementations to add support for features where they see fit. So maybe we should be changing this wording (now that #2820 has agreement) to say something like "Here are the env() variables we have defined. You must not support other ones, but here are the behaviors of the ones that may be supported."

Alternatively we may want to allow groups of env() variables to all be supported if one of them is, such as all of the safe-area-inset-* ones.

[chris-morgan]

It seems to me reasonable for css-env-1 to say “mandatory at this level: safe-area-inset-{top,left,right,bottom}”, and css-env-2 to say “newly mandatory at this level: foo, bar”, and so forth. That’s what happens with keywords in other CSS specs.

On the other hand, those are cases where the entire rule will be rejected if it’s not supported, whereas env() is expressly designed to have a fallback value so that a particular value need not be implemented.

Yet something to be aware of is that basically all the documentation out there at present on how to make your website pretty on the iPhone X is talking about env(safe-area-inset-*) without fallback. This is why FastMail got completely broken when Chromium Canary implemented env() but not safe-area-inset-* (which led to @heycam filing this issue, and me filing 860604 on Chromium)—because we’d just followed Apple’s instructions.

So, like it or not, those four variables at least are kind of a soft requirement of css-env-1—if you implement env() without implementing them, you will break what I presume will be lots of sites, though I can only attest to FastMail breaking (and, pending the outcome of this, I’ll consider adding the fallback anyway).