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

On Wed, May 23, 2012 at 10:32 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

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

This could still be var($bar, red) and var($bar) could still work. $bar
could just be an alais for it. Any subset of these options for dealing with
default values seem fine to me.


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

The new syntax looks strictly better. It prioritizes making the common case
more readable (or at least more concise) and easier to use without making
the less common cases any worse.


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