Changes between Version 11 and Version 12 of DeprecatingFeatures


Ignore:
Timestamp:
Sep 21, 2012 4:30:25 PM (12 years ago)
Author:
abarth@webkit.org
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • DeprecatingFeatures

    v11 v12  
    11= Overview =
    22
    3 We hope that the vast majority of features we add to WebKit will become widely implemented by other web rendering engines and enjoyed by authors and users for years to come.  However, if we avoided landing code for a feature until we were sure that feature would be successful, we wouldn't be perpetually following rather than leading, and the web platform would not advance as quickly.  This wiki page explains how to handle those cases in which we wish to remove a feature from WebKit.
     3We hope that the vast majority of features we add to WebKit will become widely implemented by other web rendering engines and enjoyed by authors and users for years to come.  However, if we avoided landing code for a feature until we were sure that feature would be successful, we would be perpetually following rather than leading, and the web platform would not advance as quickly.  This wiki page explains how to handle those cases in which we wish to remove a feature from WebKit.
    44
    55= Balancing costs and benefits =
    66
    7 The guiding principle in our approach is to balance net costs of removing the feature against the net costs of retaining the feature.  In many cases, evaluating these costs is a value judgement, and whenever possible, we should strive to replace opinion with data.  The following are some factors we ought to consider when removing a feature:
     7The guiding principle in our approach is to balance net costs of removing the feature against the net costs of retaining the feature.  In many cases, evaluating these costs is a value judgement, but, whenever possible, we should strive to replace opinion with data.  The following are some factors we ought to consider when removing a feature:
    88
    99 * ''Compatibility.''  The more a given feature is used, particularly on the web at large but also in "walled gardens" of content, the larger the compatibility cost of removing the feature.  For example, we have not removed our implementation of [http://www.w3.org/TR/webdatabase/ SQLDatabase] even though other browser vendors have refused to implement the feature and the W3C has removed the specification from the standards track.  We've kept SQLDatabase because removing this API would break compatibility with a large number of consumers of WebKit that use this API.
    … …  
    1313 * ''Complexity.''  Each feature we include in WebKit increases WebKit's complexity, slowing down development of the engine.  We try to reduce the complexity cost of features (e.g., by using [[Modules]]), but each feature still adds a non-zero cost (e.g., for project-wide improvements, like [[EfficientStrings]]).  Removing some features (e.g., Workers) would reduce the complexity of WebKit greatly, whereas removing others (e.g., Blob.webkitSlice) would have little impact on WebKit's overall complexity.
    1414
     15This list is certainly not exhaustive.  For example, some feature might have security or stability costs that we should also consider.  Ultimately, we need to balance the costs and benefits on a feature-by-feature basis.
     16
    1517= Approaches for removing features =
    1618
    17 There are a number of different approaches you can use to remove features from WebKit.  Similar to [http://www.webkit.org/coding/adding-features.html adding features], it's important to communicate clearly with the WebKit community.  Often emailing [http://lists.webkit.org/mailman/listinfo/webkit-dev webkit-dev] is a good place to start.  In your email, you will likely want to outline which feature you'd like to remove, the relative costs and benefits of removing the feature, and which of the following approaches you intend to take.
     19There are a number of different approaches you can use to remove a feature from WebKit.  Similar to [http://www.webkit.org/coding/adding-features.html adding features], it's important to communicate clearly and broadly with the WebKit community.  Often emailing [http://lists.webkit.org/mailman/listinfo/webkit-dev webkit-dev] is a good place to start.  In your email, you will likely want to outline which feature you'd like to remove, the relative costs and benefits of removing the feature, and which of the following approaches you intend to take.
    1820
    1921== Cold turkey ==
    2022
    21 Perhaps the crudest approach to removing a feature is to simply delete it, cold turkey.  We might use this sort of approach when we're sure we understand the costs of removing a feature.  For example, we [http://trac.webkit.org/changeset/123724 removed the first iteration of the PeerConnection API] cold turkey because we knew that the API was not in wide use and that the working group standardizing PeerConnection had redesigned the API.
     23Perhaps the crudest approach to removing a feature is to simply delete it, cold turkey.  We might use this approach when we're sure we understand the costs of removing a feature.  For example, we [http://trac.webkit.org/changeset/123724 removed the first iteration of the PeerConnection API] cold turkey because we knew that the API was not in wide use and that the working group standardizing PeerConnection had redesigned the API.
    2224
    23 Removing a feature cold turkey is also appropriate if the feature is actively causing security or stability problems for WebKit.  For example, we [http://trac.webkit.org/changeset/111361 removed support for magic iframes] cold turkey because they were an ongoing source of security vulnerabilities.  In these cases, however, we should be prepared to bear the compatibility costs of removing the feature.
     25Removing a feature cold turkey is also appropriate if the feature is actively causing security or stability problems for WebKit.  For example, we [http://trac.webkit.org/changeset/111361 removed support for magic iframes] cold turkey because they were an ongoing source of security vulnerabilities.
    2426
    2527== A port-specific experiment ==
    … …  
    2931This approach as two main benefits:
    3032
    31  * The risks associated with removing a feature are concentrated on a single port.  If you're passionate about removing a feature, you might have more luck convincing one port to experiment with removing a feature than convincing all the ports at once.  That port can bear the risks and the project as a whole can learn about the costs of removing the feature.
     33 * The risks associated with removing a feature are concentrated on a single port.  If you're passionate about removing a feature, you might have more luck convincing one port to experiment with removing a feature than convincing all the ports at once.  That port can bear the risks, and the project as a whole can learn about the costs of removing the feature.
    3234
    3335 * Actually removing a feature is the only way to really know what problems will arise when you remove a feature.  We can estimate the risks by searching for uses of a feature or by measuring how often a feature is used, but those are only estimates.  For example, many web sites detect which features are enabled and then take different code paths depending on what they're able to detect, adding noise both to code searches and to runtime measurements.
    … …  
    3941 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.)
    4042
    41  2. Add log a deprecation message to the console whenever the feature is used.  This message lets web developers know that this feature is deprecated and they should use another feature instead.  Ideally the deprecation message let developers know what they should use instead of this feature.  For example, a deprecation message for webkitIndexedDB might suggest that developers use the unprefixed indexedDB API instead.
     43 2. Log a deprecation message to the console whenever the feature is used.  This message lets web developers know that this feature is deprecated and that they should use another feature instead.  Ideally the deprecation message will let developers know what they should use instead of the deprecated feature.  For example, a deprecation message for window.webkitIndexedDB might suggest that developers use the unprefixed window.indexedDB API instead.
    4244
    43  3. Once usage of the feature drops low enough, remove the feature.  We currently do not have any guidelines for what constitutes "low enough" usage because we don't have much experience removing features based on usage statistics.  Hopefully as we use this approach more, we'll gain experience and have a better sense for how much pain will be caused by removing features with varying levels of usage.
     45 3. Once usage of the feature drops low enough, remove the feature.  Currently, we do not have any guidelines for what constitutes "low enough" usage because we don't have much experience removing features based on metrics.  Hopefully, as we use this approach more, we'll gain experience and have a better sense for how much pain will be caused by removing features with varying levels of usage.
    4446
    4547= Special considerations for vendor prefixes =
    … …  
    4749Generally speaking, removing vendor prefixes is similar to remove support for a feature.  However, there are two important differences:
    4850
    49  * ''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 the vendor-prefixed version of the API.
     51 * ''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.
    5052
    51  * ''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 maturity level, typically Candidate Recommendation.  By participating in those working groups, we incur an obligation to remove such 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 abide by these requests, but we should make an effort to remove vendor prefixes whenever possible.
     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.