| | 37 | 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: |
| | 38 | |
| | 39 | 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.) |
| | 40 | |
| | 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. |
| | 42 | |
| | 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. |
| | 44 | |
