- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 27 Jan 2010 00:12:39 -0800
- 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 UTC