1539708 - Including env() in a property value causes an otherwise invalid value to be treated as valid and zero

Status: RESOLVED INVALID

(Core :: CSS Parsing and Computation, defect)

Description

[Chris Morgan]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Give an element this style:

margin-bottom: 1em;
margin-bottom: purple env(bar, green);

Actual results:

The calculated margin-bottom was 0px, because the second rule was treated as valid, but equal to zero.

Expected results:

The calculated margin-bottom should be 1em, because purple green is not a valid value for margin-bottom, and so the second rule should be invalid, leaving the value from the first rule.

Comment 1

[David Olah]

Hi Chris,

Can you please attach a test case so I can reproduce the issue exactly as you managed to?

Thank you!

Comment 2

[Chris Morgan]

I made a simple test case with a different property:

<!doctype html>
<body style="background-color:limegreen;background-color:red env(bar, purple)">
Page background should be limegreen, not white.

But then I tested it in Chrome, and found that it’s white instead of limegreen in Chrome, too.

So I looked at the spec:

If a property contains one or more env() functions, and those functions are syntactically valid, the entire property’s grammar must be assumed to be valid at parse time. It is only syntax-checked at computed-time, after env() functions have been substituted.

As a web developer, I say about it that what Chrome and Firefox are doing is obviously wrong and not-useful behaviour. I’m not familiar enough with the terms it’s speaking of to be certain that what they have implemented is spec-noncompliant (“syntactically valid” at parse time, and “syntax-checked at computed-time”), but I think it’s wrong.

I don’t have access to Safari to check what it does in this case.

---

But here’s another example (closer to what made my coworker find this bug) where Chrome does the sensible thing and Firefox doesn’t:

<!doctype html>
<body style="margin:10em;margin:foo(env(bar, blue))">
Page margin should be large, not zero.

On this, Firefox seems to go with the “syntactically valid” decision, and so apply zero margin. Chrome decides something along the lines of “foo() isn’t a known function, syntactically invalid” despite the presence of env(), and so applies the earlier 10em property.

---

So: we seem to have cross-browser inconsistency here, with at least Firefox and Chrome implementing slightly different nonsense behaviour due to something that could do with a clarifying note in the css-env spec. I’m going to file an issue on https://github.com/w3c/csswg-drafts/issues about it.

Comment 3

[Chris Morgan]

Filed https://github.com/w3c/csswg-drafts/issues/3792. Hold this bug until the appropriate action is determined there.

Comment 4

[Emilio Cobos Álvarez [:emilio]]

This is invalid.

Relevant spec text is https://drafts.csswg.org/css-env-1/#env-function:

If a property contains one or more env() functions, and those functions are syntactically valid, the entire property’s grammar must be assumed to be valid at parse time. It is only syntax-checked at computed-time, after env() functions have been substituted.

Which is exactly what we implement. I actually had to go fix chrome to implement the spec in https://bugs.chromium.org/p/chromium/issues/detail?id=921152.

Safari matches Firefox and the spec here. We proposed https://github.com/w3c/csswg-drafts/issues/3285 to have better behavior here, but it was too late because other engines had already shipped a custom-properties-based env().