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

Re: [css-variables] Why so inefficient?

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 23 Feb 2016 12:05:02 -0800
Message-ID: <CAAWBYDBh0vahHDPbA-jGcbmMjvomiOyH9FvZdxfe3uvwpnTivw@mail.gmail.com>
To: darkdragon <darkdragon-001@web.de>
Cc: fantasai <fantasai.lists@inkedblade.net>, www-style list <www-style@w3.org>
On Sun, Feb 21, 2016 at 11:40 AM, darkdragon <darkdragon-001@web.de> wrote:
> On Thu, Feb 18, 2016 at 4:28 AM, fantasai <fantasai.lists@inkedblade.net>
> wrote:
>>
>> On 02/16/2016 06:35 PM, Tab Atkins Jr. wrote:
>>>
>>> For two, var() is required in some circumstances, like when you want
>>> to provide a fallback.  In general, a language shouldn't provide
>>> multiple ways to do something unless there are good reasons for each,
>>> and there isn't a strong reason to omit var() when you're not using
>>> any other functionality, so I don't allow it.
>>
>>
>> I'm not convinced restriction is worth the cost. Imho a bare --foo
>> should be valid as a variable use. If fallbacks are needed, then they
>> can be provided with functional notation.
>>
>> If I was designing from scratch, we could have
>>   width: --foo;
>>   width: fallback(--foo, 20px);
>> but failing that I guess
>>   width: --foo;
>>   width: var(--foo, 20px);
>> is fine.
>
>
> I think the way of defining fallbacks in css is as follows:
>
> width: 20px; /* fallback */
> width: --foo; /* try */

No, that's how you fallback *for unsupported things which will cause
parsing errors*.  The parser throws out the unknown thing as nonsense,
recovers at the next semicolon, then resumes parsing.

Variables dont' cause parsing errors (assuming the browser supports
them at all).  That style of fallback doesn't work for this.

Even if it did work, it's too "wide" - it wipes out the entire
declaration.  Having to repeat an entire declaration just to replace a
var() with a default value would be annoying in many cases, and make
editting/maintenance more error-prone.  And that's just a *single*
variable - trying to handle *two* vars in a single declaration, each
of which have default values, requires repeating the line *four times*
to handle all the cases properly.

> Further the choice for "--" which is the same for browser-specific
> properties like "--webkit-border-radius" etc. is also confusing and not
> consistent.

No, browser prefixes use a *single* leading dash.  Variables uses two
leading dashes specifically to avoid stomping in that namespace and
causing accidental clashes.  (Previous ideas included a single leading
underscore, or a leading "var-" prefix, which at the time matched how
custom properties were named as well.)

~TJ
Received on Tuesday, 23 February 2016 20:05:50 UTC

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