Re: [webkit-dev] Following up on removing -khtml- and -apple- CSS vendor prefixes
Resent from the right email address. -- Forwarded message -- From: Ryosuke Niwa rn...@berkeley.edu Date: Thu, May 3, 2012 at 7:49 PM Subject: Re: [webkit-dev] Following up on removing -khtml- and -apple- CSS vendor prefixes To: Adam Barth aba...@webkit.org Cc: Alexey Proskuryakov a...@webkit.org, webkit-dev@lists.webkit.org On Fri, Apr 6, 2012 at 4:27 PM, Adam Barth aba...@webkit.org wrote: 2012/4/5 Alexey Proskuryakov a...@webkit.org: 05.04.2012, в 01:08, Adam Barth написал(а): Based on this information, I've posted a patch that limits the -apple- and -khtml- vendor prefixes to ENABLE(DASHBOARD_SUPPORT): https://bugs.webkit.org/show_bug.cgi?id=83256 This approach lets ports that wish to remain compatible with Dashboard widgets continue to support these prefixes while also letting ports that aren't constrained by dashboard widgets disable them, hopefully lessening their use on the broader web. Guarding on ENABLE(DASHBOARD_SUPPORT) will make it so that these names will be available in Safari on Mac, in every Mac application that uses WebKit, but not in Safari on Windows or iOS, and not in other WebKit based browsers such as Chrome. I don't think that this level of fragmentation is good. We normally guard Dashboard-only quirks with settings-usesDashboardBackwardCompatibilityMode(). I attempted to implement this approach in https://bugs.webkit.org/attachment.cgi?id=136093action=prettypatch, but I ran into a problem because cssPropertyID is a free function. Requiring all the callers to pass in a Settings object seems undesirable. Note: there are already a number of uses of ENABLE(DASHBOARD_SUPPORT) in CSSParser.cpp, and none of them check usesDashboardBackwardCompatibilityMode(). I don't think you need to do that. Looking at your latest work-in-progress patch, it's probably sufficient to add a guard in CSSParser.cpp. It's okay to have those free functions (in fact we DO need them) when ENABLE(DASHBOARD_SUPPORT) is true and usesDashboardBackwardCompatibilityMode() is false since they will never be called if the parser rejects values. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Following up on removing -khtml- and -apple- CSS vendor prefixes
On Thu, May 3, 2012 at 7:57 PM, Ryosuke Niwa rn...@webkit.org wrote: Resent from the right email address. -- Forwarded message -- From: Ryosuke Niwa rn...@berkeley.edu Date: Thu, May 3, 2012 at 7:49 PM Subject: Re: [webkit-dev] Following up on removing -khtml- and -apple- CSS vendor prefixes To: Adam Barth aba...@webkit.org Cc: Alexey Proskuryakov a...@webkit.org, webkit-dev@lists.webkit.org On Fri, Apr 6, 2012 at 4:27 PM, Adam Barth aba...@webkit.org wrote: 2012/4/5 Alexey Proskuryakov a...@webkit.org: 05.04.2012, в 01:08, Adam Barth написал(а): Based on this information, I've posted a patch that limits the -apple- and -khtml- vendor prefixes to ENABLE(DASHBOARD_SUPPORT): https://bugs.webkit.org/show_bug.cgi?id=83256 This approach lets ports that wish to remain compatible with Dashboard widgets continue to support these prefixes while also letting ports that aren't constrained by dashboard widgets disable them, hopefully lessening their use on the broader web. Guarding on ENABLE(DASHBOARD_SUPPORT) will make it so that these names will be available in Safari on Mac, in every Mac application that uses WebKit, but not in Safari on Windows or iOS, and not in other WebKit based browsers such as Chrome. I don't think that this level of fragmentation is good. We normally guard Dashboard-only quirks with settings-usesDashboardBackwardCompatibilityMode(). I attempted to implement this approach in https://bugs.webkit.org/attachment.cgi?id=136093action=prettypatch, but I ran into a problem because cssPropertyID is a free function. Requiring all the callers to pass in a Settings object seems undesirable. Note: there are already a number of uses of ENABLE(DASHBOARD_SUPPORT) in CSSParser.cpp, and none of them check usesDashboardBackwardCompatibilityMode(). I don't think you need to do that. Looking at your latest work-in-progress patch, it's probably sufficient to add a guard in CSSParser.cpp. It's okay to have those free functions (in fact we DO need them) when ENABLE(DASHBOARD_SUPPORT) is true and usesDashboardBackwardCompatibilityMode() is false since they will never be called if the parser rejects values. Ok. I'll update the patch. Thanks! Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Following up on removing -khtml- and -apple- CSS vendor prefixes
By the way, can we add a test for this? For example, we should make sure document.body.style.khtmlTransform and document.body.style.appleTransform are undefined on ports that do not enable legacy prefixes. In fact, shouldn't we be able to override the value of usesDashboardBackwardCompatibilityMode in DRT somehow? - Ryosuke On Thu, May 3, 2012 at 8:01 PM, Adam Barth aba...@webkit.org wrote: On Thu, May 3, 2012 at 7:57 PM, Ryosuke Niwa rn...@webkit.org wrote: Resent from the right email address. -- Forwarded message -- From: Ryosuke Niwa rn...@berkeley.edu Date: Thu, May 3, 2012 at 7:49 PM Subject: Re: [webkit-dev] Following up on removing -khtml- and -apple- CSS vendor prefixes To: Adam Barth aba...@webkit.org Cc: Alexey Proskuryakov a...@webkit.org, webkit-dev@lists.webkit.org On Fri, Apr 6, 2012 at 4:27 PM, Adam Barth aba...@webkit.org wrote: 2012/4/5 Alexey Proskuryakov a...@webkit.org: 05.04.2012, в 01:08, Adam Barth написал(а): Based on this information, I've posted a patch that limits the -apple- and -khtml- vendor prefixes to ENABLE(DASHBOARD_SUPPORT): https://bugs.webkit.org/show_bug.cgi?id=83256 This approach lets ports that wish to remain compatible with Dashboard widgets continue to support these prefixes while also letting ports that aren't constrained by dashboard widgets disable them, hopefully lessening their use on the broader web. Guarding on ENABLE(DASHBOARD_SUPPORT) will make it so that these names will be available in Safari on Mac, in every Mac application that uses WebKit, but not in Safari on Windows or iOS, and not in other WebKit based browsers such as Chrome. I don't think that this level of fragmentation is good. We normally guard Dashboard-only quirks with settings-usesDashboardBackwardCompatibilityMode(). I attempted to implement this approach in https://bugs.webkit.org/attachment.cgi?id=136093action=prettypatch, but I ran into a problem because cssPropertyID is a free function. Requiring all the callers to pass in a Settings object seems undesirable. Note: there are already a number of uses of ENABLE(DASHBOARD_SUPPORT) in CSSParser.cpp, and none of them check usesDashboardBackwardCompatibilityMode(). I don't think you need to do that. Looking at your latest work-in-progress patch, it's probably sufficient to add a guard in CSSParser.cpp. It's okay to have those free functions (in fact we DO need them) when ENABLE(DASHBOARD_SUPPORT) is true and usesDashboardBackwardCompatibilityMode() is false since they will never be called if the parser rejects values. Ok. I'll update the patch. Thanks! Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Following up on removing -khtml- and -apple- CSS vendor prefixes
2012/4/5 Alexey Proskuryakov a...@webkit.org: 05.04.2012, в 01:08, Adam Barth написал(а): Based on this information, I've posted a patch that limits the -apple- and -khtml- vendor prefixes to ENABLE(DASHBOARD_SUPPORT): https://bugs.webkit.org/show_bug.cgi?id=83256 This approach lets ports that wish to remain compatible with Dashboard widgets continue to support these prefixes while also letting ports that aren't constrained by dashboard widgets disable them, hopefully lessening their use on the broader web. Guarding on ENABLE(DASHBOARD_SUPPORT) will make it so that these names will be available in Safari on Mac, in every Mac application that uses WebKit, but not in Safari on Windows or iOS, and not in other WebKit based browsers such as Chrome. I don't think that this level of fragmentation is good. We normally guard Dashboard-only quirks with settings-usesDashboardBackwardCompatibilityMode(). I attempted to implement this approach in https://bugs.webkit.org/attachment.cgi?id=136093action=prettypatch, but I ran into a problem because cssPropertyID is a free function. Requiring all the callers to pass in a Settings object seems undesirable. Note: there are already a number of uses of ENABLE(DASHBOARD_SUPPORT) in CSSParser.cpp, and none of them check usesDashboardBackwardCompatibilityMode(). My current plan is to introduce a new ENABLE macro that ports can set as they desire. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Following up on removing -khtml- and -apple- CSS vendor prefixes
In July 2010, there was a thread on webkit-dev about removing support for the -khtml- and -apple- vendor prefixes: https://lists.webkit.org/pipermail/webkit-dev/2010-July/013519.html At the time, we tried an approach recommended by David Hyatt https://lists.webkit.org/pipermail/webkit-dev/2010-July/013536.html, but that approach appears to have been too agressive in that it broke a number of Dashboard widgets: https://bugs.webkit.org/show_bug.cgi?id=42093#c29 Based on this information, I've posted a patch that limits the -apple- and -khtml- vendor prefixes to ENABLE(DASHBOARD_SUPPORT): https://bugs.webkit.org/show_bug.cgi?id=83256 This approach lets ports that wish to remain compatible with Dashboard widgets continue to support these prefixes while also letting ports that aren't constrained by dashboard widgets disable them, hopefully lessening their use on the broader web. I welcome any thoughts the list has on this topic. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Following up on removing -khtml- and -apple- CSS vendor prefixes
On Thu, Apr 5, 2012 at 1:08 AM, Adam Barth aba...@webkit.org wrote: In July 2010, there was a thread on webkit-dev about removing support for the -khtml- and -apple- vendor prefixes: https://lists.webkit.org/pipermail/webkit-dev/2010-July/013519.html At the time, we tried an approach recommended by David Hyatt https://lists.webkit.org/pipermail/webkit-dev/2010-July/013536.html, but that approach appears to have been too agressive in that it broke a number of Dashboard widgets: https://bugs.webkit.org/show_bug.cgi?id=42093#c29 Based on this information, I've posted a patch that limits the -apple- and -khtml- vendor prefixes to ENABLE(DASHBOARD_SUPPORT): https://bugs.webkit.org/show_bug.cgi?id=83256 This approach lets ports that wish to remain compatible with Dashboard widgets continue to support these prefixes while also letting ports that aren't constrained by dashboard widgets disable them, hopefully lessening their use on the broader web. That sounds like a nice middle ground. It's unfortunate that we have to fragment the WebKit behavior like that but exposing those two prefixes on the Web seems more harmful. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Following up on removing -khtml- and -apple- CSS vendor prefixes
On Thursday 05 April 2012, Adam Barth wrote: In July 2010, there was a thread on webkit-dev about removing support for the -khtml- and -apple- vendor prefixes: https://lists.webkit.org/pipermail/webkit-dev/2010-July/013519.html At the time, we tried an approach recommended by David Hyatt https://lists.webkit.org/pipermail/webkit-dev/2010-July/013536.html, but that approach appears to have been too agressive in that it broke a number of Dashboard widgets: https://bugs.webkit.org/show_bug.cgi?id=42093#c29 Based on this information, I've posted a patch that limits the -apple- and -khtml- vendor prefixes to ENABLE(DASHBOARD_SUPPORT): https://bugs.webkit.org/show_bug.cgi?id=83256 This approach lets ports that wish to remain compatible with Dashboard widgets continue to support these prefixes while also letting ports that aren't constrained by dashboard widgets disable them, hopefully lessening their use on the broader web. I welcome any thoughts the list has on this topic. I the way they currently work I am in favor of removing them as well. Though I think they optimally should still be available for features that were historically prefexed with those prefixes, but only those. `Allan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Following up on removing -khtml- and -apple- CSS vendor prefixes
05.04.2012, в 01:08, Adam Barth написал(а): Based on this information, I've posted a patch that limits the -apple- and -khtml- vendor prefixes to ENABLE(DASHBOARD_SUPPORT): https://bugs.webkit.org/show_bug.cgi?id=83256 This approach lets ports that wish to remain compatible with Dashboard widgets continue to support these prefixes while also letting ports that aren't constrained by dashboard widgets disable them, hopefully lessening their use on the broader web. Guarding on ENABLE(DASHBOARD_SUPPORT) will make it so that these names will be available in Safari on Mac, in every Mac application that uses WebKit, but not in Safari on Windows or iOS, and not in other WebKit based browsers such as Chrome. I don't think that this level of fragmentation is good. We normally guard Dashboard-only quirks with settings-usesDashboardBackwardCompatibilityMode(). Due to high potential of site breakage, this seems worth a separate setting with pre-made plumbing for site-specific quirks, so that ports seeing release blocking regressions on important sites wouldn't have to undo this change entirely. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Following up on removing -khtml- and -apple- CSS vendor prefixes
On Thu, Apr 5, 2012 at 1:08 AM, Adam Barth aba...@webkit.org wrote: In July 2010, there was a thread on webkit-dev about removing support for the -khtml- and -apple- vendor prefixes: As a first step toward deprecation, it would be nice if browsers could issue a warning in the console when such property prefix are used. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Following up on removing -khtml- and -apple- CSS vendor prefixes
One option is to start evaluating the compat implications by disabling the prefixes in Chrome. If we have a positive experience we can disable them in more ports/configurations over time, hopefully arriving where you suggest while avoiding the stress of release blocking bugs. Adam On Apr 5, 2012 10:14 AM, Alexey Proskuryakov a...@webkit.org wrote: 05.04.2012, в 01:08, Adam Barth написал(а): Based on this information, I've posted a patch that limits the -apple- and -khtml- vendor prefixes to ENABLE(DASHBOARD_SUPPORT): https://bugs.webkit.org/show_bug.cgi?id=83256 This approach lets ports that wish to remain compatible with Dashboard widgets continue to support these prefixes while also letting ports that aren't constrained by dashboard widgets disable them, hopefully lessening their use on the broader web. Guarding on ENABLE(DASHBOARD_SUPPORT) will make it so that these names will be available in Safari on Mac, in every Mac application that uses WebKit, but not in Safari on Windows or iOS, and not in other WebKit based browsers such as Chrome. I don't think that this level of fragmentation is good. We normally guard Dashboard-only quirks with settings-usesDashboardBackwardCompatibilityMode(). Due to high potential of site breakage, this seems worth a separate setting with pre-made plumbing for site-specific quirks, so that ports seeing release blocking regressions on important sites wouldn't have to undo this change entirely. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Following up on removing -khtml- and -apple- CSS vendor prefixes
One option is to start evaluating the compat implications by disabling the prefixes in Chrome. If we have a positive experience we can disable them in more ports/configurations over time, hopefully arriving where you suggest while avoiding the stress of rel On Apr 5, 2012 10:14 AM, Alexey Proskuryakov a...@webkit.org wrote: 05.04.2012, в 01:08, Adam Barth написал(а): Based on this information, I've posted a patch that limits the -apple- and -khtml- vendor prefixes to ENABLE(DASHBOARD_SUPPORT): https://bugs.webkit.org/show_bug.cgi?id=83256 This approach lets ports that wish to remain compatible with Dashboard widgets continue to support these prefixes while also letting ports that aren't constrained by dashboard widgets disable them, hopefully lessening their use on the broader web. Guarding on ENABLE(DASHBOARD_SUPPORT) will make it so that these names will be available in Safari on Mac, in every Mac application that uses WebKit, but not in Safari on Windows or iOS, and not in other WebKit based browsers such as Chrome. I don't think that this level of fragmentation is good. We normally guard Dashboard-only quirks with settings-usesDashboardBackwardCompatibilityMode(). Due to high potential of site breakage, this seems worth a separate setting with pre-made plumbing for site-specific quirks, so that ports seeing release blocking regressions on important sites wouldn't have to undo this change entirely. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Following up on removing -khtml- and -apple- CSS vendor prefixes
(Previous email got cut off) ...release blocking bugs. On Apr 5, 2012 2:25 PM, Adam Barth aba...@webkit.org wrote: One option is to start evaluating the compat implications by disabling the prefixes in Chrome. If we have a positive experience we can disable them in more ports/configurations over time, hopefully arriving where you suggest while avoiding the stress of rel On Apr 5, 2012 10:14 AM, Alexey Proskuryakov a...@webkit.org wrote: 05.04.2012, в 01:08, Adam Barth написал(а): Based on this information, I've posted a patch that limits the -apple- and -khtml- vendor prefixes to ENABLE(DASHBOARD_SUPPORT): https://bugs.webkit.org/show_bug.cgi?id=83256 This approach lets ports that wish to remain compatible with Dashboard widgets continue to support these prefixes while also letting ports that aren't constrained by dashboard widgets disable them, hopefully lessening their use on the broader web. Guarding on ENABLE(DASHBOARD_SUPPORT) will make it so that these names will be available in Safari on Mac, in every Mac application that uses WebKit, but not in Safari on Windows or iOS, and not in other WebKit based browsers such as Chrome. I don't think that this level of fragmentation is good. We normally guard Dashboard-only quirks with settings-usesDashboardBackwardCompatibilityMode(). Due to high potential of site breakage, this seems worth a separate setting with pre-made plumbing for site-specific quirks, so that ports seeing release blocking regressions on important sites wouldn't have to undo this change entirely. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
