W3C home > Mailing lists > Public > www-style@w3.org > May 2012

Re: [css-variables] Using $foo as the syntax for variables

From: Ojan Vafai <ojan@chromium.org>
Date: Tue, 22 May 2012 17:10:39 -0700
Message-ID: <CANMdWTsT_LAyTYKNSBeuWE5cf851vS1KOS_UmGirsqSAUcDpCQ@mail.gmail.com>
To: Florian Rivoal <florianr@opera.com>
Cc: www-style@w3.org
On Tue, May 22, 2012 at 1:24 AM, Florian Rivoal <florianr@opera.com> wrote:

> On Mon, 21 May 2012 23:30:34 +0200, Tab Atkins Jr. <jackalmage@gmail.com>
> wrote:
>
>  Right now, the Variables draft makes variable names be simple idents,
>> and uses the var() function to reference them.  This was *one* option
>> for using variables, which I chose on the hope that it would make it
>> easier for the group to accept the draft.
>>
>> Another possibility is to use a $ glyph as a prefix.  This was
>> suggested by several people in the WG after I presented the current
>> Variables draft, and it matches the way SASS does variables.  Chris
>> Eppstein, one of the SASS devs, has been telling me repeatedly that
>> the $foo syntax will be easier for devs.
>> [...]
>>
>
> I prefer the current var- syntax over $ for several reasons:
>
> 1)
> Because var-foo looks like regular property, its hint towards the
> fact that the behavior involves the cascade. $foo doesn't. It looks
> like SASS or perl or BASIC variables, which don't involve the
> cascade, and that will probably confuse authors.
>

At some level, this is just bikeshedding. I prefer red, you prefer blue,
right? IMO, there is a long-history of browsers shipping just slightly too
bulky APIs for them to be as convenient as those provided by libraries
(e.g. querySelector/querySelectorAll, vs find/findAll) and this would be
continuing that tradition. The small amount of (arguable) language
consistency we gain by avoiding $ is not worth the loss in ease-of-use.
But, this is entirely subjective and I don't see any way to come to
agreement on this.

2)
> It is less disruptive of the grammar
>

This doesn't seem like a big deal to me. The edge cases where this matters
are again not worth the cost.


> 3)
> While the various extensions proposed can be done as you said with
> a function on top of the $ syntax, it feels hacky to me. Expressing
> it based on the var() syntax seems much more natural.
>

This, to me, is the only compelling argument against the $ syntax, but I
don't have a clear sense of what the other extensions people have proposed
other than default value, which I think could be addressed alongside the $
syntax. Would someone be willing to summarize what the proposed extensions
are?

I've tried to keep up with the deluge of variables discussions on this
list, but there's just too been much.


> 4) Because SASS variables and CSS variables behave differently,
> I can reasonably see authors wanting to use either, or
> even wanting to use both in the same style sheet. Using the same
> syntax is asking for trouble.
>

I think this is worth considering, but this doesn't convince me that we
should make the API we ship less convenient for authors coding directly to
the platform.
Received on Wednesday, 23 May 2012 00:11:50 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:54 GMT