W3C home > Mailing lists > Public > www-style@w3.org > July 2010

Re: A List Apart: Articles: Prefix or Posthack

From: Christoph Päper <christoph.paeper@crissov.de>
Date: Thu, 8 Jul 2010 20:35:49 +0200
Message-Id: <B432FB34-01E5-4E41-9B2D-22F3FD80B1AE@crissov.de>
To: www-style list <www-style@w3.org>
Vendor prefixes were introduced first, if I remember correctly, for custom properties that were in no W3C draft and probably never will be, e.g. ‘-moz-’  (or ‘moz-’ back then) in chrome stylesheets. Only later they were expanded to cover experimentally implementated features from W3C drafts. These are the ones that all the fuzz is about.

Tab Atkins Jr.:
> Eric's justification for vendor prefixes matches my own thoughts
> exactly.  I like the vendor prefixes for exactly the reasons he gives,
> and similarly think that a unified prefix is a horrible idea.

It makes perfect sense to introduce a W3C prefix when you approach the discussion from one side, but it makes no sense whatsoever if you look at it from the other (i.e. yours and Eric Meyer’s) side. 

If you want to distinguish vendor specific extensions from draft implementations you need ‘-w3c-’, ‘-draft-’ or something similar (in addition to vendor prefixes).

If you want to distinguish stable and comformant implementations of draft features from experimental and possibly non-conformant ones you only need one prefix, ‘-experiment-’, ‘-intern-’ or the like. 

That every vendor has its own prefix for this second case is just a convenience to avoid name clashes. It is also an inconvenience since it muddies the waters of distinction between proprietary and temporary stuff.

Who wants and who needs to do either distinction?

Although he actually addresses and rejects it, Eric Meyer seems to assume that stylesheets are revised on a regular basis. CSS authors must never make this assumption. Every stylesheet must be assumed to be orphaned, staying forever as-is after the current edit going public. So you cannot use properties that may change at any time, i.e. prefixed ones. If you’re skilled enough you may use features that are fully specified but not implemented yet.

=> Authors must never use vendor prefixed properties on the Web.
=> Authors should never use draft prefixed properties on the Web.
=> Authors should be safe to use anything unprefixed that gets into CR, even if some of it gets removed later on.

Authors, as we know, will of course never stop trying out any latest and greatest feature some browser or standard provides. They will blame everyone but themselves if something breaks someday.

=> UAs should ignore all rules with vendor prefixes, their own or someone else’s, except when loaded from disk or localhost. 
~~ At least for non-draft, proprietary features.
Received on Thursday, 8 July 2010 18:36:24 GMT

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