W3C home > Mailing lists > Public > www-style@w3.org > April 2016

Re: [css-variables] Clarify var() fallback value example?

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 8 Apr 2016 13:22:32 -0700
Message-ID: <CAAWBYDAqYEsEp6woTuZCm3V8iHbbPMt8o1TDUf=D6=82EYfUig@mail.gmail.com>
To: Odin Hørthe Omdal <odin.omdal@gmail.com>
Cc: www-style list <www-style@w3.org>
On Tue, Apr 5, 2016 at 6:33 AM, Odin Hørthe Omdal <odin.omdal@gmail.com> wrote:
> Hello!  I want to report a confusing example.
>
> When I was reading the spec from start to end I didn't fully
> understand Example 10[1] in the editors draft.  It says that the
> fallback value in `var(<property>, [fallback])` allows for defensive
> coding for a standalone component, but doesn't say why the obvious
> solution of pre-declaring the variables in the component that has been
> shown earlier is not sufficient.
>
> 1: https://drafts.csswg.org/css-variables/#example-8bfb9889
>
> After reading the entire page, I believe this example requires the
> knowledge of properties with invalid values.  A user of the example
> component down the cascade can "ruin" a custom property, making it go
> #invalid-at-computed-value-time.  If the value is invalid, this
> particular property in the component will be whatever its default
> value is (equivalent to `unset` and not what the component author
> pre-declared her variables to be).  However, the example text does not
> mention that, and also further confuses things by explaining the
> fallback in this way:

No, that's *one* reason, but the major reason is "because
inheritance".  Custom properties inherit by default, so it's perfectly
reasonable for a page author to set a variable at their page root
that's intended to affect a component further down the page.  If the
component author sets all their variables, the page author is then
required to explicitly set the variable on or below the component root
instead.

> Also, I think there's a typo which radically changes the meaning in
> the API section[2].  In this sentence, I believe it should be
> "case-sensitive" rather than "case-insensitive":
>
>> All custom property declarations have the case-insensitive flag set.

Whoops, indeed.  Luckily there's no such thing as a case-insensitive
flag in CSSOM. ^_^

~TJ
Received on Friday, 8 April 2016 20:23:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:02 UTC