Re: Unprefixing CSS properties

On 19 November 2011 20:05, Brian Manthos <brianman@microsoft.com> wrote:
> Not necessarily correct, but often correct.  It's up the UA vendors whether they handle versioning of their prefixed properties or not.
>
> One option is..
>        -vendor-shiny
>        -vendor2-shiny
>
> Another option is document modes.
> Another option is meta tags in the page.
> Another option is to change the property name rather than the prefix:
>        -vendor-shiny
>        -vendor-shiny2
>
> There are many options.  Vendors *choose* whether they want to leave a given {prefix,property} combination frozen in time in its syntax, and they choose how long they want to support it.  Take it up with the vendors individually if you have a recommendation on changing their policies or consistency within their policy.

I don't really know what this has to do with my point, which wasn't
that there aren't ways to change syntax in backwards compatible ways,
but that authors have nothing to lose, and potential compatibility to
gain, by assuming the syntax won't change and including the unprefixed
version of properties.

> If you want consistency *across* vendors about how they use their prefixes, that's a larger challenge and (to my knowledge) is outside of the scope of the CSSWG.

I don't want consistency about prefix use, I want them gone because
they are awful and don't work. If the working group was able to
achieve consensus on prefixes, I don't see why it is hopeless or
beyond the scope of the WG for them to agree on something better that
authors don't hate. See Lea Verou's article, and other posts in this
thread for what that better solution might look like.

>> If I also include an unprefixed version, and the
>> syntax changes, my site still breaks, so what difference does it make?
>
> Including a unprefixed version is by-definition incorrect until the property is "standards ready".  Currently, "standards ready" means at CR, a test suite with report cards, etc.
>
> Sometimes (never?) you get lucky and the WG is awed by the brilliance and perfection embodied in the initial proposal and it skates immediately CR, but that's highly unlikely.  As such, as an author -- don't bake something into your page that is incorrect from day 1.

Incorrect by *what* definition? The definition of how authors are
expected to behave, or the definition of how they *actually* behave,
in reality, every day on the web? This is just XHTML 2.0 all over
again, with the official line bearing no relation to what is actually
happening or what authors want.

>
> Extending the 'draft' suggestion somewhat...
>        -wd20110908-radial-gradient(45deg, red, blue)
> ...would completely reduce ambiguity of which grammar and behavior is intended and is not vendor-specific.  That option would *not* be wrong on day 1, but is pretty cumbersome to author.
>
>> (Or rather, it doesn't "break", it simply reverts to the fallback
>> behaviour that I will provide for older browsers that never supported
>> these new features.)
>
> This is another flavor of getting lucky, given that it's not a goal (and somewhat of an anti-goal) to make the grammar backwards-INcompatible between iterations of specifications.

See above; authors have nothing to lose, and the potential to gain, by
assuming they will get lucky.

>> I'm really struggling to see any logic or evidence behind the argument
>> that prefixes enable new features to be enabled
>
> I think others have addressed it but I'll try to summarize.

> Without prefixes, more than zero vendors would consider introducing *nothing* new-ish to released versions of browsers until the new things are "standards ready".
>
> So you've effectively removed that vendor from the candidate list for "2+ implementations" that helps a spec advance.  Further, the user base that those browsers reach would thus offer you no vetting of the proposed new properties.

The major innovations in CSS in the last half-decade were driven by
Apple during the period 2007 to 2009. During that period, they added
gradients, 2D and 3D transforms, and animations. The addition of these
features was entirely due to commercial need to enhance the
capabilities of Mobile Safari on the first iPhone. I don't believe
Dave Hyatt would have hesitated for a second about adding these
features even if prefixing had not been an agreed approach. Nor do I
believe that other browsers would have refused to implement and
standardise them, any more than they refused to implement and
standardise XmlHttpRequest and a myriad of other things. All that
prefixes have done is given vendors and excuse to put-off driving
these features to full standardisation.

What's more, as has been repeatedly made clear, the prefixed nature
has done *nothing* to stop authors relying on them, and therefore has
done *nothing* to make it easier to change their implementation later.
It has just made it harder to authors to create content targeting
multiple UAs, and for other UAs to enter a space, like the mobile web,
where there is a single dominant player whose advanced features are
targeted through prefixed properties.

>
>> If you want people to make enough use of new
>> features to reveal problems, then you're going to end up with a body
>> of content that relies on the original implementation, and which will
>> break when the syntax changes, regardless of whether those features
>> are using a prefix or not.
>
> I think this is where the disconnect is.
>
> One of the -- apparently too subtle -- points of using prefixes is to make it clear that the property is *in evolution* (i.e. not final) and that it is *experimental*.  Authors that bake in experimental, in evolution features into their LOB/production pages are being aggressive and promising to themselves that they will be reactive to spec changes when they arise.

I perfectly understand that this was one of the intentions of
prefixes. There is nothing subtle about it, and it has been repeated
ad nauseum in this group. But the fact is it flies totally in the face
of reality of what happens on the web today. There is nothing
"aggressive" about an author using CSS transforms, a feature that was
added to Webkit in 2007[1], and which hasn't had a new WD since
2009[2]. This reality has eroded whatever experimental or unstable
denotation was originally intended by vendor prefixes to the point
where it is utterly lost, and authors use prefixed properties as
easily as they would any other, except with the tedious requirement of
duplication. These are facts, and perpetuating a failed system in
denial of them gains nothing.

> Authors that avoid such experimental features are immune to these concerns.
>
> Put another way... authors aren't wrong for using prefixed properties.  They're wrong for expecting that they can do so in pages without having to maintain/update as the features mature.

You have given them absolutely no reason to believe otherwise. You
have implemented features in cross-compatible ways, then left the
specs to rot for years in WD with neither changes and improvements,
nor any suggestion they will ever move to CD. You have trumpeted
prefixed features as major enhancements of a core programming model in
your new operating systems, and invited developers to start developing
applications that make use of them. In Webkit's case you have made it
explicit that these "experimental" syntaxes will be supported in
perpetuity, regardless of any future changes.

And I thought I had made it clear, but I guess I'll say it again:
Authors don't care about having to maintain and update content as
standards evolve, but they want better tools to do so than vendor
prefixes. They want to be able to say, I know this is an experimental
feature, but I don't want to include such a ridiculous amount of
duplication and ceremony when I know for a fact that is implemented in
a cross-compatible way on all the browsers I am targeting.

[1] http://www.webkit.org/blog/130/css-transforms/
[2] http://www.w3.org/TR/css3-2d-transforms/
[3] http://lea.verou.me/2011/11/vendor-prefixes-have-failed-whats-next/

Received on Saturday, 19 November 2011 23:40:46 UTC