1525249 - env(safe-area-inset-*) part is evaluated in otherwise invalid expression

Status: RESOLVED INVALID

(Firefox :: Untriaged, defect)

Description

[narrowtux]

Attachment: Screenshot 2019-02-05 at 12.37.51.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36

Steps to reproduce:

Using the following CSS code

padding-left: 15px;
padding-right: 15px;
padding-left: max(15px,env(safe-area-inset-left));
padding-right: max(15px,env(safe-area-inset-right));

which is the recommended way to implement safe area insets for iPhone X Notch with default paddings.

More info:

When I use max(15px, 30px), Firefox says the rule is invalid.
In combination with env() it seems to only parse the env part and ignore the max part.

It would be preferable if firefox would invalidate the entire rule and instead use the first variants as default.

Actual results:

On desktop, the resulting padding-left/right values are 0px.

Expected results:

The resulting padding-left/right values should be 15px.

Comment 1

[narrowtux]

To make this clearer: even some obviously wrong input like

padding-left: ahisudhaisud ashd iahsod ahsd uahodu 32478128934ho^&*%^^RT env(safe-area-inset-left);

is accepted and evaluated to

padding-left: 0px;

Comment 2

[Max Arnold]

Also see https://bugzilla.mozilla.org/show_bug.cgi?id=1523970#c2

Comment 3

[Emilio Cobos Álvarez (:emilio)]

This is per spec. https://drafts.csswg.org/css-env-1/#safe-area-insets:

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.

Chrome used to violate their own spec. I fixed that in https://bugs.chromium.org/p/chromium/issues/detail?id=921152.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

You need to use @supports to use max + env.

Comment 5

[Niklas Klein]

I disagree with Emilio's conclusion since the second part he cited explains that the syntax-check must be done after substitution

It is only syntax-checked at computed-time, after env() functions have been substituted.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

That's true, and substitution happens at computed value time, not at parse time. It's the same as CSS variables. If you do:

--my-variable: 40px;
padding: 10px;
padding: something-nonsensical var(--my-variable);

You're never going to end up with a 10px padding.

Comment 7

[Niklas Klein]

See:

ISSUE 4 Define when substitution happens. It has to be before var() substitution. Alternately, should env() substitution happen at parse time, so unknown variable names cause it to fail syntax checking? There’s no particular reason to have it happen at computed-value time, like var() does—that was to ensure that custom properties could inherit their value down before they were picked up by a var().

Emilio's example just doesn't make sense to me.

If I have:

padding: 10px;
padding: something-nonsensical 15px;

I'm going to end up with 10px - why should that be any different just because there is an env statement in it? I just can't believe that is what the author of the spec intended. Very confusing to me. Anyhow, thanks for looking into it.

Comment 8

[Emilio Cobos Álvarez (:emilio)]

(In reply to Niklas Klein from comment #7)

ISSUE 4 Define when substitution happens. It has to be before var() substitution. Alternately, should env() substitution happen at parse time, so unknown variable names cause it to fail syntax checking? There’s no particular reason to have it happen at computed-value time, like var() does—that was to ensure that custom properties could inherit their value down before they were picked up by a var().

Well, the other section of the spec I quoted seems pretty clear to me. You can't substitute them at parse-time in any case, since the values can change, e.g., on orientation changes.

Why should that be any different just because there is an env statement in it?

Same reason why it is different when there's a var() function in it. env() were modeled after var() functions.

Note that we objected to it in https://github.com/w3c/csswg-drafts/issues/3285. But it was too late, probably, since Safari shipped env() without any kind of spec or discussion with the Working Group, and working like CSS variables. Chrome and us effectively implemented the same (modulo that bug I fixed in Chromium) and wrote a spec. Maybe WebKit could've consulted the CSSWG before shipping env, and the story would be different.

Comment 9

[Niklas Klein]

ok, thanks