W3C home > Mailing lists > Public > www-style@w3.org > November 2011

Re: Unprefixing CSS properties

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 17 Nov 2011 10:44:23 +1300
Message-ID: <4EC42EB7.7040509@mit.edu>
To: Brian Manthos <brianman@microsoft.com>
CC: "www-style@w3.org" <www-style@w3.org>
On 11/17/11 10:28 AM, Brian Manthos wrote:
> 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.

I'm not really sure it does; I fully expect "Selectors Level 4" to go to 
REC sooner than some "Level 3" modules.

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

Why does that matter?

> If you went that route people would complain because they couldn't start building the features in the "Future Maybe" draft without confusing everyone.

Why?

I think we're having a fundamental difference in assumptions here 
somewhere.... :(

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

Why?  Why would it ever matter to a web developer?

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

Uh... I think you completely misread what I wrote.  Did you miss the 
whole "because ... or ..." bit?  They care whether two UAs have 
incompatible implementations, because it affects their work.  They don't 
care what the exact reasons are _why_ that happens.  It doesn't matter 
to them whether it's because one UA added an implementation of an 
extension to one of the properties because such an extension has gone to 
CR, or just unilaterally added it, or some other reason.  The net impact 
on them is the same.  The future time-evolution might be different, as 
other UAs also implement.  Or not.  And whether other UAs implement is 
not really all that dependent on whether there's a CR for it, really.

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

The discussion in this subthread was about your specific concern that 
with the current proposal web developers may have to deal with multiple 
unprefixed implementations of the same property which are incompatible 
insofar as some implement sets of values that are strict supersets of 
the sets of values implemented by others.

I pointed out that web developers have this problem anyway any time the 
CSSWG adds more values to a property and the module in which we have 
done so goes to CR.  Possibly even before that, if UAs are adding the 
new values to their existing unprefixed implementations.  The only way 
to prevent that is to synchronize the addition of new values to existing 
unprefixed properties across all UAs, which doesn't seem feasible to me.

Are we on the same page now?

-Boris
Received on Wednesday, 16 November 2011 21:44:57 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:46 GMT