[webkit-dev] Feature removal: CSS variables

Jon Rimmer jon.rimmer at gmail.com
Sun Apr 7 16:17:27 PDT 2013

I was asked to provide feedback via the mailing-list and not the bug, so
here goes.

As a web developer, I'm very disappointed to see this feature removed. I
would prefer it to be enabled in Safari and maintained by the remaining
WebKit contributors. Especially now, removing a feature like this sends an
unfortunate signal about your intentions for the project and your
commitment to continued advancement. A commonly repeated narrative
regarding Google's fork is that they were the only ones dragging WebKit
forward, and this doesn't do a lot to disprove it.

The debate over the syntax of "CSS variables" is long and storied, and is
marked by misused terminology and misunderstanding in general. Most
objections from developers stem from a preference for a $foo style syntax,
as used in the SASS preprocessor. However, SASS's kind of "variables" are
not really variables, they are preprocessor defines. "CSS variables" as
implemented by this feature are also not variables either, nor do they
match what SASS does. They as better referred to custom properties, and
indeed, the full title of the specification has already changed to reflect
this[1]. The $foo syntax is not a good fit for custom properties, but is
being reserved for other, variable-esque things, that might be added to CSS
in the future[2].

CSS Custom Properties are an important feature. They support the basic use
case of defining some value, like a colour, in a single location, then
using it in others. Unlike preprocessor defines however, they participate
in the cascade, meaning a value can easily be overridden for a section of a
page if required. They also play an important role in Web Components, where
they provide a method for encapsulated widgets to provide a styling
interface to their users[3]. Furthermore, it's also possible to imagine CSS
libraries like Bootstrap using custom properties to allow them to be
configured without having to rebuild the entire library with the
preprocessor, or as a way to provide custom styling information that can be
consumed by JavaScript UI libraries such as jQuery Mobile (in that sense,
they are more analogous to HTML's data-* attributes than variables).

As well as being in Chrome, custom property support is also being developed
by Mozilla[4]. It is an actively edited W3C spec that is expected to reach
Last Call status soon[5]. Given that situation, removing it from WebKit
seems a very negative step. If it is removed and remains unimplemented in
Safari and other WebKit browsers, then they will continue to fall behind
competing layout engines. If it is removed now and must be resurrected at a
later date, then the total cost is likely to be greater than making the
effort to turn it on and take ownership of it *now*.

It seems like WebKit is at a crossroads: You can deal with the engineering
shortfall that Google's departure has left you with by simplifying the
architecture, cutting out their features and continuing at a reduced pace,
or by stepping up yourselves to fill the gap. I think it would be better
for the web and for WebKit if you chose the latter.

[1] http://dev.w3.org/csswg/css-variables/
[2] http://www.xanthir.com/blog/b4KT0
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=773296
[5] http://www.w3.org/blog/CSS/2013/03/28/css-variables-updated/


Jon Rimmer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130408/4dadcac3/attachment.html>

More information about the webkit-dev mailing list