Changes between Version 9 and Version 10 of DeprecatingFeatures
- Timestamp:
- Sep 21, 2012 4:16:22 PM (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
DeprecatingFeatures
v9 v10 29 29 This approach as two main benefits: 30 30 31 1.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.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. 32 32 33 2.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.33 * 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. 34 34 35 35 == Measure, deprecate, and remove == … … 45 45 = Special considerations for vendor prefixes = 46 46 47 = XYZZY = 47 Generally speaking, removing vendor prefixes is similar to remove support for a feature. However, there are two important differences: 48 48 49 = Deprecation steps = 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. 50 50 51 * Any deprecation should be sent to webkit-dev for discussion. 52 * Any deprecation requires some data as to why the feature can be deprecated. The goal of the data is to show that the feature is not widely used and is not popular. The following would qualify: 53 * usage statistics in the wild (either by instrumenting the browser or any other means). 54 * some discussions on the standard mailing lists underlining that the standards' bodies don't think there is enough traction to get the feature standardized. 55 * some proof that there is others way to achieve the same result that are better. 56 * some proof that web-developers don't care much about this feature. 57 * ... 58 * If several vendors are supporting the feature, we expect people to have interacted with them to assess their support towards the removal. 59 60 = Deprecating a prefixed feature = 61 62 Deprecating a prefixed feature should be treated as deprecating an existing features and should follow the previous steps. 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.
