RE: Unprefixing CSS properties

> "CSS3 browser" and "CSS4 browser" are meaningless terms.
No, they are not.  If that were the case, there is no point in having “Level 4” vs. “Level 3” modules.


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

The key concern is un-prefixed.  If you want different implementations of a property, that’s what prefixes are all about.


> I don't think we've previously had a proposal to immediately unprefix a specific set of properties.

We've had numerous mail threads from "the sky is falling, Jimbo demands shiny toy 7 must be unprefixed" to measured debates about the existence of prefixes, the intended goals, and whether they are achieving them.

To me they've all blurred into the same overall concern of not tackling the problem head on and solving it.

My interpretation of the latest flavor (in this thread) is "can we just violate the rules because we think these properties are really super cool and stuff?"


If the system isn't working, focus on fixing the system rather than trying to get what you consider a special case exception.


Going back to the original post:
> We had a meeting about this with some Mozilla developers today
> and came up with a proposed list of properties/features which
> we think are eligible for unprefixing

Great.

Options:
(A) Work to get the modules containing them to CR
(B) Propose a change to the W3C as a whole, or CSSWG as a part, that defines when it is ok to un-prefix outside of CR holistically, not just for the ones you've cherry-picked
(C) Lobby to get your cherry-picked properties to be treated as *special*

I'm arguing against (C).  (A) and (B) are fine; go nuts.

Received on Wednesday, 16 November 2011 20:28:01 UTC