[webkit-dev] Fwd: Feature removal: CSS variables

Ryosuke Niwa rniwa at webkit.org
Sun Apr 7 17:40:33 PDT 2013


On Sun, Apr 7, 2013 at 4:17 PM, Jon Rimmer <jon.rimmer at gmail.com> wrote:

> 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*.
>

I definitely see a value in keeping the feature.  However, there is a
practical problem of someone having to maintain the code.  Now that all
contributors who have previously worked on this feature has left to work on
Blink, I don't see who can be maintaining this code in WebKit.  Are you
volunteering to maintain the code?  If not, then who is?

Not having this feature will be unfortunate and we might need to add it
back in the future, but that's much better than leaving unmaintained code
in our codebase.

- R. Niwa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20130407/33b71e48/attachment.html>


More information about the webkit-dev mailing list