[css-2015] Make recommendation about prefix documentation normative, add some subheadings, move feedback notes.

Author: fantasai

css-2015/Overview.bs

@@ -485,8 +485,6 @@ Proprietary and Non-standardized Features</h4>
 <h4 id="de-facto">
 Market Pressure and De Facto Standards</h4>
 
-	<p class="feedback">Added "should not" against encumbered features, per dbaron's request.
-
 	If a feature is <a>unstable</a> (i.e. the spec has not stabilized yet), yet
 
 	*	at least three UAs implement the feature
@@ -510,56 +508,55 @@ Market Pressure and De Facto Standards</h4>
 		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.
+	</details>
 
-		<p>Note, though, that the CSSWG must still be consulted to ensure coordination across vendors
+	<p class="note">Note that the CSSWG must still be consulted to ensure coordination across vendors
 		and to ensure sanity review by the CSS experts from each vendor.
 		Note also that <a>rough interoperability</a> 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>
 
-	<p>When exposing such an <a>unstable</a> feature to the Web in a production release,
-	implementations should support both <a>vendor-prefixed</a> and unprefixed syntaxes
+<h5 id="unstable-syntax" class="no-toc">
+Vendor-prefixing Unstable Features</h5>
+
+	<p>When exposing such a standards-track <a>unstable</a> feature to the Web in a production release,
+	implementations should support <em>both</em> <a>vendor-prefixed</a> and unprefixed syntaxes
 	for the feature.
 	Once the feature has stabilized and the implementation is updated to match interoperable behavior,
 	support for the <a>vendor-prefixed</a> 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 <a>vendor-prefixed</a> 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.
+		being written with only the vendor-prefixed syntax.
 		This in turn allows UA vendors to retire
 		their prefixed syntax once the feature is stable,
-		without risking breaking existing content.
+		with a lower risk of 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>
 
+	<p class="feedback">Added "should not" against advocating prefixed syntax,
+	per Florian's clarification of dual-syntax usage.
+
+	Anyone promoting <a>unstable</a> features to authors
+	should document them using their standard unprefixed syntax,
+	and avoid encouraging the use of the <a>vendor-prefixed</a> syntax
+	for any purpose other than working around implementation differences.
+
+<h5 id="open-technology" class="no-toc">
+Preserving the Openness of CSS</h5>
+
+	<p class="feedback">Added "should not" against encumbered features, per dbaron's request.
+
 	In order to preserve the open nature of CSS as a technology,
 	vendors should make it possible for other implementors
 	to freely implement any features that they do ship.
@@ -568,7 +565,6 @@ Market Pressure and De Facto Standards</h4>
 	and avoid other obstacles (e.g., platform dependency, licensing restrictions)
 	to their competitors shipping the feature.
 
-
 <h3 id="testing">Implementations of CR-level Features</h3>
 
 	Once a specification reaches the Candidate Recommendation stage,