Updating Our Prefixing Policy
When implementing new features for the Web, it’s important for us to be able to get them into the hands of developers early, so they can give new things a try. (Of course, this also helps us identify and fix bugs!) In the past, browsers did this by using vendor-prefixed names for features. This was intended to protect the Web from the churn of spec and implementation changes. Browsers would eventually implement the standard version with no prefix and drop support for the prefixed version.
Over time this strategy has turned out not to work so well. Many websites came to depend on prefixed properties. They often used every prefixed variant of a feature, which makes CSS less maintainable and JavaScript programs trickier to write. Sites frequently used just the prefixed version of a feature, which made it hard for browsers to drop support for the prefixed variant when adding support for the unprefixed, standard version. Ultimately, browsers felt pressured by compatibility concerns to implement each other’s prefixes.
The current consensus among browser implementors is that, on the whole, prefixed properties have hurt more than they’ve helped. So, WebKit’s new policy is to implement experimental features unprefixed, behind a runtime flag. Runtime flags allow us to continue to get experimental features into developers’ hands while avoiding the various problems vendor prefixes had. Runtime flags also make it easier for us to have different default settings between stable builds and preview builds such as Safari Technology Preview.
We’ll be applying our updated policy to new feature work going forward. Whether or not a runtime flag should be on or off on WebKit trunk (and thus in nightly builds) depends on the maturity of the feature, both in terms of its spec stability and implementation maturity.
What does this mean for Web developers?
Initially, developers shouldn’t notice anything different. In the longer term we hope this change will make it easier for you to try out upcoming features. As always, we encourage you to give in-progress features a try. Feedback and bug reports on experimental features are very welcome.
What about currently prefixed features?
We’ll be evaluating existing features on a case-by-case basis. We expect to significantly reduce the number of prefixed properties supported over time but Web compatibility will require us to keep around prefixed versions of some features.
We invite comments and feedback on the new policy from Web developers, educators, and our colleagues working on other browser engines. Feel free to reach out to me on Twitter (@hober), Jon Davis (@jonathandavis), @webkit, or email me directly at hober@apple.com.