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

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

From: Odin Hørthe Omdal <odin.omdal@gmail.com>
Date: Tue, 5 Apr 2016 15:33:32 +0200
Message-ID: <CACZFz7MZ2uHpfGEzuq2=qZSje8EqO3vP=iPXpzQK=N7dKwyHVQ@mail.gmail.com>
To: www-style@w3.org
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:

> Without fallback, the app author must supply a value for every variable that your component uses. With fallback, the component author can supply defaults, so the app author only needs to supply values for the variables they wish to override.

To me this doesn't ring true (at that part of the text), the component
author could simply declare her custom properties and then the app
author doesn't have to supply those values.  If I'm not mistaken, then
maybe rewriting that part, or simply mentioning why fallback is better
than properties in such a case would go a long way.  I'd come with a
suggestion, but if you agree, I bet you'll better know what to write
anyway.


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.

2: https://drafts.csswg.org/css-variables/#apis


Other than that, I found the spec easy to read and follow.  Good job :)

-- 
Beste helsing,
Odin Hørthe Omdal <odin.omdal@gmail.com>
English, technical: http://tech.velmont.net
Norsk, personleg: http://velmont.no
Received on Thursday, 7 April 2016 20:53:54 UTC

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