Home Specs Ideas Testing About
You are here: CSS Working Group Wiki » Specification Issues and Planning » CSS Vendor Prefixes

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
spec:vendor-prefixes [2014/12/09 15:48] – external edit 127.0.0.1spec:vendor-prefixes [2015/11/06 20:25] (current) – [open questions] florian
Line 1: Line 1:
-====== CSS Vendor Prefixes ======+<note warning>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 [[http://www.w3.org/TR/CSS/#future-proofing|section 3.2 of the CSS 2015 Snapshot]]</note>
  
 +
 +====== CSS Vendor Prefixes ======
 In CSS we use [[http://www.w3.org/wiki/Evolution/Identifiers|vendor prefixes]] for properties, values, @-rules that are: In CSS we use [[http://www.w3.org/wiki/Evolution/Identifiers|vendor prefixes]] for properties, values, @-rules that are:
   * [[http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords|vendor specific extensions (per CSS 2.1)]], or   * [[http://www.w3.org/TR/CSS21/syndata.html#vendor-keywords|vendor specific extensions (per CSS 2.1)]], or
Line 33: Line 35:
  
 ===== Simple guidance ===== ===== Simple guidance =====
 +
 +<note warning>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 [[http://www.w3.org/TR/CSS/#future-proofing|section 3.2 of the CSS 2015 Snapshot]]</note>
 +
 Simple straw proposal guidance. Terms per RFC2119 etc. Simple straw proposal guidance. Terms per RFC2119 etc.
  
Line 38: Line 43:
  
 ==== Working Draft features ==== ==== Working Draft features ====
 +<note warning>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 [[http://www.w3.org/TR/CSS/#future-proofing|section 3.2 of the CSS 2015 Snapshot]]</note>
 +
 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 only defined in a Working Draft (WD, including Last Call LCWD and Editor’s Draft ED), your implementation:
   * SHOULD ([[http://www.w3.org/TR/css-2010/#experimental|per CSS-snapshot-2010]]) use a vendor-specific prefix for the implementation of the feature   * SHOULD ([[http://www.w3.org/TR/css-2010/#experimental|per CSS-snapshot-2010]]) use a vendor-specific prefix for the implementation of the feature
Line 51: Line 58:
  
 ==== Candidate Recommendation features ==== ==== Candidate Recommendation features ====
 +<note warning>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 [[http://www.w3.org/TR/CSS/#future-proofing|section 3.2 of the CSS 2015 Snapshot]]</note>
 +
 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 Candidate Recommendation or later (CR, PR, REC), your implementation:
   * SHOULD ([[http://www.w3.org/TR/css-2010/#experimental|per CSS-snapshot-2010]]) support an unprefixed version of the feature   * SHOULD ([[http://www.w3.org/TR/css-2010/#experimental|per CSS-snapshot-2010]]) support an unprefixed version of the feature
Line 59: Line 68:
  
 ==== W3C, but non-CSS features ==== ==== W3C, but non-CSS features ====
 +<note warning>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 [[http://www.w3.org/TR/CSS/#future-proofing|section 3.2 of the CSS 2015 Snapshot]]</note>
 +
 If you are implementing a feature which is defined in a mature W3C specification (CR, PR, REC), but not in CSS, 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:
   * SHOULD support an unprefixed version of the feature   * SHOULD support an unprefixed version of the feature
Line 70: Line 81:
  
 ==== Third-party features ==== ==== Third-party features ====
 +<note warning>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 [[http://www.w3.org/TR/CSS/#future-proofing|section 3.2 of the CSS 2015 Snapshot]]</note>
 +
 If you are implementing a feature which is defined in a mature non-W3C specification, but not in CSS, your implementation: 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-''   * SHOULD use a prefix specific to the issuing body for the implementation of the feature, e.g. ''-epub-'' or ''-wap-''
Line 78: Line 91:
  
 ==== Internal features ==== ==== Internal features ====
 +<note warning>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 [[http://www.w3.org/TR/CSS/#future-proofing|section 3.2 of the CSS 2015 Snapshot]]</note>
 +
 If you are implementing a feature which is intended for internal use only, your implementation: 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   * MUST use a vendor-specific prefix for the implementation of the feature
Line 88: Line 103:
  
 ==== Transitions ==== ==== Transitions ====
 +<note warning>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 [[http://www.w3.org/TR/CSS/#future-proofing|section 3.2 of the CSS 2015 Snapshot]]</note>
 +
 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: 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 support an un-prefixed version of the feature (this will help exit CR)
Line 95: Line 112:
 ===== open questions ===== ===== open questions =====
 ==== When to implement un-prefixed features ==== ==== When to implement un-prefixed features ====
 +<note warning>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 [[http://www.w3.org/TR/CSS/#future-proofing|section 3.2 of the CSS 2015 Snapshot]]</note>
 +
 +
 +
 When is the best time to implement the unprefixed version of a feature? When is the best time to implement the unprefixed version of a feature?
  
Line 106: Line 127:
  
 ==== When to drop vendor-prefixed features ==== ==== When to drop vendor-prefixed features ====
 +<note warning>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 [[http://www.w3.org/TR/CSS/#future-proofing|section 3.2 of the CSS 2015 Snapshot]]</note>
 +
 +
 +
 When is the best time to drop support for the vendor-prefixed version of a feature? When is the best time to drop support for the vendor-prefixed version of a feature?
  
Line 113: Line 138:
  
 ==== Is it okay to implement unprefixed features in a post-CR LCWD ==== ==== Is it okay to implement unprefixed features in a post-CR LCWD ====
 +<note warning>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 [[http://www.w3.org/TR/CSS/#future-proofing|section 3.2 of the CSS 2015 Snapshot]]</note>
 +
 +
 +
 Is it okay to implement unprefixed features when a CR is taken back to Last Call for non-trivial changes? Is it okay to implement unprefixed features when a CR is taken back to Last Call for non-trivial changes?
  
 
spec/vendor-prefixes.txt · Last modified: 2015/11/06 20:25 by florian
Recent changes RSS feed Valid XHTML 1.0 Valid CSS Driven by DokuWiki