Re: Making sense of the various web performance specifications

On 06/16/2015 12:34 PM, Boris Zbarsky wrote:
> On 6/16/15 11:48 AM, Ilya Grigorik wrote:
>> They're tangled together. Practically speaking, you can't implement one
>> without the other:
>> - HR-time defines time origin and performance.now().. but that presumes
>> Performance interface exists.
>> - Perf Timeline, in turn, needs time origins and performance.now()
>
> There's no particular reason things couldn't be set up like so:
>
> HR-time: defines time origin, DOMHighResTimestamp, and a Performance
> interface with a single now() method.
>
> Perf Timeline: depends on HR-time, defines a "partial interface
> Performance" with the bits it wants to add.

Unless I'm mistaken, this is what we have in the editor's drafts today.

If we come through with cleaning up /TR and getting a primer (I asked 
for help on that front), this would help significantly.

Re /TR clean up, I believe adopting something similar to CSS would be 
helpful.

ie
- /TR/performance-timeline would be in sync with the github draft.
- /TR/performance-timeline-1 would link to the first REC.
- /TR/performance-timeline-2 would link to our expected new version 
(which is identical to the github draft for the moment anyway)
- once or if p-t-2 diverges from the github draft (because we don't 
expect some features to be implemented in a release cycle), we should 
rev to p-t-3.

All github drafts shouldn't use version links. Either link to github 
drafts or non-version TR shortnames (shouldn't make a difference if we 
keep things in sync).

I'd like to minimize the work for release cycles as much as possible, ie 
delay a move to CR until we're sure we can ship it within 6 months at 
most, so that editors don't have to edit two documents as much as 
possible. This may be contrary to vendor release cycles however since 
some may wait until CR before looking at implementing.

Philippe

Received on Tuesday, 16 June 2015 18:51:11 UTC