RE: Unprefixing CSS properties

Jon Rimmer:
> On 19 November 2011 01:30, Brian Manthos <brianman@microsoft.com>
> wrote:
> >> Authors are taught to set the same values they're using for prefixed properties for the
> >> unprefixed version as well, to "future proof" their production sites. Such usage
> >> constrains browser implementers, and by extension the WG, to make sure the spec
> >> evolves in a way that doesn't break those sites.
> >
> > This is incorrect guidance and should be corrected.
> 
> What? If I only include the prefixed property, and the syntax changes,
> my site breaks.

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.

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.

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


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.

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

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

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 should all just agree to drop vendor prefixes, or make them an
> optional way to target implementations on a per-UA, and move on.

We're not going to agree on this one, and I'm not going to try to convince you in this thread.

> Concentrate on reducing the body of content that is broken by spec
> changes by minimising the period of instability, by avoiding
> bike-shedding and working quickly to stabilise syntaxes. Don't keep
> trying to solve unsolvable problems or save authors from ourselves.

Essentially agree on this one.

Received on Saturday, 19 November 2011 20:06:27 UTC