Re: [webkit-dev] Removing support for the -khtml- (and -apple-?) vendor prefixes
On Mon, Jul 12, 2010 at 22:28, David Hyatt hy...@apple.com wrote: On Jul 12, 2010, at 12:09 PM, Maciej Stachowiak 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. 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: (1) Drop support for -khtml- completely. (2) Continue to support -apple- for -apple-dashboard-region and -apple-line-clamp only. dave (hy...@apple.com) I have submitted a patch[1] following your recommendations. Regards, Peter Beverloo [1] https://bugs.webkit.org/show_bug.cgi?id=42093 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Removing support for the -khtml- (and -apple-?) vendor prefixes
Sounds like an easy patch to post. I'm in favor of removing this support. Reducing the number of non-standard CSS properties we support seems like a good thing. -eric On Mon, Jul 12, 2010 at 1:53 AM, Peter Beverloo pe...@lvp-media.com 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
Re: [webkit-dev] Removing support for the -khtml- (and -apple-?) vendor prefixes
Please post a patch: http://webkit.org/coding/contributing.html On Mon, Jul 12, 2010 at 8:25 AM, Eric Seidel e...@webkit.org wrote: Sounds like an easy patch to post. I'm in favor of removing this support. Reducing the number of non-standard CSS properties we support seems like a good thing. -eric On Mon, Jul 12, 2010 at 1:53 AM, Peter Beverloo pe...@lvp-media.com 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
Re: [webkit-dev] Removing support for the -khtml- (and -apple-?) vendor prefixes
On Mon, Jul 12, 2010 at 18:00, Ryosuke Niwa rn...@webkit.org wrote: While converting all -khtml- properties to -webkit- may not be appropriate because there could be incompatible implementation of certain property, there are properties starting with -khtml- that are supposed to be supported by WebKit. See bugs such as https://bugs.webkit.org/show_bug.cgi?id=11825. Not supporting these will be a burden for some Web developers as they need to add both -khtml- and -webkit- to specify one property. Best, Ryosuke Niwa On Mon, Jul 12, 2010 at 1:53 AM, Peter Beverloo pe...@lvp-media.com 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 I decided to take this issue to the mailing lists before posting a patch for such reasons. The Apple documentation which is referred to[1] in that bug has been updated to use WebKit's own vendor prefix, so I suspect the impact of removing -khtml- will be rather small. After all, that regression happened about four years ago. I will upload a patch within a few hours. Regards, Peter Beverloo http://peter.sh/ [1] http://developer.apple.com/mac/library/documentation/AppleApplications/Conceptual/SafariJSProgTopics/Tasks/DragAndDrop.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Removing support for the -khtml- (and -apple-?) vendor prefixes
On Mon, Jul 12, 2010 at 9:20 AM, Peter Beverloo pe...@lvp-media.com wrote: I decided to take this issue to the mailing lists before posting a patch for such reasons. The Apple documentation which is referred to[1] in that bug has been updated to use WebKit's own vendor prefix, so I suspect the impact of removing -khtml- will be rather small. After all, that regression happened about four years ago. You'll hope. There was a incident about a year ago where MediaWiki had a work-around for a very old KHTML bug and we had to add a special work around for MediaWiki for the compatibility. (See https://bugs.webkit.org/show_bug.cgi?id=28350). Later, we found that there are various websites that uses 3 years old or older copies of MediaWiki. I'm very afraid that the change you proposed will cause many problems like that. But don't take me wrong, I like your idea. I'm just saying we have to be extra careful. Best, Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Removing support for the -khtml- (and -apple-?) vendor prefixes
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
Re: [webkit-dev] Removing support for the -khtml- (and -apple-?) vendor prefixes
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
Re: [webkit-dev] Removing support for the -khtml- (and -apple-?) vendor prefixes
Excuse me, I forgot to note the new bug + patch in my previous mail, although it was listed in the references. https://bugs.webkit.org/show_bug.cgi?id=42093 Regards, Peter Beverloo http://peter.sh/ On Mon, Jul 12, 2010 at 17:26, Eric Seidel e...@webkit.org wrote: Please post a patch: http://webkit.org/coding/contributing.html On Mon, Jul 12, 2010 at 8:25 AM, Eric Seidel e...@webkit.org wrote: Sounds like an easy patch to post. I'm in favor of removing this support. Reducing the number of non-standard CSS properties we support seems like a good thing. -eric On Mon, Jul 12, 2010 at 1:53 AM, Peter Beverloo pe...@lvp-media.com 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
Re: [webkit-dev] Removing support for the -khtml- (and -apple-?) vendor prefixes
On Jul 12, 2010, at 10:44 AM, Peter Beverloo wrote: 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. WebKit really uses vendor-prefixed properties for a few different purposes: 1) Properties that are only intended to be used internal to the engine, to implement particular effects. 2) Properties that are future CSS standards but not yet mature enough to remove the prefix. 3) Experimental properties that may be proposed as standards in the future. 4) Proprietary properties that we don't intend to standardize, but which can be used by content. 5) Properties that were once prefixed for one of the above reasons, and we keep the prefixed version in addition to the unprefixed one. One beneficial exercise would be to classify prefixed properties into the above buckets. For categories (3) and (4), we should consider whether the properties in question can actually be proposed as standards, and therefore move to category (2). For category (5), we should assess the compatibility impact of removing the prefixed version. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Removing support for the -khtml- (and -apple-?) vendor prefixes
On Jul 12, 2010, at 12:09 PM, Maciej Stachowiak 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. 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: (1) Drop support for -khtml- completely. (2) Continue to support -apple- for -apple-dashboard-region and -apple-line-clamp only. dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
