W3C home > Mailing lists > Public > public-web-perf@w3.org > April 2016

Re: Resource Timing Level 1 and beyond

From: Philippe Le Hegaret <plh@w3.org>
Date: Wed, 27 Apr 2016 19:05:35 -0400
To: Ilya Grigorik <igrigorik@google.com>
Cc: public-web-perf <public-web-perf@w3.org>
Message-ID: <572145BF.4020306@w3.org>

On 04/27/2016 06:42 PM, Ilya Grigorik wrote:
> On Tue, Apr 26, 2016 at 7:52 AM, Philippe Le Hegaret <plh@w3.org
> <mailto:plh@w3.org>> wrote:
>     Following last week discussion, I added "Level 1" to Resource Timing
>     with the following:
>     [[
>     This specification is ready for wide review, with the following
>     features at risk for the first release:
>     *    Dependency with Performance Timeline 2, since performance
>     observers are lacking implementations;
>     *    Dependency with High Resolution Time 2 and workers support,
>     including workerStart, since we're still refining time origin;
>     *    nextHopProtocol, transferSize, encodedBodySize, and
>     decodedBodySize, since we're currently lacking implementations.
>     ]]
> We also had secureConnectionStart marked as optional for a long time and
> recently changed it to mandatory. My proposal would be to also treat
> that change as an L2 feature. With these carveouts in place, I think we
> should have three existing implementations (Edge, FF, Chrome) of
> proposed L1. And once we land
> https://github.com/w3c/resource-timing/issues/46, we can (hopefully :))
> confirm that.
>     Imho, the issue that affects the most implementations at the moment is
>     https://github.com/w3c/resource-timing/issues/12
>     I'm proposing that we don't solve it for V1 but keep flagging it as
>     an issue in the spec for Web developers to be aware of.
> I agree. The spec did not indicate either way until we landed [1] and I
> think we can: (a) keep it as such for L1, (b) resolve it in L2. With
> that in mind, we would probably need to back out that commit for L1?

Yes, in the v1 branch. gh-pages should not be affected by L1 imho.

Received on Wednesday, 27 April 2016 23:05:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 27 April 2016 23:05:38 UTC