Version 8 (modified by, 11 years ago) (diff)



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.

Balancing costs and benefits

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:

  • 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 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.
  • Interoperability. If a feature fails to garner wide-spread implementation, then web sites that use that feature might work in one user agent but not in another. This lack of interoperability fractures the web platform, making it more difficult for users to switch from one user agent to another. Removing WebKit-proprietary features, or at least hiding them from the web platform, often improves interoperability.
  • 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, for example 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.

Approaches for removing features

There are a number of different approaches you can use to remove features from WebKit. Similar to adding features, it's important to communicate clearly with the WebKit community. Often emailing 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.

Cold turkey

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 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.

Removing a feature cold turkey is also appropriate if the feature is actively causing security or stability problems for WebKit. For example, we 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.

A port-specific experiment

A more controlled approach to removing a feature is to remove the feature from a single port as an experiment. In this approach, one port removes the feature (e.g., via an ENABLE macro or a run-time setting) and gathers feedback from its release cycle. If the port succeeds in removing the feature, we can then remove the feature from the remaining ports with greater confidence that they will also avoid problems.

This approach as two main benefits:

  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.
  1. 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.

Measure, deprecate, and remove

Special considerations for vendor prefixes


Deprecation steps

  • Any deprecation should be sent to webkit-dev for discussion.
  • 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:
    • usage statistics in the wild (either by instrumenting the browser or any other means).
    • some discussions on the standard mailing lists underlining that the standards' bodies don't think there is enough traction to get the feature standardized.
    • some proof that there is others way to achieve the same result that are better.
    • some proof that web-developers don't care much about this feature.
    • ...
  • If several vendors are supporting the feature, we expect people to have interacted with them to assess their support towards the removal.

Deprecating a prefixed feature

Deprecating a prefixed feature should be treated as deprecating an existing features and should follow the previous steps.