W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Re: [WebTiming] HTMLElement timing

From: Jonas Sicking <jonas@sicking.cc>
Date: Wed, 27 Jan 2010 00:12:39 -0800
Message-ID: <63df84f1001270012r582b991drf5662795ea4084ab@mail.gmail.com>
To: Zhiheng Wang <zhihengw@google.com>
Cc: public-webapps@w3.org
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.

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

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

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.

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

/ Jonas
Received on Wednesday, 27 January 2010 08:13:36 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:36 GMT