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

Hi,

Maybe it's not known that I am one of the two developers who are actively
developing Sass. I understand that the more alike the syntax of CSS is to
the syntax of Sass, then it creates more problems for our users which we
will need to solve. You have my permission to make these headaches for us
if the result is a better CSS -- I don't ever want to hear Sass being used
as an excuse for making sub-optimal syntax decisions. We have the luxury of
being able to provide updates, deprecate syntax and introduce new concepts
at a much faster rate than the CSSWG. I encourage you to make our lives
very hard over the next year or two. We love a challenge. We also very much
want you to see Sass as a proving ground for new concepts so that
stylesheet authors can provide feedback sooner in the specification
process. Please let us know how we can help.

Cheers,
Chris Eppstein

On Mon, Feb 20, 2012 at 9:24 AM, Sylvain Galineau <sylvaing@microsoft.com>wrote:

>
> [Florian Rivoal:]
> >
> > On Fri, 17 Feb 2012 23:35:09 +0100, Chris Eppstein <chris@eppsteins.net>
> > wrote:
> >
> > > What's wrong with using $?
> > >
> > >  :root { $accentColor: green; }
> > >   h1 { color: $accentColor; }
> >
> > One obvious conflict many seem to be overlooking is the conflict with the
> > use of $ in css preprocessors.
> >
> > IMO, the proposal for variables is great, but it is quite different from
> > what is currently found in preprocessors like sass. Sass also offers
> > mixins.
> >
> > In sass, both variables and mixins use $ as part of their syntax. If we
> > start allowing $ in css, sass probably needs to be changed to use
> > something else, and I don't think this is desirable.
> >
> > Compatibility with sass as such isn't an important goal for the CSSWG,
> but
> > it is a good example of why changes to the core grammar are not
> desirable,
> > as they make break unsuspecting tools in the wild that rely (maybe
> > unknowingly) on the core grammar staying what it is.
> >
> Indeed; asking for this feature to use an already-familiar syntax is a
> request
> that comes often in informal discussions but then server-side code needs
> to be
> able to tell them apart. Most importantly, it should imo be easy for
> authors to
> tell which is the standard client-side CSS one.
>
>