Intent to implement and ship: CSS environment variables.

[Emilio Cobos Álvarez]

Summary: Implement the CSS env() function which allows to take a
variable name and a fallback value.

Note that this intent goes only for the CSS feature, not for the rest of
the display cutout support, which is tracked in bug 1503656.

This work would add support for four variables (the four that are
defined in the spec), by hardcoding them to 0px for now. The reasoning
for this is that this prevents compat issues by people that assume that
these variables exist, or fail to provide a suitable fallback, see [1]
for a recent example.

The reasoning as for why hardcoding those variables to "0px" is ok is
that we don't support viewport-fit=cover in the viewport meta tag yet,
so there's no way of putting the cutout on top of content anyway, and
thus the safe area insets are actually 0px in all our supported platforms.

This is mostly to prevent compat headache in mobile, hopefully prevent
other vendors from shipping new un-spec'd env variables, and encourage
people to use the fallback value if new environment variables are added
in the future.

Bug: 1462233

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

Platform coverage: All

Preference behind which this will be implemented: None

The reasoning for this is that:

* There's minimal regression risk.
* This touches very hot code.
* Adding the pref itself is non-trivial, requiring at least three
different code paths to be patched, and requiring `var` and `env`
functions being scanned separately during CSS parsing.

It's probably not a deal-breaker, I can add a pref, but I would prefer
to avoid it if possible.

Is this feature enabled by default in sandboxed iframes? Yes

DevTools bug: N/A (though perhaps there's something devtools can do here?)

Do other browser engines implement this?

Yes, both Safari and Blink ship this, in versions 12 and 69 respectively.

web-platform-tests: https://wpt.fyi/results/css/css-env

Is this feature restricted to secure contexts? No (as all CSS syntax
features)

Thoughts?

-- Emilio

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1298537#c7

[Ehsan Akhgari]

On Fri, Nov 2, 2018 at 5:26 PM Emilio Cobos Álvarez <emi...@crisal.io>
wrote:

> This is mostly to prevent compat headache in mobile, hopefully prevent
> other vendors from shipping new un-spec'd env variables, and encourage
> people to use the fallback value if new environment variables are added
> in the future.
>

> Thoughts?
>

I think the rationale for shipping this, given our past experience with how
developers have used WebKit/Chrome specific features on mobile is
reasonable.

Thanks for thinking ahead of the compat issues.

--
Ehsan