Changes between Version 2 and Version 3 of DeprecatingFeatures


Ignore:
Timestamp:
Sep 21, 2012 2:46:14 PM (10 years ago)
Author:
abarth@webkit.org
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • DeprecatingFeatures

    v2 v3  
    1 This is a follow-up on WebKit contributors' meeting 2012 talk about [wiki:"Deprecating features and vendor prefixes"].
     1= Overview =
     2
     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 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.
     4
     5= Balancing costs and benefits =
     6
     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, and whenever possible, we should strive to replace opinion with data.
     8
     9== Costs of removing a feature ==
     10
     11 * ''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/ SQLDatabse] even though other browser vendors have refused to implement the feature and the W3C has removed the specification from the standards track.
     12
     13
     14= XYZZY =
    215
    316= How to determine if we can deprecate a feature =