RE: Unprefixing CSS properties

> Or they are asking to use standard technology when it is already good
> even if it isn't perfect from the WG's point of view. Coping methods
> like the one presented in
> http://blogs.msdn.com/b/ie/archive/2011/10/28/a-best-practice-for-

> programming-with-vendor-prefixes.aspx
> assume that the implementations of the standard technologies are
> already good *enough* except for the barrier imposed by the prefix so
> that the same stuff can be given to different browsers with mere
> prefix substitutions.

For the record, I already discussed briefly with John in private that this techniques don't work for cases like Gradients where the grammar changed.  Which further proves my point.

> Given the how often "final" features end up being close enough to
> prefixed features, it's not foolish for a Web author to take the bet
> that properties that are prefixed today end up being similar enough
> once unprefixed so that using the unprefixed version in anticipation
> of future browsers won't break the site significantly.

IMO, that's an argument for saying there is a more advanced stage than WD that includes "grammar is stable, only edge cases of behavior remain".  Is that stage CR?  If yes, then the current system supports your suggestion.  If that stage is not CR, perhaps something in between WD and CR should be considered -- and should be considered "unprefixable".

> Instead, it
> would be foolish for the CSS WG to change a characteristic of e.g. 2D
> Transforms that the top 4 engines implement the same way (except for
> the prefix) even though the W3C Process, in principle, would allow the
> CSS WG to make such changes. And when the implementations differ, it
> would be foolish for the CSS WG to pick a totally novel behavior
> instead of upholding one of the existing behaviors. (In the general
> case; security concerns or maybe some truly exceptional badness could
> override what I just said.)

I agree.  And I would argue this is where the execution of the CSS process is having problems, not the design.

Drafts, IMO, spend a long time in ED/WD 're-envisioning' what vendors proposed and restructuring it dramatically from what was proposed.  When the editors get "off track" by moving the draft away from "implementer consensus" without implementer support/agreement, that triggers the problem you're mentioning.

Again, I don't think the right solution is to just chuck the system.  The solution is to push back on those controversial edits to the point of reversing them... and then build the argument (test suite!) to support moving forward with the grammars and behaviors that have implementer consensus.


> > I disagree.  If the behavior is clear and uncontroversial, then the spec
> > should be at CR or REC.
> 
> In theory, yes. In practice, the behavior converges enough to be
> useful and safe *enough* for deployment well before the behavior has
> converged so perfectly that the behavior is "clear" for the purpose of
> the CSS WG's way of applying the W3C Process.

Again, this is an argument for one of the following:
a. move to CR faster and keep existing process
b. change WD editing behavior such that unprefixing can be done at WD
c. something between WD and CR is "good enough for prefixing"; let's give that a name and consider changing the unprefixing policy


I don't have high hopes in 'b', and 'c' is likely to take a long time to build consensus around.

I think 'a' is the least pain path and improves the throughput of CSS across the board -- driving specs to CR faster overall rather than having them languish in pre-CR form for years.

Received on Wednesday, 16 November 2011 17:06:43 UTC