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

[cssom] New object or same object for getComputedStyle (was: Re: [cssom] Methods instead of attributes for usedStyle et al)

From: Simon Pieters <simonp@opera.com>
Date: Wed, 14 Aug 2013 10:56:40 +0200
To: "www-style@w3.org" <www-style@w3.org>, Fran├žois REMY <francois.remy.dev@outlook.com>
Message-ID: <op.w1stsqvyidj3kv@simons-macbook-pro.local>
On Wed, 14 Aug 2013 07:26:19 +0200, Mike Sherov <mike.sherov@gmail.com>  

>> getComputedStyle returns a new object each time even if it gets invoked  
>> with the same arguments in WebKit/Blink/Gecko, but not in IE10:
>> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2449
>> Does anyone have an opinion about which is better, or should I just go  
>> with the majority? Is getComputedStyle often invoked with the same  
>> arguments in a tight loop in the wild?
> jQuery used to call gCS in a tight loop (for animations). In fact, a
> recent optimization for Webkit I did passes the result around to avoid
> multiple lookups. The savings were significant. I can dig up my old
> perf results if you're interested.


On Wed, 14 Aug 2013 02:22:31 +0200, Fran├žois REMY  
<francois.remy.dev@outlook.com> wrote:

> Ooops. Since the object was live, I assumed it would be the same object  
> every time. I happen to call getComputedStyle inside loops from time to  
> time (because I use recursive functions and do not/cannot pass all the  
> style objects as arguments, or because of copy-paste).


> I didn't notice any slow down due to it, but I'll try to optimize that  
> anyway. I wonder if replacing the gCS implementation with one with weak  
> maps isn't a good idea, then.
> I suppose the advantage of returning a fresh object is that people  
> cannot leak info on the computed style of an element (put expando on it  
> and leak the object forever) or corrupt it. On the other side, it seems  
> like a strange edge case to me which may not be worth the cost.

I think the main advantage is that it's slightly simpler to implement and  
doesn't result in "memory leak", but at the cost of worse perf for pages  
that invoke it many times with the same arguments.

> Another solution would be to "freeze" the object so that it simply  
> cannot accept expandos or custom things (outside its prototype chain).  
> Is IE's object frozen? Or is it like TextNodes (ie: the returned object  
> is the same as long as it's not GCed, but all expandos are lost after  
> the GC because a new object is created then)? 		 	   		

IE10 allows expandos to be set.  

It seems IE10 doesn't seem to GC the object.  

For getElementsByTagName, the DOM spec allows the same object to be  
returned for the same argument, but also allows a new object [1], since  
there are both cases on the Web that invoke it with the same argument in a  
loop and also cases that invoke it with different arguments but many  
times. IIRC, several browsers return the same  object for  
getElementsByTagName but also allow it to be GCed. It might be a good idea  
to give getComputedStyle the same treatment, but it would be nice with  
some more data or indication from implementors whether they are interested  
in doing this optimization for getComputedStyle.

[1] http://dom.spec.whatwg.org/#concept-getelementsbytagname

Simon Pieters
Opera Software
Received on Wednesday, 14 August 2013 08:51:43 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:14:30 UTC