| 1 | | This is a follow-up on WebKit contributors' meeting 2012 talk about [wiki:"Deprecating features and vendor prefixes"]. |
| | 1 | = Overview = |
| | 2 | |
| | 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. |
| | 4 | |
| | 5 | = Balancing costs and benefits = |
| | 6 | |
| | 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. |
| | 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 = |
