- From: Sigbjørn Vik <sigbjorn@opera.com>
- Date: Thu, 26 May 2011 16:14:43 +0200
- To: public-web-perf@w3.org
On Wed, 01 Dec 2010 13:57:13 +0100, Sigbjørn Vik <sigbjorn@opera.com> wrote: > We should also explicitly lay out in the spec how future extensions > should be included, e.g. time to compile script into machine code, Flash > setupTime. Using vendor prefixes, in which locations on which objects, > which objects should not be allowed to be touched, etc. I am bringing this back to the table, I cannot see that we've reached a conclusion on this one. This holds equally for Navigation Timing as for Resource Timing. There are many more use cases than the above, including some timings that are highly implementation specific, and not fit for standardization. If a user agent wanted to implement this, how should one go about it? The answer is probably that it MUST use a "-<vendor>-" prefix to any custom attributes on PerformanceTiming, that it MUST use the same clock system, that the ResourceTimingBufferSize SHOULD be increased appropriately, and that looping over the attributes on PerformanceTiming MUST list custom attributes last. And that if future extensions cannot promise all of the above, they MUST NOT be added to the performance interfaces. E.g. CSS specs have such definitions: http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords Do we want to include this into the specifications? It would of course also be possible to explicitly declare that no future extensions be allowed, but that would limit the future flexibility and usefulness of the specs. -- Sigbjørn Vik Quality Assurance Opera Software
Received on Thursday, 26 May 2011 14:15:01 UTC