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

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](https://bugs.chromium.org/p/chromium/issues/detail?id=860604))—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).

-- 
GitHub Notification of comment by chris-morgan
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2888#issuecomment-402992901 using your GitHub account

Received on Friday, 6 July 2018 10:17:23 UTC