On Fri, Sep 21, 2012 at 5:21 PM, Maciej Stachowiak <[email protected]> wrote: > On Sep 21, 2012, at 4:30 PM, Adam Barth <[email protected]> wrote: >> On Wed, Sep 12, 2012 at 7:13 PM, Adam Barth <[email protected]> wrote: >>> On Wed, Sep 12, 2012 at 6:40 PM, Maciej Stachowiak <[email protected]> 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 _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo/webkit-dev
