On Apr 29, 2012, at 6:42 PM, Adam Barth <aba...@webkit.org> wrote: > On Sun, Apr 29, 2012 at 2:25 PM, Maciej Stachowiak <m...@apple.com> wrote: > > On Apr 29, 2012, at 1:35 PM, Adam Barth <aba...@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.
I think the relevant question is how much (if any) content uses webkitPostMessage (without unprefixed postMessage fallback). The fact that postMessage incorporates the new functionality doesn't answer that question. I'm willing to believe almost no one uses it, but I don't have any evidence for this proposition. The proposed deprecation process reasonably asks for some kind of evidence. I don't think "delete and see what breaks" is a good way to gather the relevant info, either in this case, or in general. I am sure there are low-cost ways to gather some concrete information about usage. Regards, Maciej
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
