[webkit-dev] Removing support for the -khtml- (and -apple-?) vendor prefixes
peter at lvp-media.com
Mon Jul 12 10:44:03 PDT 2010
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
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.
On Mon, Jul 12, 2010 at 19:09, Maciej Stachowiak <mjs at apple.com> wrote:
> 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.
> 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 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
>> 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.
>> Peter Beverloo
>>  http://trac.webkit.org/browser/trunk/WebCore/css/CSSParser.cpp#L5583
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
More information about the webkit-dev