W3C home > Mailing lists > Public > www-style@w3.org > July 2015

Re: [css-variables] Custom property declaration invalid at computed-value time

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 23 Jul 2015 11:16:13 -0700
Message-ID: <CAAWBYDA+B-zrP6eNak_L-B2oCiED1sqoz1fQT+nqNN_WntaP1w@mail.gmail.com>
To: Simon Sapin <simon.sapin@exyr.org>
Cc: www-style <www-style@w3.org>, Cameron McCormack <cam@mcc.id.au>
On Thu, Jul 23, 2015 at 8:09 AM, Simon Sapin <simon.sapin@exyr.org> wrote:
> https://drafts.csswg.org/css-variables/#invalid-variables
>> A declaration can be invalid at computed-value time if it contains a
>> var() that references a custom property with its initial value, as
>> explained above, or if it uses a valid custom property, but the
>> property value, after substituting its var() functions, is invalid.
>> When this happens, the computed value of the property is either the
>> property’s inherited value or its initial value depending on whether
>> the property is inherited or not, respectively, as if the property’s
>> value had been specified as the unset keyword.
> If that property happens to be a custom property, this text says that it
> should get its inherited value. (Since all custom properties are inherited.)
> Firefox however gives it its initial value.
> Test case: http://dabblet.com/gist/1f0d2d5a086181e41887
>   html { --a: green; color: red; }
>   body { --a: var(--b); color: var(--a); }
> --a on body is invalid at computed value time.
> Per the spec, it gets its inherited value green and body text is colored
> green.
> In Firefox, --a on body seems to get its initial value, which makes color on
> body invalid at computed-value time as well, causing the body text to be
> colored red, the inherited color value.
> I found this spec behavior mildly surprising compared to how dependency
> cycles are resolved (all custom properties involved get their initial
> value), but I don’t have a strong preference.

A dependency cycle in custom properties is an error, full stop.
Handling it in the simplest way possible is best.  Trying to correct
the error could lead to hiding it and making fragile, hard-to-predict

When normal properties use var() and end up incorrect, tho, that
ideally *should* be handled by throwing it out at parse time, same as
we do for violating the grammar without var().  But that's not
possible, of course.  So I get as close to "pretend it wasn't
specified" as I can, and treat it as "unset".

Received on Thursday, 23 July 2015 18:17:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:18 UTC