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

Re: RFC: WebApp Timing (Rnd 2)

From: Zhiheng Wang <zhihengw@google.com>
Date: Tue, 29 Sep 2009 11:07:44 -0700
Message-ID: <802863260909291107o4b354252n349e08154d080fc0@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: public-webapps@w3.org
Hi, Anne,
    Thanks for the comments and I will address them in the next revision.
Pls see details inline.

On Mon, Sep 28, 2009 at 6:28 AM, Anne van Kesteren <annevk@opera.com> wrote:

> On Sat, 26 Sep 2009 23:17:06 +0200, Zhiheng Wang <zhihengw@google.com>
> wrote:
>
>> 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?
>

    In the past we've found the type of navigation have much effect on the
loading latency of a page, e.g., forward/backward has more to do with
the browser itself than the apps provider's setup. So it is useful to be
able to distinguish these different cases.



>
>
> 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?
>

    Yes, one of my tasks right now is to make proper link-ups with other
html5 docs.


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

    Yes, hopefully the next revision will be on dev.w3.org instead.

thanks,
Zhiheng


>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>
Received on Tuesday, 29 September 2009 18:08:23 GMT

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