- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 20 Jun 2013 10:27:35 -0400
- To: www-style@w3.org
On 6/20/13 5:24 AM, Alan Cutter wrote:
> At the moment enumeration over a CSSVariablesMap is only indicated in an
> example.
I believe this example is now buggy and should go.
> It is hard to find a concrete specification that it has this behaviour.
That's because it doesn't.
> Previously enumeration was implied by the presence of a getter interface
> method. Is enumeration inherited as part of the MapClass interface?
No, except that presumably the normal ways of working with maps (var key
of map.keys(), var item of map.items(), var item of map) should work here.
> for (var i in el.style.var) {
> // e.style.var[i] is undefined.
> }
Shouldn't happen. This just won't enumerate
> I'm curious whether the reasoning to accommodate this is to allow
> "monkey patching" of the CSSVariablesMap interface.
No, it's to allow you to have a variable named "toString", say.
Consider carefully what the old setup would have done with
e.style.var.toString.
> 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.
Personally, I agree with Tab that things with named getters/setters
should die a horrible death. Doubly so when the set of names is
open-ended as here. Using an object-as-hashtable was the common way to
do this until Map was introduced, but the whole reason Map was
introduced is that the object-as-hashtable approach is busted.
-Boris
Received on Thursday, 20 June 2013 14:28:06 UTC