[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
Re: [webkit-dev] Is anyone not using PREEMPT_GEOLOCATION_PERMISSION?
On Thu, Mar 29, 2012 at 3:00 PM, Benjamin Poulain benja...@webkit.org wrote: I could not find any case where PREEMPT_GEOLOCATION_PERMISSION is not used. Unless someone does not use this flag, I plan to remove the flag and the related useless code. I did not get any answer for a week. Here is the patch to clean the flag: https://bugs.webkit.org/show_bug.cgi?id=83325 Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Is anyone not using PREEMPT_GEOLOCATION_PERMISSION?
On Thu, Apr 5, 2012 at 4:35 PM, Benjamin Poulain benja...@webkit.orgwrote: On Thu, Mar 29, 2012 at 3:00 PM, Benjamin Poulain benja...@webkit.org wrote: I could not find any case where PREEMPT_GEOLOCATION_PERMISSION is not used. Unless someone does not use this flag, I plan to remove the flag and the related useless code. I did not get any answer for a week. Here is the patch to clean the flag: https://bugs.webkit.org/show_bug.cgi?id=83325 Maybe blackberry port uses it? - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Is anyone not using PREEMPT_GEOLOCATION_PERMISSION?
The BlackBerry port doesn't use that flag, we are fine with removing it. On Thu, Apr 5, 2012 at 8:34 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Apr 5, 2012 at 4:35 PM, Benjamin Poulain benja...@webkit.orgwrote: On Thu, Mar 29, 2012 at 3:00 PM, Benjamin Poulain benja...@webkit.org wrote: I could not find any case where PREEMPT_GEOLOCATION_PERMISSION is not used. Unless someone does not use this flag, I plan to remove the flag and the related useless code. I did not get any answer for a week. Here is the patch to clean the flag: https://bugs.webkit.org/show_bug.cgi?id=83325 Maybe blackberry port uses it? - Ryosuke ___ 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] Is anyone not using PREEMPT_GEOLOCATION_PERMISSION?
Okay, thanks for the clarification. Given that the blackberry was the only port that listed this flag in the list of features, I think it's okay to remove this flag. As I mentioned earlier, the flag is pretty self-contained, so if this removal causes any inconvenience, we can always revert it later. i.e. I've r+ed Benjamin's patch. - Ryosuke On Thu, Apr 5, 2012 at 8:01 PM, Jeff Rogers jeffcrog...@gmail.com wrote: The BlackBerry port doesn't use that flag, we are fine with removing it. On Thu, Apr 5, 2012 at 8:34 PM, Ryosuke Niwa rn...@webkit.org wrote: On Thu, Apr 5, 2012 at 4:35 PM, Benjamin Poulain benja...@webkit.orgwrote: On Thu, Mar 29, 2012 at 3:00 PM, Benjamin Poulain benja...@webkit.org wrote: I could not find any case where PREEMPT_GEOLOCATION_PERMISSION is not used. Unless someone does not use this flag, I plan to remove the flag and the related useless code. I did not get any answer for a week. Here is the patch to clean the flag: https://bugs.webkit.org/show_bug.cgi?id=83325 Maybe blackberry port uses it? - Ryosuke ___ 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
