- 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>
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. Philippe
Received on Wednesday, 27 April 2016 23:05:38 UTC