[webkit-dev] Updated https://trac.webkit.org/wiki/DeprecatingFeatures (was Re: Removing the prefix from webkitPostMessage)

[Adam Barth]

On Fri, Sep 21, 2012 at 5:21 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> On Sep 21, 2012, at 4:30 PM, Adam Barth <abarth at webkit.org> wrote:
>> On Wed, Sep 12, 2012 at 7:13 PM, Adam Barth <abarth at webkit.org> wrote:
>>> On Wed, Sep 12, 2012 at 6:40 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>>>> 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.
>>
>> As discussed, I've updated
>> https://trac.webkit.org/wiki/DeprecatingFeatures to be a bit more
>> friendly and to incorporate soisame of the recent discussion we had on
>> this mailing list.
>>
>> Please let me know if you have any feedback.
>
> I like it. One style note:
>
>> Measure, deprecate, and remove
>>     The most measured way to remove a feature is to quantify the compatibility costs of removing the feature by collecting usage metrics.
>
> This uses "measure" in two different senses right next to each other, which I think is a bit confusing.

Fixed.

> Two other minor comments:
>
>> Generally speaking, removing vendor prefixes is similar to remove support for a feature. However, there are two important differences:
>
> I'd suggest s/two important differences/two additional considerations/. Removing non-prefixed versions of features may sometimes give a clearer path forward if they are duplicative of other features, for instance.

Done.

>> Obligation to unprefix.
>
> I agree with the sentiment expressed in this bullet. But I disagree that we have an "obligation" to follow a Working Group's request to remove something, either in general or by virtue of participating in the Working Group. Joining a Working Group carries no obligation to add or remove support for anything; W3C, IETF, ECMA and other bodies are pretty clear on this. Maybe it's a good thing to do to listen to requests from the Working Group, but it's certainly not an obligation.
>
> I think it would be reasonable to call this "Being good standards citizens" or "Being nice to standards bodies" or something along those lines and reword the rest of the paragraph accordingly.

Yeah, "obligation" is probably too loaded a word.  Here's some updated text:

[[
* Standards citizenship. Many W3C working groups, including the CSS
working group, ​request that implementors remove support for vendor
prefixed features once the specifications of the features reach a
certain level of maturity, typically Candidate Recommendation. To be
good citizens of these standards bodies, we should make an effort to
remove vendor prefixes, even if doing so would incur a larger
compatibility cost than we would otherwise prefer.
]]

Adam