Changes between Version 12 and Version 13 of DeprecatingFeatures


Ignore:
Timestamp:
Sep 21, 2012 5:31:04 PM (9 years ago)
Author:
abarth@webkit.org
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DeprecatingFeatures

    v12 v13  
    3737== Measure, deprecate, and remove ==
    3838
    39 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:
     39The 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:
    4040
    4141 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.)
     
    4747= Special considerations for vendor prefixes =
    4848
    49 Generally speaking, removing vendor prefixes is similar to remove support for a feature.  However, there are two important differences:
     49Generally speaking, removing vendor prefixes is similar to remove support for a feature.  However, there are two additional considerations:
    5050
    5151 * ''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.
    5252
    53  * ''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.
     53 * ''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.