RE: Unprefixing CSS properties

1. Again, you're talking about cross-module.  This is why I mentioned 27 and 28.  My point is that *for an individual module* Level 3 vs. Level 4 has meaning.  Across modules, I'm somewhat agreeing with you that it has become watered down by a variety of factors.
2. It was a way to address the "multiple levels of modules evolving at once" concern I thought you were concerned with.
3. Because people like to say "my v2011.11.16 browser supports selectors9 (which is at ED stage)" but they wouldn't find "my v2011.11.16 browser supports selectorsTotallyNotInteroperable" as fun to put in their advertising.  Perhaps.
4. IMO, a responsible web developer should generally be using technology that is fully baked -- and intended to be interoperable -- rather than experimental.   At least for LOB sites.  For hobbyist and exploratory stuff (csszengarden.com), different rules apply.  As such, having different levels for the "ready" and "not ready" portions of technology is important.
5. I think you're making an argument for the ability for web authors to tag their markup such they can say, for example, "my page is written for selectors 3 and will break for selectors 4".  Perhaps.  IE addresses such things, in part, with document modes.  A standardized way of addressing it would indeed be lovely.
6. "CSSWG adds more values to a property" "The only way to prevent".... It's not the only way.  Another way is to have the WG stop doing that.  If they want to extend capabilities, then use a new property name.  Seems pretty simple, and compatible, to me.
7. Closer, I hope. Same, I suspect not.

-----Original Message-----
From: Boris Zbarsky [mailto:bzbarsky@MIT.EDU] 
Sent: Wednesday, November 16, 2011 1:44 PM
To: Brian Manthos
Cc: www-style@w3.org
Subject: Re: Unprefixing CSS properties

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.

(1) 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".

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

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

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

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

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

(7) Are we on the same page now?

-Boris

Received on Wednesday, 16 November 2011 22:06:58 UTC