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 <m...@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@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev