W3C home > Mailing lists > Public > public-css-testsuite@w3.org > February 2012

Re: [css3-transitions] [css3-animations] API for testing transitions and animations

From: Linss, Peter <peter.linss@hp.com>
Date: Wed, 29 Feb 2012 17:18:03 +0000
To: yvind Stenhaug <oyvinds@opera.com>
CC: "public-css-testsuite@w3.org" <public-css-testsuite@w3.org>
Message-ID: <5FFC4808-E458-4D4E-A2A6-9B94BC0665B4@hp.com>

On Feb 29, 2012, at 7:33 AM, yvind Stenhaug wrote:

> On Tue, 28 Feb 2012 20:10:19 +0100, Linss, Peter <peter.linss@hp.com>  
> wrote:
> 
>> On Feb 28, 2012, at 8:42 AM, yvind Stenhaug wrote:
> 
>>> I'd hate
>>> to see prefixes gain any more legitimacy due to someone noticing that  
>>> even
>>> W3C's standards testsuites use them...
>> 
>> 
>> Which is why we don't want them in the source.
> 
> If there is any kind of prefixing happening then surely it will be visible  
> in the source of the built tests, which is what matters.

I meant the source that the test suite gets built from, not the "view source" of the test page. Yes, of course if it's in a test page it will be visible there for anyone looking deeply. 

My point was that giving the build system the ability to inject prefixed versions of properties gives us the ability to generate test suites to measure interop before CR. This is something we'll do on an as-needed basis. Any test suites we build with that will be clearly marked as such, and will only be published temporarily. No, it's not ideal, but it's better than having prefixed properties in the source that the test suite gets built from.

> 
>> Do you have another suggestion how to test interop before prefixes get  
>> dropped?
> 
> Well, I didn't really mean to cause yet another prefix thread to emerge,  
> but why should the current state of interop matter that much to the WG  
> *before* the Call for Implementations?

Because there will be times when we decide to drop prefixes before CR. In order to do this, we need to be able to assess the degree of interop existing with the prefixed implementations.
Received on Wednesday, 29 February 2012 17:19:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 29 February 2012 17:19:55 GMT