Re: [css-variables] the new ED for CSS Variables

Comments inline:

On Mon, Feb 20, 2012 at 8:23 PM, Sylvain Galineau <sylvaing@microsoft.com>wrote:

>  I don’t mind making your life difficult as much as I mind making
> authors’ lives difficult. Maybe there is a benefit in making tools like
> yours change their syntax so that CSS can take over the syntactical pattern
> you’ve set no matter how weird and painful the transition is. If the case
> can be made, let’s hear it.
>

The "Less" css preprocessor lets users define variables using the @ sigil.
Clearly this was a horrible language design choice. Does this mean that we
should not define new @ rules with syntax that might be ambiguous with Less
variables? Clearly not.

CSS extension syntaxes have an inherent risk that CSS itself will change in
some incompatible way. I am simply saying that as a matter of process, the
CSSWG should not consider these issues in the design process of CSS itself
because it's untenable and creates an unsatisfiable demand.

I would also note that the poor syntax choice for Less's variables is
rooted in the same mistake that is being made here: "I didn't want to
introduce new syntax" is the stated reason for why Less uses @ as a
variable sigil.

Also note that Sass initially fell into this same line of thought and used
! as a variable sigil. So we have already transitioned our users once
through a dramatic syntax change. We did this by creating a Sass2-to-Sass3
compilation mode that re-wrote the user's files with a single command line
invocation.

As you can see, we are adept at making author's lives pain free and have a
mature infrastructure in place to continue to manage the evolution of
Sass's syntax as well as whatever the CSSWG can throw at us.


> ****
>
> ** In the meantime I don’t see the point of confusing authors accustomed
> to ‘this is Sass’ with questions like ‘mmm…is this Sass or CSS?’. That just
> seems unnecessary.
>

Well first and foremost you're assuming that this syntactic difference is
relevant to them. While it requires thought, my feeling is that Sass would
change it's variable semantics to be a proper superset of CSS's variable
semantics and then we will have the ability to compile the output to CSS2.1
or to a version of CSS that supports variables (or both via configuration
options). Once variables become widely implemented across the browser
landscape, we could simply change our default compilation mode.

The same goes for any number of new features that should come to CSS like
mixins, class inheritance, etc. Our goal will be to make the transition
period for Sass users as smooth as possible and to keep them on the golden
path to the future of CSS authoring.

While the benefits of preprocessing css are many, I'd wager that many of
our users don't actually want to use a preprocessor. They're just tired of
waiting for better syntax. Please give them and the massively larger user
base of CSS itself a syntax that is a pleasure to use -- if this means
changing the core syntax, so be it.

Chris