RE: Unprefixing CSS properties

Boris:
> There is no real point in having "Level 4" vs "Level 3" modules.
>
> The only reason we have them, as far as I can tell, is that some "Level 
> 3" modules are in REC or CR but we want to add more features to them, so 
> we're creating forks of the module, calling them "Level 4", and adding 
> the features there.  Then for marketing reasons we're marking other 
> modules developed at the same time "Level 4" as well.

I don't care whether you call them "Level 3 and Level 4" vs. "Level 27 and Level 28".  The point is that some features are expected to (or have already) mature(d) faster than others.  The 4 (or 28) module is the storage ground for "stuff being considered but not on the same timeline".  It has that purpose, as I understand it.

An alternative would be to rename the "Level 4" to "Future Maybe" and not give it a number at all until the "Level 3" module has reached REC and been there for a "sufficient period".  If you went that route people would complain because they couldn't start building the features in the "Future Maybe" draft without confusing everyone.

>>> You seem to be saying that adding features to CSS hurts interoperability
>>> because not all user-agents will implement the new features simultaneously.
>>
>> No, I’m not saying that.  I’m saying that having multiple incompatible un-prefixed implementations of Level N of CSS for a given property is bad, in multiple ways.
>Why is the "Level N" part important?  It's certainly not important to 
>web developers; they don't care whether two UAs have incompatible 
>un-prefixed implementations of property X because one implements "Level 
>N" while the other implements "Level N+1" or for some other reason.  So 
>who is it important to?

To responsible web developers, it's important.

If "they don't care whether two UAs have incompatible un-prefixed implementations" then it sounds like they don’t care about standards at all.  As such, why not just use the prefixed properties and pretend the un-prefixed ones don't even exist?


>> The key concern is un-prefixed.  If you want different implementations of a property, that’s what prefixes are all about.
> Unless you require that any new module revision be supported by all UAs 
> before becoming unprefixed, that's just not true today....

You lost me on this one.  So I have no useful response.

Received on Wednesday, 16 November 2011 21:29:30 UTC