Transition Level 2 to CR about performance-timeline HOT 18 CLOSED

• changes from L1: e67afe5
• ack's section: 8efc380
• privacy/security section: 08ad1cd

@toddreifsteck @plehegar ptal at the above.

from performance-timeline.

👍

from performance-timeline.

should we request wide review for this spec to make sure we're covered?

from performance-timeline.

I didn't bring it up on the call today because I'd like to resolve w3c/resource-timing#55 (comment) before we push for CR... However, I guess request for wide review doesn't need to block on that?

from performance-timeline.

I don't think we need to block: we could a pointer to the issue from the status to bring attention if needed. If you're ok, I'll just do the status and trigger the wide review.

from performance-timeline.

Sounds good to me.

from performance-timeline.

Done. https://lists.w3.org/Archives/Public/public-review-announce/2016Oct/0015.html

from performance-timeline.

This list is looking good to me so far!

from performance-timeline.

Re, w3c/resource-timing#55 (comment): I believe that issue is a no-op for perf-timeline and hence this is ready to go to CR.

from performance-timeline.

@igrigorik any chance you can look at the privacy/security section to see if it's up-to-date?

from performance-timeline.

@plehegar I believe it is. As it stands, perf-timeline provides plumbing for receiving and retrieving metrics from it; on it's own it's a no-op in terms of privacy or security implications.. it only becomes relevant based on what data is pushed into it by other specs and mechanisms.

from performance-timeline.

Doesn't Performance Timeline have some lifetime guarantees built into it to ensure it is flushed across navigates and also each subdocument has its own performance timeline. These are HTML5 requirements for any member of window but.. perhaps it is worth calling those out?

from performance-timeline.

Doesn't Performance Timeline have some lifetime guarantees built into it to ensure it is flushed across navigates and also each subdocument has its own performance timeline.

Yes, implicitly via...

Each ECMAScript global environment has:

• a performance entry buffer to store PerformanceEntry objects.
  ...

I guess if we want to be super explicit about it we could say...

This specification extends the Performance interface defined by [HR-TIME-2] and provides methods to queue and retrieve entries from the performance timeline of the associated ECMAScript global environment. Please refer to [HR-TIME-2] for privacy and security considerations of exposing high-resoluting timing information.

To be honest, I don't think we want to get into discussion on how/where these globals are cleared, unloaded, etc, that should fall out from the HTML spec.

WDYT?

from performance-timeline.

I don't disagree, but wanted us to be explicit that we were choosing not to document that. It is the only privacy item I could think of so I figured it was best to be clear that we believe it is already covered by HTML5 and should not be repeated.

from performance-timeline.

Approved to publish L2 CR on today's call.

@plehegar @siusin can you help us with the transition request and close this once that's on the way?

from performance-timeline.

@igrigorik I'll take care of this one today.

from performance-timeline.

Done: https://www.w3.org/TR/2016/CR-performance-timeline-2-20161208/
Sorry that it took so long :(
Next step will be PR in January

from performance-timeline.

Thanks Philippe. Updated our dashboard, closing this..

from performance-timeline.