Re: Implementing the web timing spec

On 4/6/2010 14:19, zhihengw wrote:
> On Mar 30, 1:41 pm, Jonas Sicking<[email protected]>  wrote:
>> On 2/11/2010 11:13, Boris Zbarsky wrote:
>>
>>> On 2/11/10 1:28 PM, Christian Biesinger wrote:
>>>> Would people agree this is useful, and in particular, would the DOM
>>>> peers be willing to accept patches to implement this spec?
>>
>>> So the biggest issue I see here (past the fact that I'm not sure we can
>>> sanely get some of this information) is that any element that exposes
>>> this interface ends up bigger by about 100 bytes, right? That seems a
>>> little unfortunate....
>>
>> One way to solve this would be to attach the timing data to the load
>> event fired from these elements, instead of on the elements themselves.
>
>     To make sure I follow, do you mean allowing GC to remove the timing
> objects earlier if we attach
> DOMTiming to onload? This is an interesting idea and a couple
> developers here actually had some
> discussion on it.

Specifically, to attach it to the Event object fired for the 'load' 
event. Yes, the idea is that the DOMTiming object could be GCed earlier 
since Event objects are often short lived. Of course, if a page want to 
keep the timing data around for longer, it can always hold a reference 
to the DOMTiming object.

> A main downside is that it limits the interface to
> give out data up to the onload event
> only. While right now the attributes mandated by the draft fit that,
> the draft is also open to other
> UA-specific attributes, e.g., pain event, etc.

(I take it you mean the pain*t* event?)

I'm not saying it needs to be exclusively on the 'load' Event. It can be 
attached to other Events as needed as well.

/ Jonas