Re: [WebTiming] HTMLElement timing

Hi, Jonas,

   Thanks for the comments. pls find comments inline.

On Wed, Jan 27, 2010 at 12:12 AM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Tue, Jan 26, 2010 at 11:39 PM, Zhiheng Wang <zhihengw@google.com>
> wrote:
> > Folks,
> >      Thanks to the much feedback from various developers, the WebTiming
> > specs has undergone some
> > major revision. Timing info has now been extended to page elements and a
> > couple more interesting timing
> > data points are added. The draft is up
> > on http://dev.w3.org/2006/webapi/WebTiming/
> >      Feedback and comments are highly appreciated.
>
> I take it the idea is that you can get when we for an <img> element
> start fetching the image, when image data starts arriving etc. I'd
> prefer if the spec had a comprehensive list of elements that this is
> expected to be implemented on.
>

   Right now only embedded content
elements<http://dev.w3.org/html5/spec/Overview.html#embedded-content-1>
require
these info. An explicit list
might be better though, e.g., <script> is not classified as embedded
content.



>
> Extending this to elements introduces *significantly* more
> implementation cost. Is it really worth it? My concern is that this
> spec already had fairly high cost/benefit ratio since it doesn't add
> any "new" functionality to the web platform, it "just" lets devs do
> more accurate performance measurements. And it's far from easy to
> implement since much of the information isn't available outside of the
> networking code (and many times there only available on a different
> thread).
>

   Certainly the overhead of implementing the specs should be evaluated. It
should be
done while we are looking into more browser-specific implementations. Right
now I want
to be as specific as possible in the specs. But much implementation overhead
can be
avoided if we can tune the specs to accept some slight "inaccuracy", say,
taking the time
of the first callback from the data socket instead of the actual first
byte time as responseStart.



>
> Also, what is the use case for the "Ticks" interface?
>

   The Ticks interface is a convenient way to store time measurements and
retrieve it later on a page.
I will have some example there.



>
> I would really encourage that this spec be reduced to the most
> important parts first and wait for browsers to catch up before adding
> "nice to have" features.
>

   Agree and we do keep that in mind. Most of the the properties specified
right now are
on the critical path of user perceived latency though.



>
> If implementations implement progress events on the various elements
> it would seem like you would get most of the advantages from this
> spec.
>

   The progress events are great, except that they mostly focus on
downloading the content but
not much about everything else, say, parseStart.


cheers,
Zhiheng



>
> / Jonas
>