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

RE: Unprefixing CSS properties

From: Brian Manthos <brianman@microsoft.com>
Date: Wed, 16 Nov 2011 05:49:08 +0000
To: "robert@ocallahan.org" <robert@ocallahan.org>
CC: Charles Pritchard <chuck@jumis.com>, www-style <www-style@w3.org>
Message-ID: <9710FCC2E88860489239BE0308AC5D170447E43A@TK5EX14MBXC264.redmond.corp.microsoft.com>
> I think in cases where authors are already widely producing content using the unprefixed property
I don’t see it that way.  I see it this way:  authors are intentionally choosing a bad path if they are producing content based on technology that isn’t final yet.

If the technology isn’t keeping up with author demand, then perhaps authors are really asking for proprietary technology rather than standardized technology.


> I think in cases where authors are already widely producing content using the unprefixed property
> and assuming that the behavior will match the behavior of the vendor-prefixed properties
The WG has said stated multiple times that the author is wrong in making this assumption, and at least hinted that the author is somewhat foolish in building LOB on top of prefixed properties.

Such authors are completely missing the point that prefixed properties *are not ready* for production content.  That’s much of the point of prefixing.


> Even if authors aren't using the unprefixed property widely, if the behavior is clear and uncontroversial then the harm of unprefixing should be minimal.
I disagree.  If the behavior is clear and uncontroversial, then the spec should be at CR or REC.  Correspondingly, the spec being at ED / WD suggests that the behavior has not reached the “clear and uncontroversial” state.  Either that or it’s missing the “documented” requirement, which I don’t think anyone would argue is a requirement of a specification.


> I deliberately excluded gradients.
In the July F2F, the argument was made that gradients are being held up by the rest of Images, not the reverse.  Perhaps that’s flipped since; perhaps not.  The point holds though that vetting-to-CR is one of the apparently few forcing function we have in getting the official behavior formally agreed and supported.

>> expanded grammar
> Those are totally OK since the changes are backwards compatible.
Incorrect.  While authoring conventions can make it effectively backwards compatible, it’s not strictly backwards compatible.

Example:
div {
                transition-timing-function: ease-in;
                transition-timing-function: step-start;
}

Browser A unprefixes against the current WD.  Browser A applies “ease-in”.

Browser B unprefixes against the current ED.  Browser B applies “step-start”.

Interoperability failure.
Received on Wednesday, 16 November 2011 05:49:37 GMT

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