merge

Author: dauwhe

css-2015/Overview.bs

@@ -380,57 +380,82 @@ Requirements for Responsible Implementation of CSS</h2>
 
 	To avoid clashes with future stable CSS features,
 	the CSSWG recommends the following best practices for the implementation of
-	unstable features and proprietary extensions to CSS.
-	A CSS feature is considered <dfn>unstable</dfn> unless
-	its specification has reached the Candidate Recommendation (CR) stage in the W3C process.
-	A CSS feature is a <dfn>proprietary extension</dfn> if it is not intended for
-	or released for use on the World Wide Web.
-
-	<ol>
-		<li>
+	<a>unstable</a> features and <a>proprietary extensions</a> to CSS:
+
+	<h4 id="unstable">
+	Experimentation and Unstable Features</h4>
+
+			Issue: Rewritten per gregwhitworth's feedback.
+
 			Implementations of <a>unstable</a> features
 			that are described in W3C specifications
 			but are not interoperable
-			should not be released in production software;
-			but may be released experimentally (unprefixed) in non-release builds.
+			should not be released broadly for general use;
+			but may be released for limited, experimental use in controlled environments.
 
 			<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.
+				We want to allow both authors and implementors to experiment with the feature and give feedback,
+				but prevent authors from relying on them in production websites
+				and thereby accidentally "locking in" (through content dependence)
+				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 an <a>unstable</a> or otherwise non-standard feature in a production release),
+			<div class="example">
+				For example,
+				a UA could release an <a>unstable</a> features for experimentation
+				through beta or other testing-stage builds;
+				behind a hidden configuration flag;
+				behind a switch enabled only for specific testing partners;
+				or through some other means of limiting dependent use.
+			</div>
+
+			A CSS feature is considered <dfn>unstable</dfn> until
+			its specification has reached the Candidate Recommendation (CR) stage in the W3C process.
+			In exceptional cases,
+			the CSSWG may additionally, by an officially-recorded resolution,
+			add pre-CR features to the set that are considered safe to release for broad use.
+
+			Note: Vendors should consult the WG explicitly and not make assumptions on this point,
+			as a pre-CR spec that hasn't changed in awhile is usually more out-of-date than stable.
+
+		<h4 id="de-facto">
+		Market Pressure and De Facto Standards</h4>
+
+			Issue: Added "should not" against encumbered features, per dbaron's request.
+
+			If at least three UAs implement a feature
+			(or if a browser has broken the previous rule and shipped for broad use
+			an <a>unstable</a> or otherwise non-standard feature in a production release),
 			and the implementations have rough interoperability,
 			<em>and</em> the CSS Working Group has recorded consensus that this feature should exist and be released,
 			implementers may ship that feature unprefixed in release builds.
 			<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,
+				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 ship.
+				Also, 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
+				<p>Note, though, 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 "rough interoperability" still usually means painful lack of interop in edge (or not-so-edge) cases,
+				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>
 
-			When exposing an unstable feature to the Web in a production release,
+			<p>When exposing such an <a>unstable</a> feature to the Web in a production release,
 			implementations should support both prefixed and unprefixed syntaxes
 			for the feature.
+			<ins>Once the feature has stabilized and the implementation is updated to match interoperable behavior,
+			support for the prefixed syntax should be removed.</ins>
 
 			<details class=why>
 				<summary>Why?</summary>
@@ -440,22 +465,44 @@ Requirements for Responsible Implementation of CSS</h2>
 				as they get ironed out through the standards/bugfixing process.
 			</details>
 
-		<li>
-			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.)
+			<p>Vendors <em>should</em> provide spec-editing and testing resources
+			to complete standardization of such features.
+			<ins>Vendors <em>should not</em> use this clause as an excuse to release features
+			that cannot be freely implemented by their competitors
+			(due to platform dependency, licensing restrictions, etc.).</ins>
+
+		<h4 id="proprietary">
+		Proprietary and Non-standardized Features</h4>
+
+			Issue: Rewritten as open vs. closed systems instead of Web vs. non-Web, per szilles' request.
+
+			A CSS feature is a <dfn>proprietary extension</dfn> if it is meant for use
+			in a closed environment accessible only to a single vendor's user agent(s).
+			A UA should support such <a>proprietary extensions</a>
+			only through a vendor-prefixed syntax
+			and not expose them to open (multi-UA) environments such as the World Wide Web.
 
 			<details class=why>
 				<summary>Why?</summary>
-				The prefixing requirement allows shipping specialized features in non-Web environments
+				The prefixing requirement allows shipping specialized features in closed 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.
+				The restriction on exposure to open systems is to prevent
+				accidentally causing the public CSS environment
+				to depend on an unstandardized <a>proprietary extensions</a>.
 			</details>
-	</ol>
+
+			<div class="example">
+				For example,
+				Win8 Metro apps, Firefox's XUL-based UI, and the iTunes UI
+				use extensions to CSS implemented by their respective UAs.
+				So long as these UAs do not allow Web content to access these features,
+				they do not provide an opportunity for such content
+				to become dependent on their <a>proprietary extensions</a>.
+			</div>
+
+			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.
 
 
 <h3 id="testing">Implementations of CR-level Features</h3>

css-animations/Overview.bs

@@ -11,8 +11,9 @@ ED: http://dev.w3.org/csswg/css-animations/
 Previous Version: http://www.w3.org/TR/2013/WD-css3-animations-20130219/
 Previous Version: http://www.w3.org/TR/2012/WD-css3-animations-20120403/
 Editor: Dean Jackson, Apple Inc., dino@apple.com
-Editor: L. David Baron, Mozilla, dbaron@dbaron.org
+Editor: L. David Baron, Mozilla, http://dbaron.org/
 Editor: Tab Atkins Jr., Google, http://xanthir.com/contact/
+Editor: Brian Birtles, Mozilla Japan, bbirtles@mozilla.com
 Former Editor: David Hyatt, Apple Inc.
 Former Editor: Chris Marrin, Apple Inc.
 Former Editor: Sylvain Galineau, Adobe, galineau@adobe.com
@@ -1120,6 +1121,12 @@ Acknowledgements</h2>
 	Estelle Weyl,
 	and all the rest of the www-style community.
 
+<h2 id="other-open-issues">Other open issues</h2>
+
+<p class="issue">Need to <a href="https://lists.w3.org/Archives/Public/www-style/2015Jul/0391.html">specify how keyframes interact</a>.</p>
+
+<p class="issue">Need to specify better handling of dynamic changes of animation-name; see <a href="https://twitter.com/estellevw/status/617525016104583168">conversation</a>.</p>
+
 <h2 id="wg-resolutions-pending">
 Working Group Resolutions that are pending editing</h2>