[webkit-dev] Removing the prefix from webkitPostMessage

[Maciej Stachowiak]

On Sep 12, 2012, at 6:17 PM, Adam Barth <abarth at webkit.org> wrote:

> 
> I don't think we should adopt policies without some evidence that they
> work.  I'm glad that we had a discussion about this topic at the
> contributor's meeting, and I'm also glad that we tried out
> <https://trac.webkit.org/wiki/DeprecatingFeatures>, but my view is
> that the experiment has been a failure because we have not succeeded
> in removing any vendor prefixes.
> 
> As an alternative, I suggest we experiment with different approaches
> to removing vendor prefix, learn what works and what doesn't work, and
> then revisit whether we need a policy once we have more experience.
> 
> For example, I just sent a message to webkit-dev describing my
> experience removing the -khtml- and -apple- prefixes from all CSS
> properties.  In that work, we used an ENABLE macro to make it easy to
> toggle the prefixes on and off.  I'd be happy to add an ENABLE macro
> in https://bugs.webkit.org/show_bug.cgi?id=96577 so that we can start
> by deleting the prefix in one port, learn from the experience, and
> then decide whether to delete the prefix in the rest of the ports.

That seems like a reasonable approach to gathering usage data indirectly, so I'd say that type of information satisfies the policy as written. If you wanted to take that type of approach to other prefixed features, I doubt I would object in most cases. As I understand the policy, it's just asking for a reasonable effort to gather data relative to what we know about the feature. Perhaps you and other readers of the policy see it as demanding an unreasonable level of work, but I don't think it does.

To determine which approach our policy should recommend as preferred for future cases, here are some quick questions about this approach vs. histogram-style data:
- Has that approach succeeded in removing any prefixes across all ports yet? 
- It appears that our one experience with this approach took 6 months to produce an answer. Is that what we should expect as the normal case, or is it a one-time anomaly?
- Is this approach substantially less time and effort than adding a histogram-style metric? I expect you have added a histogram to Chrome at some point, and so can comment  on the relative difficulty and time to produce an answer.
  (BTW we have the capability to do this type of thing in Safari as well, and it is what I ask Apple engineers to do when they want to remove a feature, even a purely Mac-specific one.)

BTW, the following comment from the bug is useful data about usage that I would have found helpful in your unprefix request message:

> We don't have any hard numbers.  I wasn't able to find any uses when I looked with various code search tools.  As far as I can tell, its existence was only mentioned in one tutorial.

It may be that in cases such as this one, that level of qualitative data gathering is sufficient. I personally find it sufficient, and I'd expect others to also find it more compelling than your initial feature request message.

Regards,
Maciej