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

On Tue, May 22, 2012 at 5:10 PM, Ojan Vafai <ojan@chromium.org> wrote:
> 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.

Agreed.  I think this is just personal preference.  I don't share
Florian's fear that authors will be confused about its existence as a
property.  It's pretty obvious when you see something like:

foo {
  $bar: blue;
}

That "$bar" is something like a property.


>> 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.

Yes, it's a small matter for implementations.

More importantly, this is prioritizing theoretical purity and minor
implementation convenience over author convenience, which is the wrong
ordering of constituencies.


>> 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.

The only two extensions I know I want right now are (1) the ability to
specify a default value to be used when a var is invalid or undefined,
and (2) the ability to grab the value of a variable from the parent
(the inherited value) rather than from the current element.

Under the current syntax, these would look something like this:

color: var(bar) // normal
color: var(bar, red) // default value
color: parent-var(bar) // bar from the parent
color: parent-var(bar, red) // bar from the parent, with a default value

In the new syntax, it would look something like this:

color: $bar //normal
color: default-var($bar, red) // default value
color: parent-var($bar) // bar from the parent
color: parent-var($bar, red) // bar from the parent, with a default value


>> 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.

More importantly, one of the maintainers of the SASS language
explicitly told us not to worry about this issue, because SASS will
change around CSS.  He absolutely does *not* want us to make decisions
about CSS syntax based on avoiding confusion with SASS.  I
respectfully suggest that we listen to him about his own project. ^_^

~TJ

Received on Wednesday, 23 May 2012 17:33:53 UTC