W3C home > Mailing lists > Public > www-style@w3.org > July 2015

Re: [css-variables] feedback

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 10 Jul 2015 17:10:09 -0700
Message-ID: <CAAWBYDC7c4jz2fxWcTJYLTYw2mMxpFtnOGyy3CY40q9sPT7K2Q@mail.gmail.com>
To: raees@thewebsmith.co
Cc: www-style list <www-style@w3.org>
On Wed, Jul 1, 2015 at 9:22 AM,  <raees@thewebsmith.co> wrote:
> First of all, thank you for your work in making of CSS and taking time to
> read this email. I’m Raees Iqbal, a web designer.
> I’ve been following the development regarding CSS variables from about more
> than a year now. The current proposal I see uses “--” to declare variables
> and “var()” to use them. While I’m happy that there has been progress, I’m
> not sure about the suggested syntax.
> I would like to suggest that as most of the web designers and developers are
> familiar with JavaScript notation of variables and some are known to PHP
> style. A similar style should be used in CSS also, for example:
> var baseColor: #444;
> or maybe
> $baseColor: #444;
> h1 {
> color: $baseColor;
> }
> The only use for “$” sign is in “ends with” selector ( eg. [src$=”.jpg”] ),
> so, it will be as much easy for layout engines and there should not be any
> performance difference. But this will be much easier in use, which is the
> core beauty of CSS.

CSS Variables have shipped in multiple browsers, so the syntax is
frozen at this point regardless of the merits of any possible change.
But I can still address your suggestion under the assumption that it's
possible. ^_^

The syntax for variables and custom properties was chosen to fit well
into the existing CSS syntax.  In particular, *declaring* a variable
is done with a custom property, not some new type of variable
declaration statement.  This means that it can be manipulated with the
existing APIs for getting/setting properties, and can be set on a
*non-root* element and only apply to that element and its descendants,
so there's less of a global namespace management issue.  (This was
particularly important for the anticipated use-cases of using
variables to theme web components.)

The var() syntax was used because (a) functions are already familiar,
(b) it makes it more obvious that you're doing something tricky, and
(c) it gives us space to add more features, like the "default value if
the variable isn't set" feature that already exists.  In the future, I
plan to add a parent-var() function (for referring to the value of a
variable on the element's parent, to avoid circular references) and
keeping var() as a function ensures that parent-var(), and anything
similar that I add, have the same "shape" as the plain variable, which
is important for leaning and reading.

Received on Saturday, 11 July 2015 00:10:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:18 UTC