In CSS we use vendor prefixes for properties, values, @-rules that are:
This is a collection of the latest thoughts towards policy/guidance for when to use vendor prefixes in an implementation and when it is safe/right/required to drop vendor prefixes from implementations.
There has been much discussion of vendor prefixes in both www-style and CSS working group face-to-face meetings, but nothing conclusive has been written up.
Past discussions (incomplete)
Simple straw proposal guidance. Terms per RFC2119 etc.
In what follows the term “feature” refers to any of property, value, at-rule, descriptor and unit.
If you are implementing a feature which is only defined in a Working Draft (WD, including Last Call LCWD and Editor’s Draft ED), your implementation:
If you are implementing a feature which is defined in a Candidate Recommendation or later (CR, PR, REC), your implementation:
If you are implementing a feature which is defined in a mature W3C specification (CR, PR, REC), but not in CSS, your implementation:
For non-mature specifications (ED, WD) adopt the convention for WDs.
W3C WGs try hard not to introduce incompatible features, but this is not guaranteed in all cases. The CSS version must take precedence in ambiguous cases.
If you are implementing a feature which is defined in a mature non-W3C specification, but not in CSS, your implementation:
For non-mature specifications adopt the convention for WDs.
If you are implementing a feature which is intended for internal use only, your implementation:
You SHOULD, however, consider proposing the feature to the CSS WG and then, if it is accepted, follow the convention for WDs.
If you implemented a feature with a vendor-specific prefix when it was only defined in a Working Draft, and the WD transitions to Candidate Recommendation, then your implementation:
When is the best time to implement the unprefixed version of a feature?
Ideally, when the feature is known to be 100% stable in a CR or better (that nearly never happens in practice).
In practice, when a spec reaches CR.
However, there have been some specs in the past that reached their first CR “prematurely” for which it would have been bad had implementations implemented unprefixed features (e.g. CSS3 Text).
There are also cases where a spec oscillates between CR and LCWD (e.g. CSS 2.1, CSS3 Color, Selectors, CSS3 UI), so it’s not clear when during those oscillations it was “ideal” to implement unprefixed features.
When is the best time to drop support for the vendor-prefixed version of a feature?
Ideally, when you implement the unprefixed version.
In practice, some implementations have found it necessary/useful to maintain both vendor-prefixed and unprefixed versions of a feature for some amount of time. Different vendors appear to have different policies on this. For example, WebKit has unmodifiable content which uses prefixed properties in the field, such as iTunes Extras, so is unable to deprecate those properties. (Other examples/documentation/reasoning would be appreciated).
Is it okay to implement unprefixed features when a CR is taken back to Last Call for non-trivial changes?
In theory, no, any features implemented from a WD should have a vendor-specific prefix.
In practice however, LCWD2s are typically far more stable and correct than their preceding CRs (e.g. CSS 2.1, Selectors, CSS3 Color), thus it stands to reason that if it was ok to implement new features as unprefixed in that CR, then it should be more ok in a LCWD2.
The CSS3-UI editor’s draft defines two new (since the previous CSS3-UI CR) cursor values,
Mozilla has supported these two values, with a vendor-specific prefix, for a number of years.
Opera has recently implemented (in Opera 11.10) vendor-specific versions as well.
The definition and function of this feature feel fairly stable, very unlikely to functionally change between the editor’s draft and the next CR of CSS3-UI.
It is desirable to consider allowing unprefixed implementations before people come to rely upon the vendor-prefixed version of the feature.
Thus we should consider allowing implementations to implement unprefixed versions of
If so, this is an interesting test case for iterating/changing the abovementioned guidance.
What is the higher level condition here that merits considering allowing implementations to ship an unprefixed version of a feature?
Perhaps some combination of:
This is a list of known prefixes from vendors and third parties. Implementers MUST NOT use them unless licensed by a condition above.
Vendors or organizations who want to introduce a prefix of their own should publicize it by registering the case-insensitive string with the CSS WG, i.e. sending an informal mail to www-style. The string should be two to six characters long and should be easily associated with (only) the registering party or its product.
The prefixes are shown with leading and trailing hyphen, although in some cases the initial one is left out.
|-atsc-||Advanced Television Standards Committee|
|-epub-||ePUB (Electronic Publication format)|
|-ms-||Microsoft Internet Explorer|
|-prince-||Yes Logic Prince|
|-rim-||Research In Motion|
|-wap-||The WAP Forum|
|-webkit-||Apple Safari, Google Chrome etc. (WebKit)|
|-xv-||Opera (CSS Speech module)|
The following prefixes are reserved for semantics to be defined by the CSS WG. This
may or may not happen. They must not be used with different meaning.
All combinations of any of the following prefixed followed by any combination of digits 0–9, the hyphen character ‘-’ and the letter ‘x’ is also reserved, e.g.
|-w3-||W3C – World Wide Web Consortium|
|-css-||CSS – Cascading Stylesheets|
|-csswg-||CSS Working Group|
|-svg-||SVG – Scalable Vector Graphics|
|-svgwg-||SVG Working Group|
|-xsl-||XSL – Extensible Stylesheet Language (Family)|
|-xslfo-||XSL Formatting Objects|
|-xppl-||XPPL – XML Print and Page Layout Working Group|
|-expires-||“expires”, “expiration date”|
|-exp-||“experimental” or “expires”|
|-test-||“test”, “in testing”|
|-pd-||“proposed draft”, “proposal”, “public draft”, “private draft”|
|-lc-||Last Call Working Draft|
|-vendor-||Example vendor prefix|
|-ua-||Example user agent prefix|
|-org-||Example third party prefix|
|-spec-||Example third party specification prefix|