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

Re: [css-variables] -- considered harmful

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 4 Nov 2015 12:41:54 -0800
Message-ID: <CAAWBYDB_r6u1VmOgkEG-_a5=SJv80Y_fjskgPNxCe41VuOG5TA@mail.gmail.com>
To: Daniel Glazman <daniel.glazman@disruptive-innovations.com>
Cc: "www-style@w3.org" <www-style@w3.org>
On Mon, Nov 2, 2015 at 1:57 AM, Daniel Glazman
<daniel.glazman@disruptive-innovations.com> wrote:
> Hi there,
>
> I just stumbled upon a set of slides authored by Wilson Page from
> Mozilla about WebComponents in Gaia. And in this set, I found the
> following slide (please note these great slides are just a live
> example of CSS Variables usage and I link to a screenshot of them here
> only as such):
>
>   http://pbs.twimg.com/media/CSyy2UGWcAA2lbh.png
>
> Reading this slide triggered many, many comments here.
> So I'd like this mailing-list to record my POV on the -- syntax:
>
> 1. I still find it our ugliest syntactic decision in 20 years
> 2. I still find it incredibly error-prone
> 3. it allows an author to write the perfectly valid
>
>    .two-columns {
>      column-count: var(--column-count);
>      -moz-column-count: var(--column-count);
>      -webkit-column-count: var(--column-count);
>      --column-count: 2;
>    }
>
>    and such a rule seems to me so awful I'm shaking my head in despair.

That code is ugly because it's doing a lot of prefixing. It's ugly
regardless of what you actually do with it.  In this particular case
the variable feels like overkill, since it's just abstracting away the
"2", but in many other cases this code will be equal or better than
the "repeat the entire thing" practices of today.

Anyway, this is *far* from a core use-case for variables. I really
don't care what this particular pattern looks like.

> Custom Properties are - I did not change of opinion - a superb way
> of nicely adding variables to CSS. But first, if they are 'properties',
> I don't think we should be able to give the same name to a property and
> a custom property; one could argue the names will never be the same
> since -- is part of the custom property's name... I'm far from
> accepting that argument as enough. I think we're making a very bad
> decision allowing things like 'background: var(--background)'. I
> perfectly understand the technical details here, and I am replying it's
> also our duty to care about the non-technical details that matter
> to our main users, web agencies.

This is impossible.  It would mean making valid custom properties
invalid when we introduce new properties.  It defeats the *entire
point* of namespacing custom properties.  If we wanted to do this, we
wouldn't have used a distinguishing sigil at all; there's about as
much breakage between your suggestion and "just let authors define
their own properties with any name".

> Second, from a readability and maintainance point of view, even $foo
> would be better than --foo. Unfortunately, $foo is impossible to avoid
> collisions with CSS preprocessors. But that's probably not a good enough
> reason to pick up a double dash. If $foo is universally understood as a
> variable, --foo is universally understood as a decrement. A very bad
> choice again.
>
> It's still time to offer better than what we have now.

No, there is no time to change this.  Variables have been in Firefox
for a year+, they're now in WebKit and Blink (just landed in our
Nightly yesterday, I think).  There is code in the wild that depends
on this, there's tons of tutorials out there for the spec, and I'm not
willing to invalidate that.  As well, the only other candidate sigil,
$, is already used by multiple preprocessors for a *different* notion
of variable (lexically-scoped substitutions), and it would be a
terrible idea to invade that space.  I'm not willing to be overtly
hostile to preprocessors for one of their most widely-used features.

~TJ
Received on Wednesday, 4 November 2015 20:42:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:58 UTC