Table of Contents

This page is preserved out of historical interest, but the guidance and rules it suggests are NOT the policy of the CSS Working Group. After much discussion (and this page is part of that discussion), the CSSWG adopted a different set of guidelines, as recorded in section 3.2 of the CSS 2015 Snapshot

CSS Vendor Prefixes

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.

Sources

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.

Please feel free to research those www-style archives and CSS WG minutes (telcon, f2f) and add (with citation!) any conclusions here.

Past discussions (incomplete)

Simple guidance

This page is preserved out of historical interest, but the guidance and rules it suggests are NOT the policy of the CSS Working Group. After much discussion (and this page is part of that discussion), the CSSWG adopted a different set of guidelines, as recorded in section 3.2 of the CSS 2015 Snapshot

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.

Working Draft features

This page is preserved out of historical interest, but the guidance and rules it suggests are NOT the policy of the CSS Working Group. After much discussion (and this page is part of that discussion), the CSSWG adopted a different set of guidelines, as recorded in section 3.2 of the CSS 2015 Snapshot

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:

Candidate Recommendation features

This page is preserved out of historical interest, but the guidance and rules it suggests are NOT the policy of the CSS Working Group. After much discussion (and this page is part of that discussion), the CSSWG adopted a different set of guidelines, as recorded in section 3.2 of the CSS 2015 Snapshot

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

W3C, but non-CSS features

This page is preserved out of historical interest, but the guidance and rules it suggests are NOT the policy of the CSS Working Group. After much discussion (and this page is part of that discussion), the CSSWG adopted a different set of guidelines, as recorded in section 3.2 of the CSS 2015 Snapshot

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.

Third-party features

This page is preserved out of historical interest, but the guidance and rules it suggests are NOT the policy of the CSS Working Group. After much discussion (and this page is part of that discussion), the CSSWG adopted a different set of guidelines, as recorded in section 3.2 of the CSS 2015 Snapshot

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.

Internal features

This page is preserved out of historical interest, but the guidance and rules it suggests are NOT the policy of the CSS Working Group. After much discussion (and this page is part of that discussion), the CSSWG adopted a different set of guidelines, as recorded in section 3.2 of the CSS 2015 Snapshot

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.

Transitions

This page is preserved out of historical interest, but the guidance and rules it suggests are NOT the policy of the CSS Working Group. After much discussion (and this page is part of that discussion), the CSSWG adopted a different set of guidelines, as recorded in section 3.2 of the CSS 2015 Snapshot

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:

open questions

When to implement un-prefixed features

This page is preserved out of historical interest, but the guidance and rules it suggests are NOT the policy of the CSS Working Group. After much discussion (and this page is part of that discussion), the CSSWG adopted a different set of guidelines, as recorded in section 3.2 of the CSS 2015 Snapshot

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 to drop vendor-prefixed features

This page is preserved out of historical interest, but the guidance and rules it suggests are NOT the policy of the CSS Working Group. After much discussion (and this page is part of that discussion), the CSSWG adopted a different set of guidelines, as recorded in section 3.2 of the CSS 2015 Snapshot

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 in a post-CR LCWD

This page is preserved out of historical interest, but the guidance and rules it suggests are NOT the policy of the CSS Working Group. After much discussion (and this page is part of that discussion), the CSSWG adopted a different set of guidelines, as recorded in section 3.2 of the CSS 2015 Snapshot

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.

specific cases

cursor zoom-in zoom-out

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:

Known prefixes

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)

Reserved prefixes

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

W3C bodies and specifications

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

Generic statuses

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

For use in examples or discussion

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