On Apr 29, 2012, at 1:35 PM, Adam Barth <[email protected]> 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"? 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. Regards, Maciej
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
