Re: Implementing the web timing spec

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. 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.

thanks,
Zhiheng





>
> / Jonas