Re: A List Apart: Articles: Prefix or Posthack

Boris Zbarsky:
> 
> At the point when the unprefixed version starts being supported, (…):
> 
> 1)  Drop support for the prefixed version.
> 2)  Make the prefixed version an alias for the unprefixed one.
> 3)  Keep the prefixed version meaning whatever it meant (…)
> 
> #3 has some serious implementation complexity costs.  #2 is, imo, pretty much equivalent to #1 except in the cases that we (…) want to discourage anyway.  Specifically, authoring of browser-specific pages.

I completely agree, although I’d perhaps give authors one to few minor releases (i.e. ‘y’ in ‘x.y.z’ and ‘x.y’ version numbering) before finally removing prefixed items.

Option 3) also must never occur, because browser vendors are expected to constantly update their _temporary_ prefixed property (or value or unit or selector) until it finally matches the CR+ specification (and other implementations). Only in the release after the prefixed item has achieved that level of maturity the UA may first support the unprefixed variant. They may keep the prefixed property (e.g. until PR), too, but by then it has by definition become an alias of the unprefixed item.

Thus 3) is essentially 2) and 2) is essentially 1), but see next paragraphs.

> Note that taking approach #3 (which entails never changing the meaning of your prefixed version of the property) also means that if you implement a property with a prefix and then the spec changes you won't change your prefixed property to match the spec until the spec reaches CR.  There have been several instances of this recently, in fact, with UA developers giving exactly the "we can't change the meaning of our prefixed properties" rationale for why they're not making it possible to experiment with the changed spec.

This looks like a case of _vendor specific_ properties, which are okayish by themselves for internal use, but should not be confused with _official_ properties from W3C, draft or final. 

Since CSS standardised the feature differently, the implementations should have kept two different sets of prefixed properties, one with proprietary legacy meaning (‘-vendor-’) and one with CSS meaning (‘-w3c-’?). The latter should be removed upon hitting CR and interoperability, the former may be kept (longer). Whenever possible such situations should be avoided by timely specification of desirable features.

The following is a quick, but lenghty, write-up of what I think should happen in practice (in theory I would like to have it stricter). I hope there’re not too many logic failures – the weather’s quite hot today.

== Author Guide (alpha) ==

Can I use features from
 [!W3] non-W3C drafts, proprietary extensions
 [ED]  Editor Drafts
 [WD]  Working Drafts
 [LC]  Last Call
 [CR]  Candidate Recommendations
 [PR]  Proposed Recommendations
 [REC] Recommendations
in my 
 [+] public
 [-] private
stylesheets?

[!W3+]
You MUST NOT.
[ED+]
You MUST NOT, except when they are taken from and are identical to more advanced drafts (see appropriate entry below).
[ED-]
You SHOULD NOT, except to experiment.
[WD+], [LC+]
You SHOULD NOT.
  UA vendors may ship experimental implementations of draft features with a vendor-specific prefix attached. They are likely to contain bugs, may depart from the W3C proposal, may differ from other implementations and may change from release to release unannounced. You MAY try them out, but you MUST NOT use the unprefixed version from the specification since it may change significantly at any time. Only do this in stylesheets that are guaranteed to be kept up to date. 
  There is no cross-vendor ‘-draft-’ prefix that could be used as the baseline after vendor specific rules.*
[!W3-]
You MAY use proprietary prefixed properties to configure UA rendering or chrome if that is the standard way to do it, this also covers areas that the WG considers out of scope for CSS. 
  Be aware that there may be a CSS way to do things (some day), which probably will differ.
[WD-], [LC-]
You MAY and you are encouraged to, if you intend to report back your findings of problems with spefications or implementations.
[CR+], [CR-]
You CAN. The features of this specification are guaranteed to be stable enough to be used, but some may be removed (and possibly reintroduced later) or see minor syntax or rendering clarifications. 
  Implementations may not be robust and compatible enough to have dropped their prefixes when a specification reaches candidate state. If you need to you MAY use rules incorporating temporary vendor prefixes, but since these will stop being supported at some point, you MUST add the equivalent unprefixed spec-conformant rule at the end.
[PR-]
You SHOULD.
[PR+]
You SHOULD. You SHOULD NOT use rules with prefixes in them any longer.
[REC-]
You MUST. :)
[REC+]
You MUST. :) You MUST NOT use rules with prefixes in them.

* I’m not convinced there shouldn’t be ‘-draft-’ or ‘-w3c-’ for WD features, because, on the one hand, of the differences between vendor-specific properties and experimental implemenations that I’ve mentioned before and, on the other, to give smaller and niche vendors a chance to show off their features since no author would add their prefixes and they surely shouldn’t mimic major browsers.

== Implementor Guide (alpha) ==

Can I introduce features from
 [!W3] non-W3C drafts, my or others proprietary extensions
 [ED]  Editor Drafts
 [WD]  Working Drafts
 [LC]  Last Call
 [CR]  Candidate Recommendations
 [PR]  Proposed Recommendations
 [REC] Recommendations
in my public releases and how?

[!W3]
You SHOULD NOT. 
  If you do, you MUST prefix them, enclosed in hyphens, with a short string reminiscent of your company or product which MUST NOT be the same as the one you are using for experimental implementations of draft properties. 
  You SHOULD NOT copy or support prefixes from other vendors.
  If the scope of your proprietary extensions becomes part of a W3C draft you MAY reuse your code if applicable, but you MUST add or change to the appropriate name (perhaps with prefix). You MAY retain incompatible implementations using your prefix, otherwise it becomes an alias and should be dropped at an appropriate time.
[ED]
You SHOULD NOT.
  You MAY try them internally.
[WD], [LC]
You SHOULD.
  You MUST prefix them, enclosed in hyphens, with a short string reminiscent of your company or product which MUST NOT be the same as the one you are using for proprietary extensions. You MUST update your implementation according to specification changes and bug reports without altering the prefix.
  You MAY use the general prefix defined by the CSS WG or the Module editor (e.g. ‘-w3c-’ or ‘-css4-text-’) if you consider your implementation compatible with the latest draft definition.*
[CR]
You SHOULD.
  You SHOULD prefix them as with WDs until it has been established that your implementation is conformant to the specification. It also SHOULD be compatible with others.
  If your implementation complies, you SHOULD drop support for your vendor prefix immediately, you MAY wait until your next major release and you MAY keep supporting any W3C prefix until PR.*
[PR]
You SHOULD. 
  You SHOULD NOT release non-conformant implementations of finalised properties to the public, therefore you don’t need prefixes.
[REC]
You MUST. :)

Received on Saturday, 10 July 2010 12:32:57 UTC