<div class="gmail_quote">On Sun, Apr 29, 2012 at 1:25 PM, Ryosuke Niwa <span dir="ltr"><<a href="mailto:rniwa@webkit.org" target="_blank">rniwa@webkit.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sun, Apr 29, 2012 at 1:06 PM, Maciej Stachowiak <span dir="ltr"><<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div><br><div><div>On Apr 29, 2012, at 12:53 PM, Ryosuke Niwa <<a href="mailto:rniwa@webkit.org" target="_blank">rniwa@webkit.org</a>> wrote:</div><blockquote type="cite">
<div class="gmail_quote">On Sun, Apr 29, 2012 at 12:34 PM, Maciej Stachowiak <span dir="ltr"><<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div><div>On Apr 29, 2012, at 11:01 AM, Adam Barth <<a href="mailto:abarth@webkit.org" target="_blank">abarth@webkit.org</a>> wrote:</div><blockquote type="cite"><div>
I read <<a href="https://trac.webkit.org/wiki/DeprecatingFeatures" target="_blank">https://trac.webkit.org/wiki/DeprecatingFeatures</a>>, but I'm<br>still unsure how to proceed with removing webkitPostMessage and<br>
aligning postMessage with the spec. No one responded to my earlier<br>message, so I'm inclined to just post a patch.</div></blockquote></div></div><div>Comparing your post to the recommended steps on that page (t<span style="font-family:Verdana,Arial,'Bitstream Vera Sans',Helvetica,sans-serif;font-size:13px">he page says the same steps should be applied to removing only the prefixed version of a feature)</span>:</div>
<div><br></div><div>It looks like you did this:</div><div><ul style="font-size:13px;font-family:Verdana,Arial,'Bitstream Vera Sans',Helvetica,sans-serif"><li>Any deprecation should be sent to webkit-dev for discussion.</li>
</ul><div><font face="Verdana, Arial, Bitstream Vera Sans, Helvetica, sans-serif"><span style="font-size:13px">It doesn't look like you did any of these yet:</span></font></div><ul style="font-size:13px;font-family:Verdana,Arial,'Bitstream Vera Sans',Helvetica,sans-serif">
<li>Any deprecation requires some data as to why the feature can be deprecated. The goal of the data is to show that the feature is not widely used and is not popular. The following would qualify:</li><ul><li>usage statistics in the wild (either by instrumenting the browser or any other means).</li>
<li>some discussions on the standard mailing lists underlining that the standards' bodies don't think there is enough traction to get the feature standardized.</li><li>some proof that there is others way to achieve the same result that are better.</li>
</ul></ul></div></div></blockquote><div>It appears to me that the the unprefixed version will be a better alternative in this case since the websites can just use the same API on all spec-compliant browsers if ArrayBuffer is supported in the unprefixed version.</div>
</div></blockquote></div></div></div><div>Is there evidence that authors are either not using the prefixed version or are highly willing to migrate? I ask because another part of the policy says:</div><div><br></div><div>
</div><div><div>"The burden on the overall project needs to be evaluated as it should be the primary driver for dropping any feature. Small features that require very little maintenance may not qualify under this rule and their deprecation would need to be argued extensively."</div>
</div><div><br></div><div>This implies to me that the burden of proof is higher for lower-maintenance-cost features (which I imagine applies to a prefixed method that also exists in unprefixed form).</div><div><br></div>
<div>
I'm not necessarily saying that lots of evidence is required in this case. But we can use this instance as a test case to adjust the policy.</div></div></blockquote><div><br></div><div>I'm actually curious as to how the session participants reached this consensus (probably on a separate thread). It seems like the bar shouldn't too high for removing prefixed APIs when they are unprefixed equivalents because I'm certain web developers want to use the ones that work on all browsers instead of just on WebKit.</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div></font></span></div></blockquote><div><br></div><div>The discussion went like this:</div><div><br></div><div>It is good to remove vendor prefixed features in favor of their standardized, unprefixed forms.</div>
<div><br></div><div>However, the process for removing a vendor prefixed feature is the same as the process for removing any feature. In both cases, we care about the impact to users of WebKit-based products. The vendor prefix just provides motivation for wanting to remove a feature. It doesn't necessarily make it any easier to remove a feature.</div>
<div><br></div><div>Just as we announce feature addition on webkit-dev, I think it is a good idea to announce feature removal on webkit-dev.</div><div><br></div><div>-- If we have data to indicate that a feature is nearly unused, then removing the feature straight-away seems good. We can learn quickly if we made a mistake.</div>
<div><br></div><div>-- If we have data to indicate that a feature is somewhat used, then we can still deprecate it, but we probably need to take our time, complain in the JS console about deprecated API usage for some time, and then remove the feature from trunk and see who complains.</div>
<div><br></div><div>-- If we have data to indicate that a feature is highly used, then perhaps we are stuck with the feature. We may have some hard discussions here if someone is truly motivated to remove such a feature.</div>
<div><br></div><div>-Darin</div></div>