Changes between Version 12 and Version 13 of DeprecatingFeatures

Timestamp:

Sep 21, 2012, 5:31:04 PM (12 years ago)

Author:

abarth@webkit.org

Comment:

--

DeprecatingFeatures

@@ -37 +37 @@
 == Measure, deprecate, and remove ==
 
-The most measured way to remove a feature is to quantify the compatibility costs of removing the feature by collecting usage metrics.  Typically, this approach proceeds in three steps:
+The most data-driven way to remove a feature is to quantify the compatibility costs of removing the feature by collecting usage metrics.  Typically, this approach proceeds in three steps:
 
  1. Use FeatureObserver to measure how often a given feature is used.  This webkit-dev post contains [http://lists.webkit.org/pipermail/webkit-dev/2012-September/022239.html instructions for using FeatureObserver].  (Currently only the [[Chromium]] port implements the backend for FeatureObserver, but hopefully other ports will add support in the future.)
@@ -47 +47 @@
 = Special considerations for vendor prefixes =
 
-Generally speaking, removing vendor prefixes is similar to remove support for a feature.  However, there are two important differences:
+Generally speaking, removing vendor prefixes is similar to remove support for a feature.  However, there are two additional considerations:
 
  * ''Clear path forward.''  When we remove a vendor prefix, web developers have a clear path forward: use the unprefixed version of the API.  This clear path forward means that we won't strand developers when we remove a vendor-prefixed version of an API.
 
- * ''Obligation to unprefix.''  Many W3C working groups, including the CSS working group, [http://wiki.csswg.org/spec/vendor-prefixes request that implementors remove support for vendor prefixed features] once the specifications of the features reach a certain level of maturity, typically Candidate Recommendation.  By participating in those working groups, we incur an obligation to remove these vendor prefixes, even if doing so would incur a larger compatibility cost than we would otherwise prefer.  Of course, in some cases, the costs will be too high and we will be unable to remove the prefixes, but we should make an effort to remove vendor prefixes whenever possible.
+ * ''Standards citizenship.''  Many W3C working groups, including the CSS working group, [http://wiki.csswg.org/spec/vendor-prefixes request that implementors remove support for vendor prefixed features] once the specifications of the features reach a certain level of maturity, typically Candidate Recommendation.  To be good citizens of these standards bodies, we should make an effort to remove vendor prefixes whenever possible, even if doing so would incur a larger compatibility cost than we would otherwise prefer.