[webkit-dev] Removing support for the -khtml- (and -apple-?) vendor prefixes
Maciej Stachowiak
mjs at apple.com
Mon Jul 12 10:09:11 PDT 2010
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.
Regards,
Maciej
On Jul 12, 2010, at 1:53 AM, Peter Beverloo wrote:
> Good day,
>
> While going through WebCore for some CSS research I'm currently doing,
> I came across a piece of code[1] 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. When Microsoft announced support for "-webkit-text-size-adjust"
> in IE Mobile it was argued that browsers should not implement
> properties with prefixes "belonging" to other vendors, which seems to
> be exactly what WebKit is doing with the KHTML prefix.
>
> 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.
>
> Regards,
> Peter Beverloo
> http://peter.sh/
>
> [1] http://trac.webkit.org/browser/trunk/WebCore/css/CSSParser.cpp#L5583
> [2] http://blogs.msdn.com/b/iemobile/archive/2010/05/10/javascript-and-css-changes-in-ie-mobile-for-windows-phone-7.aspx
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
More information about the webkit-dev
mailing list