Re: Unprefixing CSS properties

Yehuda Katz
(ph) 718.877.1325


On Tue, Nov 15, 2011 at 9:49 PM, Brian Manthos <brianman@microsoft.com>wrote:

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

Authors are asking for technology that is on track for standardization and
is widely supported in multiple major browsers. Authors are intentionally
choosing the path that allows them to create web sites and applications
that are performant and capable on mobile devices, using the tools that are
widely available on many of those platforms; saying they are choosing a bad
path without providing an alternative (other than "build a native app" or
"accept bad performance") is not really fair.


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

Except that they are ready for production content, and were released in
virtually identical form on several-generations-old mobile platforms. These
are the APIs we, as authors, are provided by platform and browser vendors.
If the iOS or Android APIs are "ready for production content", saying that
widely deployed web APIs are not ready is making the web less competitive
on these platforms.

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