[webkit-dev] webkitPostMessage

[Adam Barth]

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

>
> On Apr 29, 2012, at 1:35 PM, Adam Barth <abarth at webkit.org> wrote:
>
>
> 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).
>
>
> I think the intent of the "Deprecating a prefixed feature" section is that
> the same policy applies to removing only the prefixed version of a feature
> that exists unprefixed, as to removing a feature entirely: "Deprecating a
> prefixed feature should be treated as deprecating an existing features and
> should follow the previous steps." I don't know whether that makes sense or
> not. We can certainly come up with something different. It's almost always
> the case that the marginal maintenance burden for a prefixed feature that
> also exists in unprefixed form is very low. Does it make sense to say that,
> therefore, removal of the prefixed version should always be "argued
> extensively"?
>

Honestly, if you make people argue extensively, they're just not going to
bother.


> I do think there are some features where removing the prefixed version
> would cause lots of content to break, regardless of spec maturity or other
> implementations. So I'm not sure those can be the sole factors for removing
> a prefixed version of something. For example, it will likely be a long
> time, if ever, before we can remove support for -webkit-transform.
>

Sure, but we're not talking about -webkit-transform.  Rather than trying to
find the grand unified theory of vendor prefixing, I'm inclined to just
remove webkitPostMessage given that postMessage incorporates the new
functionality.  If we run into compat problems down the road, we can figure
out what to do then.

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