W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: RFC: WebApp Timing (Rnd 2)

From: Anne van Kesteren <annevk@opera.com>
Date: Mon, 28 Sep 2009 15:28:17 +0200
To: "Zhiheng Wang" <zhihengw@google.com>, public-webapps@w3.org
Message-ID: <op.u0yydfya64w2qv@annevk-t60>
On Sat, 26 Sep 2009 23:17:06 +0200, Zhiheng Wang <zhihengw@google.com>  
> Updated to incorporate the feedbacks. (Sorry for the long pause. I've  
> been in absence for the past couple weeks.)
>   1) the window.pageTiming attribute should be available for each  
> browsing context, not only the top-level one.

You need to use [Supplemental] before "interface Window" as you are not  
defining the Window interface in this draft, just an extension.

The draft does not explain why the different navigation methods need to be  
distinguished. Assuming this feature can be justified I think it needs to  
be defined in more detail. E.g. what needs to be returned if a page is  
loaded inside a <frame>, <embed>, or <object> element? Is it useful that  
you do not get information about the entire redirect chain rather than  
just the one before you go to the current page?

Is is important to share with the Web author whether the user opened the  
page in the current tab or a new one?

I also think it should be made more clear how exactly the specification  
works together with the navigate algorithm. It currently says "navigation  
event" where "navigation" is a pointer to the navigate algorithm in HTML5  
which does not define an event so it is unclear from where the timing  
should start.

Why does this draft not contain the legacy timer APIs currently in HTML5?

(Maybe you should ask a Team contact for an account on dev.w3.org so it is  
easier for us to monitor changes. Would also be nice to have a single  
pointer for the draft.)

Anne van Kesteren
Received on Monday, 28 September 2009 13:33:49 UTC

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