W3C home > Mailing lists > Public > www-style@w3.org > February 2011

Re: CSS Variables

From: Alex Russell <slightlyoff@google.com>
Date: Mon, 7 Feb 2011 20:39:43 -0800
Message-ID: <AANLkTi=dAGftj4=nE0P-KYQFZuF2dYfNnCY5m+68d6AK@mail.gmail.com>
To: Peter Beverloo <peter@lvp-media.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Daniel Glazman <daniel.glazman@disruptive-innovations.com>, www-style list <www-style@w3.org>
On Sun, Feb 6, 2011 at 4:36 AM, Peter Beverloo <peter@lvp-media.com> wrote:

> On Sun, Feb 6, 2011 at 12:32, Daniel Glazman
> <daniel.glazman@disruptive-innovations.com> wrote:
> >
> > Le 06/02/11 01:34, Tab Atkins Jr. a écrit :
> >>
> >> The syntax isn't complex.  What we're going with so far is this:
> >>
> >> @var $foo red;
> >
> > I don't understand that $ at all and I think it is useless. Just make
> > the first parameter following @var an ident and that's enough. Using
> > $var to ACCESS a variable is fine, modulo the impact on parsing. I admit
> > I haven't thought at it yet. Thinking out loud, I think the var()
> > notation is better because more conformant to CSS's common practice.
> > It will also be easier to implement.
> > I don't think the preprocessing-on-server-side argument is a good one.
> > The purpose of a Variables spec is to obsolete such preprocessing
> > anyway.
> Omitting the dollar-sign prefix would certainly have my preference, as
> long as it's for both declaring a variable as for using a variable.
> While potentially minor, requiring authors to declare a variable
> without the prefix, and use it with the prefix, would create an
> inconsistency and add to the complexity of using variables.

That was exactly the objection that motivated the current use of "$" in

>  Therefore
> I'd be in favor of the following:
> @var foo red;
> bar {
>    color: var(foo);
> }

This was my preference at first, but I eventually changed my mind.

After some experience with the "var()" syntax via a pre-processor, it
eventually wound up littering our code everywhere with syntax that wasn't
trivial to un-pack when looking at it. The final ")" can be a long way from
the "var(" component, and it's just a whole lot to type and read.

> Furthermore, I'm curious about the naming requirements for variable
> identifiers.  Which characters are allowed, and are the identifiers
> case-sensitive?
> One part of your blog post I am opposed to is the inclusion of CSS
> Modules.  The concept closely approaches that of CSS Namespaces, and
> when talking about "CSS Modules", the first thing that comes to mind
> are the modules which are part of CSS Level 3.  Neither two
> definitions of namespaces nor two definitions of modules can be
> desirable.
> Based on the fact that the namespacing concept is already available in
> CSS, I'm more in favor of advocating prefixing of variable names to
> authors from the first ED forward (e.g. @var csswg-example red).  This
> would be consistent with other parts of their CSS and JavaScript code
> as well, which many projects and libraries already do.

Saying that things are "consistent with JavaScript" isn't particularly
helpful. The shared global NS in JS is a high-priority error that TC39 is
working in various ways to correct (Simple Modules, lexical variables,
etc.). Forcing discipline and wordy names in CSS is no better.


> Regards,
> Peter Beverloo
Received on Tuesday, 8 February 2011 04:40:42 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:43 UTC