RE: Making sense of the various web performance specifications

That is an interesting question.

I tend to think of HR-TIME as a primitive that Performance Timeline and possibly other features build on so my first preference is to simply move it above performance-timeline on the dependency graph.

Is there a downside to keeping them separate beyond having 2 specs for each new timing to depend on on?

From: Ilya Grigorik [mailto:igrigorik@google.com]
Sent: Tuesday, June 16, 2015 8:27 AM
To: Boris Zbarsky
Cc: Philippe Le Hegaret; public-web-perf@w3.org
Subject: Re: Making sense of the various web performance specifications



On Mon, Jun 15, 2015 at 8:52 PM, Boris Zbarsky <bzbarsky@mit.edu<mailto:bzbarsky@mit.edu>> wrote:
On 6/15/15 2:16 PM, Ilya Grigorik wrote:
Not claiming this is complete, but here's how it at lines up in my head:
https://docs.google.com/document/d/1ZKW9N0cteHgK91SyYQONFuy2ZW6J4Oak398niTo232E


Thanks, that's helpful.

User Timing depends on the time origin, right?  In fact, everything in the performance timeline does (because of the startTime attribute on PerformanceEntry).  So it seems like at the very least the time origin definition, and the definition of DOMHighResTimestamp, need to live in Performance Timeline.  Or that hr-time needs to be the base thing here, with timeline depending on it, but then it needs to define the Performance interface.

Right, had the same thought while I was making that diagram yesterday.. I'm wondering if we should just merge HR-TIME into timeline spec.