Re: [webkit-dev] Removing the prefix from webkitPostMessage
On Sep 12, 2012, at 10:36 PM, Ojan Vafai o...@chromium.org wrote: On Wed, Sep 12, 2012 at 6:40 PM, Maciej Stachowiak m...@apple.com wrote: - Is this approach substantially less time and effort than adding a histogram-style metric? I expect you have added a histogram to Chrome at some point, and so can comment on the relative difficulty and time to produce an answer. (BTW we have the capability to do this type of thing in Safari as well, and it is what I ask Apple engineers to do when they want to remove a feature, even a purely Mac-specific one.) FWIW, histograms can only tell you a percentile. We never report back URLs due to privacy concerns. So, it's somewhat underpowered compared to experimentally removing a feature and seeing what sites break. I'm not saying that's not a useful signal, just clarifying what data is possible for Chromium to gather in the wild. That's about what the equivalent Safari mechanism does too. What it can tell you is stuff like feature x is used very little by sites users actually visit without risk of breakage. But if there is significant use, it won't tell you what sites it is on or whether it's critical. Cheers, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Removing the prefix from webkitPostMessage
On Wed, Sep 12, 2012 at 11:00 PM, Maciej Stachowiak m...@apple.com wrote: On Sep 12, 2012, at 10:36 PM, Ojan Vafai o...@chromium.org wrote: On Wed, Sep 12, 2012 at 6:40 PM, Maciej Stachowiak m...@apple.com wrote: - Is this approach substantially less time and effort than adding a histogram-style metric? I expect you have added a histogram to Chrome at some point, and so can comment on the relative difficulty and time to produce an answer. (BTW we have the capability to do this type of thing in Safari as well, and it is what I ask Apple engineers to do when they want to remove a feature, even a purely Mac-specific one.) FWIW, histograms can only tell you a percentile. We never report back URLs due to privacy concerns. So, it's somewhat underpowered compared to experimentally removing a feature and seeing what sites break. I'm not saying that's not a useful signal, just clarifying what data is possible for Chromium to gather in the wild. That's about what the equivalent Safari mechanism does too. What it can tell you is stuff like feature x is used very little by sites users actually visit without risk of breakage. But if there is significant use, it won't tell you what sites it is on or whether it's critical. Technically we can build histograms that either give you a percentage of sites or a percentage of page views without compromising privacy overly. The combination of the two is a pretty good approximation of importance. It would be interesting to build a generic mechanism for monitoring prefixed APIs ... I wonder how hard that would be. -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Removing the prefix from webkitPostMessage
On Thu, Sep 13, 2012 at 12:06 PM, Dirk Pranke dpra...@chromium.org wrote: On Wed, Sep 12, 2012 at 11:00 PM, Maciej Stachowiak m...@apple.com wrote: On Sep 12, 2012, at 10:36 PM, Ojan Vafai o...@chromium.org wrote: On Wed, Sep 12, 2012 at 6:40 PM, Maciej Stachowiak m...@apple.com wrote: - Is this approach substantially less time and effort than adding a histogram-style metric? I expect you have added a histogram to Chrome at some point, and so can comment on the relative difficulty and time to produce an answer. (BTW we have the capability to do this type of thing in Safari as well, and it is what I ask Apple engineers to do when they want to remove a feature, even a purely Mac-specific one.) FWIW, histograms can only tell you a percentile. We never report back URLs due to privacy concerns. So, it's somewhat underpowered compared to experimentally removing a feature and seeing what sites break. I'm not saying that's not a useful signal, just clarifying what data is possible for Chromium to gather in the wild. That's about what the equivalent Safari mechanism does too. What it can tell you is stuff like feature x is used very little by sites users actually visit without risk of breakage. But if there is significant use, it won't tell you what sites it is on or whether it's critical. Technically we can build histograms that either give you a percentage of sites or a percentage of page views without compromising privacy overly. The combination of the two is a pretty good approximation of importance. It would be interesting to build a generic mechanism for monitoring prefixed APIs ... I wonder how hard that would be. FWIW, Tab has adding roughly this for prefixed CSS properties. Not sure what the status of that is, but the code has been committed AFAIK. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Removing the prefix from webkitPostMessage
I've posted a patch to delete webkitPostMessage in favor of the identically behaving, unprefixed postMessage: https://bugs.webkit.org/show_bug.cgi?id=96577 We've discussed this topic previously in http://lists.webkit.org/pipermail/webkit-dev/2012-April/020237.html. In that thread, I was asked to follow the instructions in https://trac.webkit.org/wiki/DeprecatingFeatures, but those instructions are too hard. I'm not aware of any vendor prefixes that have actually been removed using that process. In order to act in good faith as a browser rendering engine, we need to be able to delete prefixed versions of APIs. As far as I can tell, it's time to delete the webkitPostMessage API in favor of the identically behaving postMessage API. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Removing the prefix from webkitPostMessage
On Sep 12, 2012, at 5:10 PM, Adam Barth aba...@webkit.org wrote: I've posted a patch to delete webkitPostMessage in favor of the identically behaving, unprefixed postMessage: https://bugs.webkit.org/show_bug.cgi?id=96577 We've discussed this topic previously in http://lists.webkit.org/pipermail/webkit-dev/2012-April/020237.html. In that thread, I was asked to follow the instructions in https://trac.webkit.org/wiki/DeprecatingFeatures, but those instructions are too hard. Really? I thought it was pretty easy for Chrome to gather usage statistics in the wild (either by instrumenting the browser or any other means) using what people call the histogram mechanism. Is it now a lot harder? Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Removing the prefix from webkitPostMessage
On Wed, Sep 12, 2012 at 5:34 PM, Maciej Stachowiak m...@apple.com wrote: On Sep 12, 2012, at 5:10 PM, Adam Barth aba...@webkit.org wrote: I've posted a patch to delete webkitPostMessage in favor of the identically behaving, unprefixed postMessage: https://bugs.webkit.org/show_bug.cgi?id=96577 We've discussed this topic previously in http://lists.webkit.org/pipermail/webkit-dev/2012-April/020237.html. In that thread, I was asked to follow the instructions in https://trac.webkit.org/wiki/DeprecatingFeatures, but those instructions are too hard. Really? I thought it was pretty easy for Chrome to gather usage statistics in the wild (either by instrumenting the browser or any other means) using what people call the histogram mechanism. Is it now a lot harder? My evidence for it being too hard is that no one has actually been able to use that process to delete any prefixes. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Removing the prefix from webkitPostMessage
On Sep 12, 2012, at 5:51 PM, Adam Barth aba...@webkit.org wrote: On Wed, Sep 12, 2012 at 5:34 PM, Maciej Stachowiak m...@apple.com wrote: On Sep 12, 2012, at 5:10 PM, Adam Barth aba...@webkit.org wrote: I've posted a patch to delete webkitPostMessage in favor of the identically behaving, unprefixed postMessage: https://bugs.webkit.org/show_bug.cgi?id=96577 We've discussed this topic previously in http://lists.webkit.org/pipermail/webkit-dev/2012-April/020237.html. In that thread, I was asked to follow the instructions in https://trac.webkit.org/wiki/DeprecatingFeatures, but those instructions are too hard. Really? I thought it was pretty easy for Chrome to gather usage statistics in the wild (either by instrumenting the browser or any other means) using what people call the histogram mechanism. Is it now a lot harder? My evidence for it being too hard is that no one has actually been able to use that process to delete any prefixes. I've never seen anyone post usage data for a prefixed feature, nor report trying to do so and failing. Taking the inside view, do you believe gathering the suggested data would be too hard? It would be a better argument for changing the process if someone tried and failed, or tried and reported it being too much effort. Alternate hypotheses for no one even trying to gather the data: no one has been sufficiently motivated to remove a prefixed feature to do even a modest amount of research. It sounds like you are highly motivated since you believe it is a matter of good faith as a browser engine. Are you willing to be the guinea pig for the process? A bunch of WebKit hackers (not including me incidentally) proposed it at the last WebKit Contributor's meeting, it would be a shame if we discarded it without anyone even trying it. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Removing the prefix from webkitPostMessage
On Wed, Sep 12, 2012 at 6:03 PM, Maciej Stachowiak m...@apple.com wrote: On Sep 12, 2012, at 5:51 PM, Adam Barth aba...@webkit.org wrote: On Wed, Sep 12, 2012 at 5:34 PM, Maciej Stachowiak m...@apple.com wrote: On Sep 12, 2012, at 5:10 PM, Adam Barth aba...@webkit.org wrote: I've posted a patch to delete webkitPostMessage in favor of the identically behaving, unprefixed postMessage: https://bugs.webkit.org/show_bug.cgi?id=96577 We've discussed this topic previously in http://lists.webkit.org/pipermail/webkit-dev/2012-April/020237.html. In that thread, I was asked to follow the instructions in https://trac.webkit.org/wiki/DeprecatingFeatures, but those instructions are too hard. Really? I thought it was pretty easy for Chrome to gather usage statistics in the wild (either by instrumenting the browser or any other means) using what people call the histogram mechanism. Is it now a lot harder? My evidence for it being too hard is that no one has actually been able to use that process to delete any prefixes. I've never seen anyone post usage data for a prefixed feature, nor report trying to do so and failing. Taking the inside view, do you believe gathering the suggested data would be too hard? It would be a better argument for changing the process if someone tried and failed, or tried and reported it being too much effort. Alternate hypotheses for no one even trying to gather the data: no one has been sufficiently motivated to remove a prefixed feature to do even a modest amount of research. It sounds like you are highly motivated since you believe it is a matter of good faith as a browser engine. Are you willing to be the guinea pig for the process? A bunch of WebKit hackers (not including me incidentally) proposed it at the last WebKit Contributor's meeting, it would be a shame if we discarded it without anyone even trying it. I don't think we should adopt policies without some evidence that they work. I'm glad that we had a discussion about this topic at the contributor's meeting, and I'm also glad that we tried out https://trac.webkit.org/wiki/DeprecatingFeatures, but my view is that the experiment has been a failure because we have not succeeded in removing any vendor prefixes. As an alternative, I suggest we experiment with different approaches to removing vendor prefix, learn what works and what doesn't work, and then revisit whether we need a policy once we have more experience. For example, I just sent a message to webkit-dev describing my experience removing the -khtml- and -apple- prefixes from all CSS properties. In that work, we used an ENABLE macro to make it easy to toggle the prefixes on and off. I'd be happy to add an ENABLE macro in https://bugs.webkit.org/show_bug.cgi?id=96577 so that we can start by deleting the prefix in one port, learn from the experience, and then decide whether to delete the prefix in the rest of the ports. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Removing the prefix from webkitPostMessage
On Sep 12, 2012, at 6:17 PM, Adam Barth aba...@webkit.org wrote: I don't think we should adopt policies without some evidence that they work. I'm glad that we had a discussion about this topic at the contributor's meeting, and I'm also glad that we tried out https://trac.webkit.org/wiki/DeprecatingFeatures, but my view is that the experiment has been a failure because we have not succeeded in removing any vendor prefixes. As an alternative, I suggest we experiment with different approaches to removing vendor prefix, learn what works and what doesn't work, and then revisit whether we need a policy once we have more experience. For example, I just sent a message to webkit-dev describing my experience removing the -khtml- and -apple- prefixes from all CSS properties. In that work, we used an ENABLE macro to make it easy to toggle the prefixes on and off. I'd be happy to add an ENABLE macro in https://bugs.webkit.org/show_bug.cgi?id=96577 so that we can start by deleting the prefix in one port, learn from the experience, and then decide whether to delete the prefix in the rest of the ports. That seems like a reasonable approach to gathering usage data indirectly, so I'd say that type of information satisfies the policy as written. If you wanted to take that type of approach to other prefixed features, I doubt I would object in most cases. As I understand the policy, it's just asking for a reasonable effort to gather data relative to what we know about the feature. Perhaps you and other readers of the policy see it as demanding an unreasonable level of work, but I don't think it does. To determine which approach our policy should recommend as preferred for future cases, here are some quick questions about this approach vs. histogram-style data: - Has that approach succeeded in removing any prefixes across all ports yet? - It appears that our one experience with this approach took 6 months to produce an answer. Is that what we should expect as the normal case, or is it a one-time anomaly? - Is this approach substantially less time and effort than adding a histogram-style metric? I expect you have added a histogram to Chrome at some point, and so can comment on the relative difficulty and time to produce an answer. (BTW we have the capability to do this type of thing in Safari as well, and it is what I ask Apple engineers to do when they want to remove a feature, even a purely Mac-specific one.) BTW, the following comment from the bug is useful data about usage that I would have found helpful in your unprefix request message: We don't have any hard numbers. I wasn't able to find any uses when I looked with various code search tools. As far as I can tell, its existence was only mentioned in one tutorial. It may be that in cases such as this one, that level of qualitative data gathering is sufficient. I personally find it sufficient, and I'd expect others to also find it more compelling than your initial feature request message. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Removing the prefix from webkitPostMessage
On Wed, Sep 12, 2012 at 6:40 PM, Maciej Stachowiak m...@apple.com wrote: On Sep 12, 2012, at 6:17 PM, Adam Barth aba...@webkit.org wrote: I don't think we should adopt policies without some evidence that they work. I'm glad that we had a discussion about this topic at the contributor's meeting, and I'm also glad that we tried out https://trac.webkit.org/wiki/DeprecatingFeatures, but my view is that the experiment has been a failure because we have not succeeded in removing any vendor prefixes. As an alternative, I suggest we experiment with different approaches to removing vendor prefix, learn what works and what doesn't work, and then revisit whether we need a policy once we have more experience. For example, I just sent a message to webkit-dev describing my experience removing the -khtml- and -apple- prefixes from all CSS properties. In that work, we used an ENABLE macro to make it easy to toggle the prefixes on and off. I'd be happy to add an ENABLE macro in https://bugs.webkit.org/show_bug.cgi?id=96577 so that we can start by deleting the prefix in one port, learn from the experience, and then decide whether to delete the prefix in the rest of the ports. That seems like a reasonable approach to gathering usage data indirectly, so I'd say that type of information satisfies the policy as written. If you wanted to take that type of approach to other prefixed features, I doubt I would object in most cases. As I understand the policy, it's just asking for a reasonable effort to gather data relative to what we know about the feature. Perhaps you and other readers of the policy see it as demanding an unreasonable level of work, but I don't think it does. Maybe it's just the tone of the wiki page. It speaks about arguing extensively and proofs. Maybe after this discussion I'll make an editing pass trying to tone down the language and reflect some of this discussion. To determine which approach our policy should recommend as preferred for future cases, here are some quick questions about this approach vs. histogram-style data: - Has that approach succeeded in removing any prefixes across all ports yet? - It appears that our one experience with this approach took 6 months to produce an answer. Is that what we should expect as the normal case, or is it a one-time anomaly? The typical schedule is that a change spends 6 weeks in the Dev channel and then 6 weeks in the Beta channel before reaching the Stable channel. If we break a popular web site, we'll likely find out very quickly. If we don't hear anything for 12-18 weeks, then it's very unlikely that we caused a problem. - Is this approach substantially less time and effort than adding a histogram-style metric? I expect you have added a histogram to Chrome at some point, and so can comment on the relative difficulty and time to produce an answer. (BTW we have the capability to do this type of thing in Safari as well, and it is what I ask Apple engineers to do when they want to remove a feature, even a purely Mac-specific one.) The approach is more risky (in the sense that there's a greater chance that we'll make some users sad), but it's certainly faster. To get the same coverage with the metrics-based approach, we'd need to wait the same 12-18 weeks, but then we'd still be shipping the prefixed API. We'd then need to remove the prefix and wait another 12-18 week to see if it stuck. The dream with the metrics-based approach is to proactively measure usage of all prefixed APIs so that we'd be able to see the usage immediately (i.e., without the 12-18 week release lag). Unfortunately, that approach remains a dream because we haven't built that system yet. BTW, the following comment from the bug is useful data about usage that I would have found helpful in your unprefix request message: We don't have any hard numbers. I wasn't able to find any uses when I looked with various code search tools. As far as I can tell, its existence was only mentioned in one tutorial. I thought I had mentioned that originally because I did that research before sending the original message on this topic, but I've looked in the archives and you're right that I don't appear to have mentioned it until now. I'm sorry if that omission has drawn out this discussion longer than necessary. :( It may be that in cases such as this one, that level of qualitative data gathering is sufficient. I personally find it sufficient, and I'd expect others to also find it more compelling than your initial feature request message. Thanks. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Removing the prefix from webkitPostMessage
On Wed, Sep 12, 2012 at 6:40 PM, Maciej Stachowiak m...@apple.com wrote: - Is this approach substantially less time and effort than adding a histogram-style metric? I expect you have added a histogram to Chrome at some point, and so can comment on the relative difficulty and time to produce an answer. (BTW we have the capability to do this type of thing in Safari as well, and it is what I ask Apple engineers to do when they want to remove a feature, even a purely Mac-specific one.) FWIW, histograms can only tell you a percentile. We never report back URLs due to privacy concerns. So, it's somewhat underpowered compared to experimentally removing a feature and seeing what sites break. I'm not saying that's not a useful signal, just clarifying what data is possible for Chromium to gather in the wild. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
