W3C home > Mailing lists > Public > public-css-archive@w3.org > April 2019

Re: [csswg-drafts] [css-env-1] Meaning of “syntactically valid” in env() has led to differing nonsense behaviour in browsers: it needs clarifying (#3792)

From: Emilio Cobos Álvarez via GitHub <sysbot+gh@w3.org>
Date: Tue, 02 Apr 2019 17:49:46 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-479117505-1554227385-sysbot+gh@w3.org>
> Chrome decides that since it doesn’t have a foo() function, the value is invalid, and uses 10em. I’d guess it does this at parse time.

This is a Chrome bug, and a fixed one at that (https://bugs.chromium.org/p/chromium/issues/detail?id=921152).

Safari, Firefox, the current spec text, and Chrome (Canary and dev at least, not sure about whether that Chromium patch has made it to a release yet) agree on behavior here.

@SimonSapin filed https://github.com/w3c/csswg-drafts/issues/3285 with a proposal that I believe would give the behavior you want. I think we should close this as a duplicate of that.

> That one could need to wrap the third line up in @supports would be decidedly unfortunate.

I sort of agree on it being unfortunate. I think it's kind of fall-out from env() being initially implemented using the custom properties machinery, and getting an spec retro-fitted... FWIW you only need `@supports (margin-bottom: max(0px, 1px))` or such, though, right?

GitHub Notification of comment by emilio
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3792#issuecomment-479117505 using your GitHub account
Received on Tuesday, 2 April 2019 17:49:47 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:46 UTC