[webkit-dev] Removing support for the -khtml- (and -apple-?) vendor prefixes

[Peter Beverloo]

Right now WebKit has by far the most prefixed elements[1], 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.

Regards,
Peter Beverloo
http://peter.sh/

[1] http://peter.sh/examples/?/css/vendor-prefix.html
[2] https://bugs.webkit.org/show_bug.cgi?id=42093

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