Re: [css-variables] Why so inefficient?

On Tue, Feb 23, 2016 at 5:24 PM, Patrick Dark
<www-style.at.w3.org@patrick.dark.name> wrote:
> On 2/23/2016 3:32 PM, Tab Atkins Jr. wrote:
>> Conditional Rules has nothing to do with variable fallback - it's an
>> expansion on the syntax-fallback behavior that you get from writing a
>> declaration twice, once with new or prefixed values and once with old.
>> As I said in my previous email to darkdragon, even if it *did* apply,
>> it would be *extremely* onerous in practice.  This would fall clearly
>> under the "unless there's a good reason" escape valve.
>
> It seems to be the same thing to me. For example:
>
> * { --text-color: gray(20%); }
> p { color: var(--text-color, hsla(0, 0%, 20%, 1)); }
> table { color: var(--text-color, hsla(0, 0%, 20%, 1)); }
>
> As far as I can tell, that's equivalent to:
>
> * { --text-color: hsla(0, 0%, 20%, 1); }
> @supports (color: gray(0%)) { * { --text-color: gray(20%); } }
> p { color: var(--text-color); }
> table { color: var(--text-color); }
>
> Instead of determining that the property value is valid before using it, you
> use it, throw it away, then use a fallback that has to be repeatedly
> specified. The end result is the same.

Ah, you're mixing up different notions of "fallback", thus the confusion. ^_^

Variable fallback, addressed by the second argument of the var()
function, lets you supply a default value to be used *when the custom
property you're referencing doesn't exist*.  This is necessary, for
example, if you're using variables to theme a Custom Element from HTML
- if the user of your custom element doesn't override some of your
theming variables, you need a way to specify what they should be.
It's also useful for "recursive" definitions of custom properties,
that build up as you nest deeper into the tree (like using a variable
for indentation of nested structures) - the default argument lets you
supply a "base" value for the top-most usage.

You're talking about the much older syntax-fallback that CSS has
always had, where invalid/unrecognized things are ignored, so you can
specify multiple versions of a property and the last valid one wins.
@supports hooks into this, letting you test it directly, so you can do
more than just override a single property when some syntax isn't
supported.

Btw, your example uses bad practices - setting a custom property with
a `*` selector means that the property gets explicitly set on every
single element, and you can't easily override it.  (If you set it to a
different value on some element, the element's children will still
have the "global" value rather than inheriting their parent's value.)
Custom properties are inherited, so if you're trying to set something
for the entire document, just set it once on the root element.  That's
less work for the browser, and lets you override it on parts of your
document if you want.

~TJ

Received on Wednesday, 24 February 2016 01:41:31 UTC