- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Fri, 29 Jan 2010 16:15:51 +0200
- To: Zhiheng Wang <zhihengw@google.com>
- CC: public-webapps@w3.org
On 1/27/10 9:39 AM, Zhiheng Wang 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. > > cheers, > Zhiheng Like Jonas mentioned, this kind of information could be exposed using progress events. What is missing in the draft, and actually in the emails I've seen about this is the actual use case for the web. Debugging web apps can happen outside the web, like Firebug, which investigates what browser does in different times. Why would a web app itself need all this information? To optimize something, like using different server if some server is slow? But for that (extended) progress events would be good. And if the browser exposes all the information that the draft suggest, it would make sense to dispatch some event when some new information is available. There are also undefined things like paint event, which is referred to in lastPaintEvent and paintEventCount. And again, use case for paintEventCount etc. The name of the attribute is very strange: "readonly attribute DOMTiming document;" What is the reason for timing array in window object? Why do we need to know anything about previous pages? Or what is the timing attribute about? -Olli
Received on Friday, 29 January 2010 14:16:35 UTC