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

Re: [css-variables] Why so inefficient?

From: darkdragon <darkdragon-001@web.de>
Date: Sun, 21 Feb 2016 19:49:18 +0000
Message-ID: <CAAOCJVDTNwBR+ZUx4kLN3spMvFPQgEjoh+aE_FmnL3T2OeEGNg@mail.gmail.com>
To: www-style list <www-style@w3.org>
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 first putting the fallback
and then providing an alternative if supported.

background: #ffffff; /* fallback */
background: url(../image.png) repeat; /* try */

Analog to this, you could do the same for variables:

width: 20px; /* fallback */
width: --foo; /* try */

So using an additional notation var(--name, fallback) is confusing and not
consistent and provides multiple ways of achieving the same thing.


Further the choice for "--" which is the same for browser-specific
properties like "--webkit-border-radius" etc. is also confusing.
Received on Wednesday, 24 February 2016 18:22:07 UTC

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