CSS Vendor Prefixes

In CSS we use vendor prefixes for properties, values, @-rules that are:

• vendor specific extensions (per CSS 2.1), or
• experimental implementations (per CSS Snapshot 2010) (e.g. in Working Drafts)

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)

• 2012 May:
  • Policy change (after Opera’s start of defection)
  • replacement by ''!tag''
• 2012 February: okay to implement competitor’s prefix?
  • common ''-css-'' prefix
  • proprietary vs. experimental implementations
  • diverge from standard process to avoid more harm
  • opt-out vs. opt-in after Remy Sharp
  • Tantek Çelik
  • Daniel Glazman
  • unlock with @-switches after Felipe
  • F2F minutes
• 2012 January: prefix features from other W3C WGs?
• 2011 December: versioned common prefixes
• 2011 November:
  • Cocascade
  • Pragmatic unprefixing
  • Henri Sivonen
• …

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:

• SHOULD (per CSS-snapshot-2010) use a vendor-specific prefix for the implementation of the feature
  • suggest this be changed to a MUST. - Tantek
• MUST NOT support an unprefixed version of the feature
• MUST NOT support a prefix specific to a third party for the feature
• MAY use a prefix specific to the CSS WG for the feature, if one is ever introduced, e.g. -css- or -csswg-
  • disputed, could include level, e.g. -css4-
• MAY use a prefix specific to the W3C for the feature, if one is ever introduced, e.g. -w3- or -w3c-
  • disputed
• MAY use a generic draft prefix, if one is ever introduced, e.g. -draft-, -wd-, -lc- or -ed-
  • disputed, could be versioned

If you are implementing a feature which is defined in a Candidate Recommendation or later (CR, PR, REC), your implementation:

• SHOULD (per CSS-snapshot-2010) support an unprefixed version of the feature
  • suggest this be changed to a MUST. - Tantek
• MUST NOT use any vendor-specific prefix for the implementation of the feature
• SHOULD NOT retain older, incompatible implementations with vendor-specific prefix
  • disputed, see also Transitions section

If you are implementing a feature which is defined in a mature W3C specification (CR, PR, REC), but not in CSS, your implementation:

• SHOULD support an unprefixed version of the feature
• SHOULD NOT use a vendor-specific prefix for the implementation of the feature
  • could be ‘must not’
• MAY use a prefix specific to the issuing WG or to the specification, e.g. -svg-
  • disputed, may be useful in conflict situations

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:

• SHOULD use a prefix specific to the issuing body for the implementation of the feature, e.g. -epub- or -wap-
  • Third parties SHOULD define a prefix applicable for features in their specifications.
• MAY use a vendor-specific prefix for the implementation of the feature
• MUST NOT support an unprefixed version of the feature

For non-mature specifications adopt the convention for WDs.

If you are implementing a feature which is intended for internal use only, your implementation:

• MUST use a vendor-specific prefix for the implementation of the feature
  • You SHOULD document the feature publicly.
• SHOULD limit the feature to local resources and then MAY make global support opt-in for users
  • You MUST document the feature publicly, if your implementation supports it for non-local resources.
• SHOULD NOT support a feature named the same (ignoring prefixes) as a feature in any W3C draft in a different sense
• MUST NOT support an unprefixed version of the feature

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:

• SHOULD support an un-prefixed version of the feature (this will help exit CR)
• SHOULD consider dropping the vendor-specific prefixed version of the feature.
  • Eric Meyer’s article on the topic at A List Apart raised a discussion at www-style in 2010

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, zoom-in and zoom-out.

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 zoom-in and zoom-out.

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:

• implementation experience with a vendor-prefixed version of the feature, combined with
• expected/anticipated feature stability (on a case-by-case basis – up to the usual consensus consideration of the working group).

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.

-ah- Antenna House -apple- Webkit -atsc- Advanced Television Standards Committee -epub- ePUB (Electronic Publication format) -hp- Hewlett Packard -ibooks- Apple iBooks -khtml- KDE Konqueror -ms- Microsoft Internet Explorer -mso- Microsoft Office -moz- Mozilla (Gecko) -o- Opera -prince- Yes Logic Prince -rim- Research In Motion -ro- Real Objects -tc- Tall Components -wap- The WAP Forum -webkit- Apple Safari, Google Chrome etc. (WebKit) -weasy- Weasy Print -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. -css3-, -svg-2-, -wd-2012- and -draftX-.

-w3- W3C – World Wide Web Consortium -w3c- ::: -css- CSS – Cascading Stylesheets -csswg- CSS Working Group -wg- ::: -svg- SVG – Scalable Vector Graphics -svgwg- SVG Working Group -xsl- XSL – Extensible Stylesheet Language (Family) -xslfo- XSL Formatting Objects -fo- ::: -xppl- XPPL – XML Print and Page Layout Working Group -xml- :::

-alpha- “alpha” -beta- “beta” -expires- “expires”, “expiration date” -exp- “experimental” or “expires” -x- “experimental” -test- “test”, “in testing”

-draft- “draft” -pd- “proposed draft”, “proposal”, “public draft”, “private draft” -ed- Editor’s Draft -wd- Working Draft -lc- Last Call Working Draft -lcwd- ::: -cr- Candidate Recommendation -pr- Proposed Recommendation -rec- Recommendation -tr- :::

-vendor- Example vendor prefix -vnd- ::: -ua- Example user agent prefix -browser- ::: -org- Example third party prefix -spec- Example third party specification prefix -example- Example prefix -xmp- ::: -pre- ::: -prefix- :::