[webkit-dev] webkitPostMessage

[Adam Barth]

On Sun, Apr 29, 2012 at 1:06 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Apr 29, 2012, at 12:53 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
>
> On Sun, Apr 29, 2012 at 12:34 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>
>> On Apr 29, 2012, at 11:01 AM, Adam Barth <abarth at webkit.org> wrote:
>>
>> I read <https://trac.webkit.org/wiki/DeprecatingFeatures>, but I'm
>> still unsure how to proceed with removing webkitPostMessage and
>> aligning postMessage with the spec.  No one responded to my earlier
>> message, so I'm inclined to just post a patch.
>>
>> Comparing your post to the recommended steps on that page (the page says
>> the same steps should be applied to removing only the prefixed version of a
>> feature):
>>
>> It looks like you did this:
>>
>>    - Any deprecation should be sent to webkit-dev for discussion.
>>
>> It doesn't look like you did any of these yet:
>>
>>    - 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:
>>       - usage statistics in the wild (either by instrumenting the
>>       browser or any other means).
>>       - some discussions on the standard mailing lists underlining that
>>       the standards' bodies don't think there is enough traction to get the
>>       feature standardized.
>>       - some proof that there is others way to achieve the same result
>>       that are better.
>>
>> 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.
>
>
> 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:
>
> "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."
>
> 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).
>
> 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.
>

There is very little cost on the WebKit project to maintain
webkitPostMessage in addition to postMessage.  Instead, supporting
webkitPostMessage imposes a cost on the web platform at large by reducing
interoperability between browsers.

I'm not sure that this is a good test case for the policy.  The intent of <
https://trac.webkit.org/wiki/DeprecatingFeatures> seems to be more about
deleting features wholesale rather than simply removing vendor prefixes.
 Perhaps we should write different guidelines for removing vendor prefixes
(e.g., related to specification maturity and implementation by other
vendors).

Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120429/3caa309d/attachment-0001.html>