W3C home > Mailing lists > Public > www-style@w3.org > June 2013

[css-variables] CSSVariablesMap enumeration

From: Alan Cutter <alancutter@chromium.org>
Date: Thu, 20 Jun 2013 19:24:33 +1000
Message-ID: <CANJJ2CnhriYZ6ofC6U_JZmaxCpPy1T0SKaotSk65j80AmTkBFQ@mail.gmail.com>
To: www-style@w3.org
Cc: jackalmage@gmail.com

I've taken over the CSS Variables implementation in Blink. I have some
concerns/questions regarding iterating over a CSSVariablesMap object.

At the moment enumeration over a CSSVariablesMap is only indicated in an

var customProps = el.style.var;
for(customPropName in customProps) {
  if( knownCustomPropName(customPropName) ) {
    var customPropValue = customProps[customPropName];
    /* Processing code here. */

It is hard to find a concrete specification that it has this behaviour.
Previously enumeration was implied by the presence of a getter interface
method. Is enumeration inherited as part of the MapClass interface?

I'm concerned this definition of CSSVariablesMap where "get" and "set" are
used in place of the usual getter and setter interface is introducing
strange behaviours into the spec when combined with enumeration. Example:

for (var i in el.style.var) {
  // e.style.var[i] is undefined.

Tab mentioned previously that getters and setters were discarded with the
example that you could add a property to the CSSVariablesMap prototype and
it would appear as a variable when it is not.
CSSVariablesMap.prototype.foo = "bar";
// el.style.var.foo returns "bar".

I'm curious whether the reasoning to accommodate this is to allow "monkey
patching" of the CSSVariablesMap interface. One can still introduce "fake"
variables by overriding the existing prototype methods. Personally I'm not
sure it's worth the effect it is having on the CSSOM API.

Link to draft spec: http://dev.w3.org/csswg/css-variables

Received on Thursday, 20 June 2013 12:18:18 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:12 UTC