W3C home > Mailing lists > Public > public-web-perf@w3.org > May 2011

Re: [Resource Timing] User feedback and a modified proposal

From: Sigbjørn Vik <sigbjorn@opera.com>
Date: Thu, 26 May 2011 16:14:43 +0200
To: public-web-perf@w3.org
Message-ID: <op.vv3dutou41y844@id-c0735.oslo.osa>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 May 2011 14:15:02 GMT