Merge pull request #50 from frivoal/florian/prefix-policy-clarifications

[css-2015] Clarify why unstable features should be released both prefixed and unprefixed

Author: frivoal

css-2015/Overview.bs

@@ -9,6 +9,7 @@ URL: https://drafts.csswg.org/css-2015/
 TR: https://www.w3.org/TR/CSS
 Editor: Tab Atkins Jr., Google, http://xanthir.com/
 Editor: Elika J. Etemad / fantasai, Invited Expert, http://fantasai.inkedblade.net/contact
+Editor: Florian Rivoal, Invited Expert, florian@rivoal.net, http://florian.rivoal.net
 Abstract: This document collects together into one definition all the specs that
 	together form the current state of Cascading Style Sheets (CSS) as of 2015.
 	The primary audience is CSS implementers, not CSS authors, as this definition
@@ -504,12 +505,40 @@ Requirements for Responsible Implementation of CSS</h2>
 			Once the feature has stabilized and the implementation is updated to match interoperable behavior,
 			support for the prefixed syntax should be removed.
 
+			Note: Anyone promoting <a>unstable</a> features to authors
+			is urged to describe them
+			through their standard unprefixed syntax,
+			and to avoid encouraging the use of the prefixed syntax
+			for any purpose other than working around implementation differences.
+
 			<details class=why>
 				<summary>Why?</summary>
 				This is recommended so that authors can use the unprefixed syntax to target all implementations,
 				but when necessary, can target specific implementations
 				to work around incompatibilities among implementations
 				as they get ironed out through the standards/bugfixing process.
+
+				Some authors unfamiliar with this approach
+				and accustomed to the earlier practice
+				of shipping unstable features only under a prefix
+				may fail to notice that using the unprefixed syntax
+				is sufficient to target all implementations,
+				and may therethore include the prefixed syntax
+				of the various vendors
+				followed by the unprefixed syntax.
+
+				Even in the face of this possible misuse,
+				this approach still beneficial.
+				The lack of a phase
+				where only the prefixed syntax is supported
+				greatly reduces the risk of stylesheets
+				targetting only this prefixed syntax being written.
+				This in turns allow UA vendors to retire
+				their prefixed syntax once the feature is stable,
+				without risking breaking existing content.
+				It also reduces the need occasionally felt by by some vendors
+				to support a feature with the prefix of another vendor,
+				due to content depending on that syntax.
 			</details>
 
 			In order to preserve the open nature of CSS as a technology,