[webkit-dev] Removing the prefix from webkitPostMessage

[Adam Barth]

On Wed, Sep 12, 2012 at 6:40 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> 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.

Maybe it's just the tone of the wiki page.  It speaks about "arguing
extensively" and "proofs".  Maybe after this discussion I'll make an
editing pass trying to tone down the language and reflect some of this
discussion.

> 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?

The typical schedule is that a change spends 6 weeks in the Dev
channel and then 6 weeks in the Beta channel before reaching the
Stable channel.  If we break a popular web site, we'll likely find out
very quickly.  If we don't hear anything for 12-18 weeks, then it's
very unlikely that we caused a problem.

> - 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.)

The approach is more risky (in the sense that there's a greater chance
that we'll make some users sad), but it's certainly faster.  To get
the same coverage with the metrics-based approach, we'd need to wait
the same 12-18 weeks, but then we'd still be shipping the prefixed
API.  We'd then need to remove the prefix and wait another 12-18 week
to see if it stuck.

The dream with the metrics-based approach is to proactively measure
usage of all prefixed APIs so that we'd be able to see the usage
immediately (i.e., without the 12-18 week release lag).
Unfortunately, that approach remains a dream because we haven't built
that system yet.

> 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.

I thought I had mentioned that originally because I did that research
before sending the original message on this topic, but I've looked in
the archives and you're right that I don't appear to have mentioned it
until now.  I'm sorry if that omission has drawn out this discussion
longer than necessary.  :(

> 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.

Thanks.

Adam