Re: [css-variables] Adding a default value to var()

I'm clearly in favor of something like 'default values' for variables. 
However, it can be something like an "auto-fallback variable".

    selector {

        var-link-color-default: blue;
        color: var(xxx);

        /* (var-link-color: red) would override xxx-default (if the browser 
recognizes 'red') */

    }



BTW, I'm also in favor of a mechanism that allows fallbacks in case when a 
browser don't recognize a property value. I know it's not the first time I 
come up with this but in fact, I think we should have a function that 
supports that for any kind of declaration. Having the same kind of fallback 
defined in more than one module is like a sign to me we should implement 
this.

Generally, my proposed syntax is something like:

    selector {

        var-bg: firstOf(
            'black, url(a.png) repeat, url(b.png) repeat-x',
            'black url(ab.png) repeat-x'
        );

        background: firstOf(
            'var(bg)',
            'black'
        );

    }

(Maybe someone someday...)

Best regards,
François





-----Message d'origine----- 
From: Tab Atkins Jr.
Sent: Tuesday, April 03, 2012 3:42 AM
To: www-style list
Subject: [css-variables] Adding a default value to var()

In <https://www.w3.org/Bugs/Public/show_bug.cgi?id=16517>, Roland
requests the ability to add a "default value" to the var() function,
which is used when the reference variable is invalid or missing.

The main use-case for this is to make it easier to use variables as
"extension points", such that you can define several variables as part
of a "theming API" and allow the user or other authors to override
them, but provide reasonable defaults so the user doesn't necessarily
have to override the entire set of variables.

This also brings Variables more in line with the proposed abilities of
SVG Parameters, making it easier to merge the two specs into a single
piece of functionality.  The use-case for default values in SVG
Parameters is especially strong, as it can easily be unreasonable to
ask the user to provide values for *all* the things you may want to
make customizable.

So, should we add this to v1?

(Side-note: Roland's suggestion for fallback to multiple vars -
nesting var() functions - isn't quite necessary.  You can instead just
have the first argument to var() accept a space-separated list of
variable names, and it resolves to the first valid one, only taking
the fallback when none of them are valid.)

~TJ

Received on Tuesday, 3 April 2012 08:29:54 UTC