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

Thanks Sigbjørn Vik for bringing up this issue. I have added some initial text in Section 4.6 Vendor Prefixes of the Resource Timing spec, http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/ResourceTiming/Overview.html#vendor-prefixes; please review this change. I have also opened ACTION-35 Add a Vendor Prefix section to Navigation Timing on Zhiheng  and ACTION-36 Add a Vendor Prefix section to User Timing on me. 

> 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.)

What would the expected behavior be if two user agents use the same initiator type name but they mean something slightly different? It would seem that having a vendor prefix, instead of a beta prefix, might be helpful in distinguishing the two.

>> 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?

Yes, this will also be applied to Navigation Timing. 

>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)?

As we need more methods, we can always add new ones, as long as we give them unique names or signatures. User Timing constants will also have a prefixes rule - I have opened Action Item 36 on me to make this change. 

>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?

The goal is that everyone will follow the spec closely and will use vendor prefixes for experimental constants or timing data. 

Jatinder

Received on Wednesday, 1 June 2011 17:41:28 UTC