Re: Implementing the web timing spec

    Forgot to mention that the draft have been updated according to
the feedbacks we received, including
  1) DOMTiming is now a getter (vs. an array of attributes)
  2) Limit the types of elements that must provide DOMTiming
  3) DOMTiming for elements are only available if a meta html header
is set on the root page.

cheers,
Zhiheng

On Apr 6, 2:19 pm, zhihengw <[email protected]> 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. 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