[css-2015] Explain non-prefixing policy.

Author: tabatkins

css-2015/Overview.bs

@@ -260,29 +260,67 @@ Introduction {#intro}
 			should not be released in production software;
 			but may be released experimentally (unprefixed) in non-release builds.
 
+			<details class=why>
+				<summary>Why?</summary>
+				This allows both authors and implementors to experiment with the feature and give feedback,
+				while preventing authors from using them in production websites
+				and thereby accidentally "locking in" certain syntax or behavior that might change later.
+			</details>
+
 		<li>
 			If at least three browsers implement a feature
 			(or if a browser has broken the previous rule and shipped in a production release already),
 			and the implementations have rough interoperability,
-			and the CSS Working Group has consensus that this feature should exist and be released,
+			<em>and</em> the CSS Working Group has recorded consensus that this feature should exist and be released,
 			implementers may ship that feature in a release build.
 			<dfn>Rough interoperability</dfn> is satisfied by a subjective judgment
 			that even though there may be differences,
 			the implementations are sufficiently similar
 			to be used in production websites for a substantial number of use cases.
+			Vendors <em>should</em> provide spec-editing and testing resources to complete standardization of such features.
+
+			<details class=why>
+				<summary>Why?</summary>
+				If a feature has already escaped into the wild and sites have started depending on it,
+				pretending it's still "experimental" doesn't help anyone.
+				Allowing others to ship unprefixed recognizes that the feature is now de facto standardized
+				and encourages authors to write cross-platform code.
+
+				If a feature is sufficiently popular that three or more browsers have implemented it before it's finished standardization,
+				this clause allows releasing the pressure to release.
+				Note, though, that the CSSWG still needs to be consulted to ensure coordination across vendors
+				and to ensure sanity review by the CSS experts from each vendor.
+				Note also that "rough interoperability" still usually means painful lack of interop in edge (or not-so-edge) cases,
+				particularly because details have not been ironed out through the standards review process.
+			</details>
 
-		<li>
 			When exposing an unstable feature to the Web in a production release,
 			implementations should support both prefixed and unprefixed syntaxes
 			for the feature.
 
+			<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.
+			</details>
+
 		<li>
-			When shipping in a production build a feature that is either
-			only meant to be used in non-web environment,
-			or both in web and non-web environment
-			but does not match the criteria of the second rule,
-			it should be supported only through a prefixed syntax,
-			and should not be exposed to the Web environment.
+			When shipping in a production build a feature that is only meant to be used in non-Web environment,
+			it should be supported only through a prefixed syntax
+			and not exposed to the Web.
+			(Even if a feature is intended to eventually be used in the Web,
+			if it hasn't yet been standardized
+			it should still not be exposed to the Web.)
+
+			<details class=why>
+				<summary>Why?</summary>
+				The prefixing requirement allows shipping specialized features in non-Web environments
+				without conflicting with future additions to standard CSS.
+				The restriction on exposure to the Web environment is to prevent
+				accidentally causing the public web to depend on an unstandardized feature.
+			</details>
 	</ol>