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

Re: [WebTiming] HTMLElement timing

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Fri, 29 Jan 2010 16:15:51 +0200
Message-ID: <4B62ED97.3050808@helsinki.fi>
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
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?

Received on Friday, 29 January 2010 14:16:35 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:22 UTC