"CSS parsing is the same, though. Slurping up your CSS and turning it into CSSOM’s pretty standard. Yeah, though Chrome accepts just the -webkit- prefix whereas Apple and other ports accept legacy prefixes like -khtml- and -apple-."
If developers start using this technique, it might be harder to remove these prefixes in the future. Chromium's experience removing these prefixes has been quite positive. We ran into one compatibility problem on apple.com, which Apple was gracious enough to fix.
While going through WebCore for some CSS research I'm currently doing, I came across a piece of code which translates all "-khtml-" and "-apple-" vendor-prefixes to "-webkit-". This effectively means "-apple-transform" and "-khtml-transform" can both be used instead of "-webkit-transform". I am unaware of the rationales behind the apple vendor-prefix, but I'd like to propose removing support for the KHTML-prefix.
My main argument for this is that WebKit and KHTML are, in my opinion, two separate engines by two separate vendors. The port occurred eight years ago, and code in both projects has changed significantly ever since. [...]
I understand the history of supporting -khtml-, and have heard from the KHTML project that they implement the -webkit- prefix as well. However, considering that WebKit has grown significantly in the past few years and that all code changes basically made KHTML and WebKit two individual rendering engines, with individual CSS support, I believe it would be appropriate for support to be dropped.
The reason for these is historical. Originally, we didn't use a separate vendor prefix for WebKit, just -khtml. Later we changed to -apple. Eventually we realized WebKit would not be an Apple-specific project forever, so we switched to -webkit. The main risk to removing the old prefixes is that some older WebKit-specific content authored against them will break. I'm not sure the code cleanup benefits outweigh the risk of breaking content.
If we want to phase out support for these older prefixes, what I'd propose as a first step is supporting the legacy prefixes for old properties but not for any new ones.
Right now WebKit has by far the most prefixed elements, a significant part of which have not been standardized/drafted yet. Keeping the translation for all properties active practically triples the amount of supported vendor-specific CSS extensions, which cannot be desirable. I'm not opposed to the idea of limiting the supported properties for these prefixes to a certain subset, but my preference would be to only support behavioral properties as "-webkit-binding", "-webkit-font-smoothing", "-webkit-highlight" and "-webkit-user-(drag|modify|select)". In the same piece of code, prefixed versions of border-radixes and opacity are still supported as well. Although I think the latter of which could be removed as well, considering Safari 1.1 got released in 2003.
That's not quite right. Originally we just had -khtml- for CSS extensions, and then we used -apple- for features that we were Apple-specific, i.e., that we knew nobody else would care about. Those features include Dashboard regions and Safari RSS line clamping). Eventually we just decided to merge both into a common prefix, but we wanted to keep the old property names working for compatibility. It was convenient to just map both to -webkit- rather than actually checking the specific property names and only supporting either -khtml- or -apple-.
My recommendation would be as follows:
At the time, we tried an approach recommended by David Hyatt
but that approach appears to have been too agressive in that it broke a number of Dashboard widgets:
This approach lets ports that wish to remain compatible with Dashboard widgets continue to support these prefixes while also letting ports that aren't constrained by dashboard widgets disable them, hopefully lessening their use on the broader web.
I welcome any thoughts the list has on this topic.
One option is to start evaluating the compat implications by disabling the prefixes in Chrome. If we have a positive experience we can disable them in more ports/configurations over time, hopefully arriving where you suggest while avoiding the stress of release blocking bugs.
As discussed in
Chromium experimented with removing the -khtml- and -apple- vendor prefixes from CSS properties. We broke one Apple web page, which Apple was kind enough to fix. Other than that, we have encountered no problems.