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

On Sat, 28 May 2011 02:07:16 +0200, Jatinder Mann <jmann@microsoft.com>  
wrote:

> We agree on these points:
>> MUST use a "-<vendor>-" prefix to any custom attributes on
>> PerformanceTiming MUST use the same clock system
>
> I can take an action to update the spec here. Maybe the following text?
>
> Section 4.6 Vendor Prefixes
>
> Vendor-specific proprietary user agent extensions to this specification  
> are strongly discouraged. If such extensions are nonetheless needed,  
> e.g. for experimental purposes, vendors are strongly urged to use the  
> following extension mechanisms:
>
> If the extension to be added is an INITIATOR type, the INITIATOR type  
> must:
> - Follow this naming convention pattern:  
> INITIATOR_[VENDORPREFIX]_[TYPE], where VENDORPREFIX is a name that  
> identifies the vendor.
> - Have a value in the range of 100 to 200

I take my words back regarding the prefix. The new vendor prefix is  
-beta-, one prefix to rule them all. See  
http://www.quirksmode.org/blog/archives/2010/03/css_vendor_pref_1.html
Should we be avant-garde here, and be the first to implement -beta-? (I  
don't think any other specifications have picked up on this to date.)

Otherwise seems good.

> If the extension is a new timing attribute, it must:
> - Follow this naming convention: [vendorPrefix]TimeName, where  
> VENDORPREFIX is a name that identifies the vendor.
> - Use the same clock as "time" is defined in Section 3 Terminology.

Seems good. This is intended for both Navigation and Resource timing,  
right?

>> that the ResourceTimingBufferSize SHOULD be increased appropriately
>
> The buffer size is the number of resources captured by default, not the  
> size of the elements themselves.  How would the buffersize be effected  
> by vendor extensions?

Ah, right, ignore then.

>> and that looping over the attributes on PerformanceTiming MUST list  
>> custom attributes last.
>
> I'm not quite sure of the benefits of this - can you explain?

Me neither, though in a "for (a in PerformanceTiming)", developers often  
make the strangest assumptions, and keeping them in the end might be  
simpler. I have no particular thoughts on this one, my points were mostly  
intended as examples to get the discussion flowing. There are likely some  
more items we should specify, and probably some more objects too.

Do we need to allow more PerformanceNavigation types? Resource timing  
methods? UserTiming constants?
Do we need to specify any actions with regards to privacy, or with regards  
to the examples in section 4.2 of Resource Timing? With respect to which  
elements might be added and which not (e.g. compilation time might, double  
click speed might not)?

Or is a generic section at the end enough, stating some examples (like the  
two mentioned above), and that any proprietary extensions should otherwise  
attempt to follow the spec as closely as possible? If you ask me, this is  
likely enough, we are unlikely to be able to foresee all future extension  
attempts anyhow.


-- 
Sigbjørn Vik
Quality Assurance
Opera Software

Received on Monday, 30 May 2011 07:53:10 UTC