- From: Alan Cutter <alancutter@chromium.org>
- Date: Thu, 20 Jun 2013 19:24:33 +1000
- To: www-style@w3.org
- Cc: jackalmage@gmail.com
- Message-ID: <CANJJ2CnhriYZ6ofC6U_JZmaxCpPy1T0SKaotSk65j80AmTkBFQ@mail.gmail.com>
Hello, 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 example. 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. Example: 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 Thanks
Received on Thursday, 20 June 2013 12:18:18 UTC