Re: [webkit-dev] Updated https://trac.webkit.org/wiki/DeprecatingFeatures (was Re: Removing the prefix from webkitPostMessage)
For now I changed the wording to remove the claim about an explicit request by the CSS WG: [[ * Standards citizenship. The CSS Working Group is considering requesting that implementors remove support for vendor prefixed featuresonce 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. ]] since that is supported by the linked reference and matches what I have heard from Apple's CSS WG reps. I also removed the reference to many W3C Working Groups since I do not know of any others with any policy about prefixing. Feel free to change back if you find data to support a stronger claim. Also perhaps the standards citizenship argument could be made without relying on what specific standards bodies explicitly ask for, but I did not want to rewrite it that much, Cheers, Maciej On Sep 21, 2012, at 6:21 PM, Adam Barth aba...@webkit.org wrote: [+Tab] On Fri, Sep 21, 2012 at 5:50 PM, Maciej Stachowiak m...@apple.com wrote: On Sep 21, 2012, at 5:34 PM, Adam Barth aba...@webkit.org wrote: On Fri, Sep 21, 2012 at 5:21 PM, Maciej Stachowiak m...@apple.com wrote: 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. ]] Looks good. I checked the reference on the request that implementors remove support for vendor prefixed features link, which points to http://wiki.csswg.org/spec/vendor-prefixes. It looks like that document does not exeactly support the claim made - it seems to contain proposed but not yet agreed upon guidance: Simple straw proposal guidance. at least some of which is explicitly marked as disputed, e.g.: * SHOULD NOT retain older, incompatible implementations with vendor-specific prefix * disputed, see also Transitions section I'm not familiar with this document, so perhaps it's out of date. But in any case, I suggest either softening the claim used to cite it to match what it says, or using a better reference. Tab, do you know what's the most up-to-date document to reference from the CSS working group about how implementors should handle vendor prefixes? Adam The impression I got is that the CSS WG is considering making a request that implementors remove support for vendor prefixed features and perhaps even is likely to, but hasn't quite done so yet. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Updated https://trac.webkit.org/wiki/DeprecatingFeatures (was Re: Removing the prefix from webkitPostMessage)
Thanks! Adam On Tue, Oct 2, 2012 at 10:18 AM, Maciej Stachowiak m...@apple.com wrote: For now I changed the wording to remove the claim about an explicit request by the CSS WG: [[ * Standards citizenship. The CSS Working Group is considering requesting that implementors remove support for vendor prefixed featuresonce 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. ]] since that is supported by the linked reference and matches what I have heard from Apple's CSS WG reps. I also removed the reference to many W3C Working Groups since I do not know of any others with any policy about prefixing. Feel free to change back if you find data to support a stronger claim. Also perhaps the standards citizenship argument could be made without relying on what specific standards bodies explicitly ask for, but I did not want to rewrite it that much, Cheers, Maciej On Sep 21, 2012, at 6:21 PM, Adam Barth aba...@webkit.org wrote: [+Tab] On Fri, Sep 21, 2012 at 5:50 PM, Maciej Stachowiak m...@apple.com wrote: On Sep 21, 2012, at 5:34 PM, Adam Barth aba...@webkit.org wrote: On Fri, Sep 21, 2012 at 5:21 PM, Maciej Stachowiak m...@apple.com wrote: 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. ]] Looks good. I checked the reference on the request that implementors remove support for vendor prefixed features link, which points to http://wiki.csswg.org/spec/vendor-prefixes. It looks like that document does not exeactly support the claim made - it seems to contain proposed but not yet agreed upon guidance: Simple straw proposal guidance. at least some of which is explicitly marked as disputed, e.g.: * SHOULD NOT retain older, incompatible implementations with vendor-specific prefix * disputed, see also Transitions section I'm not familiar with this document, so perhaps it's out of date. But in any case, I suggest either softening the claim used to cite it to match what it says, or using a better reference. Tab, do you know what's the most up-to-date document to reference from the CSS working group about how implementors should handle vendor prefixes? Adam The impression I got is that the CSS WG is considering making a request that implementors remove support for vendor prefixed features and perhaps even is likely to, but hasn't quite done so yet. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Updated https://trac.webkit.org/wiki/DeprecatingFeatures (was Re: Removing the prefix from webkitPostMessage)
On Fri, Sep 21, 2012 at 5:21 PM, Maciej Stachowiak m...@apple.com wrote: On Sep 21, 2012, at 4:30 PM, Adam Barth aba...@webkit.org wrote: On Wed, Sep 12, 2012 at 7:13 PM, Adam Barth aba...@webkit.org wrote: On Wed, Sep 12, 2012 at 6:40 PM, Maciej Stachowiak m...@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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Updated https://trac.webkit.org/wiki/DeprecatingFeatures (was Re: Removing the prefix from webkitPostMessage)
On Sep 21, 2012, at 5:34 PM, Adam Barth aba...@webkit.org wrote: On Fri, Sep 21, 2012 at 5:21 PM, Maciej Stachowiak m...@apple.com wrote: 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. ]] Looks good. I checked the reference on the request that implementors remove support for vendor prefixed features link, which points to http://wiki.csswg.org/spec/vendor-prefixes. It looks like that document does not exeactly support the claim made - it seems to contain proposed but not yet agreed upon guidance: Simple straw proposal guidance. at least some of which is explicitly marked as disputed, e.g.: * SHOULD NOT retain older, incompatible implementations with vendor-specific prefix * disputed, see also Transitions section I'm not familiar with this document, so perhaps it's out of date. But in any case, I suggest either softening the claim used to cite it to match what it says, or using a better reference. The impression I got is that the CSS WG is considering making a request that implementors remove support for vendor prefixed features and perhaps even is likely to, but hasn't quite done so yet. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Updated https://trac.webkit.org/wiki/DeprecatingFeatures (was Re: Removing the prefix from webkitPostMessage)
On Sat, Sep 22, 2012 at 7:30 AM, Adam Barth aba...@webkit.org wrote: On Wed, Sep 12, 2012 at 7:13 PM, Adam Barth aba...@webkit.org wrote: On Wed, Sep 12, 2012 at 6:40 PM, Maciej Stachowiak m...@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 some of the recent discussion we had on this mailing list. The intro para seems odd in that it starts talking about adding features, then it immediately says it is going to discuss how to remove a feature. Regarding when to unprefix, I'm not sure the CSS WG has recommended removal of prefixes upon entrance of CR. It has recommended the implementation of the unprefixed flavor (of CSS syntactic features), but it has not gone any further than saying ideally, when you implement the unprefixed version [should you drop the prefixed version]. Also, it is worth noting that these CSS WG recommendations have not necessarily been accepted, applied to, or promulgated by other W3C WGs. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Updated https://trac.webkit.org/wiki/DeprecatingFeatures (was Re: Removing the prefix from webkitPostMessage)
[+Tab] On Fri, Sep 21, 2012 at 5:50 PM, Maciej Stachowiak m...@apple.com wrote: On Sep 21, 2012, at 5:34 PM, Adam Barth aba...@webkit.org wrote: On Fri, Sep 21, 2012 at 5:21 PM, Maciej Stachowiak m...@apple.com wrote: 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. ]] Looks good. I checked the reference on the request that implementors remove support for vendor prefixed features link, which points to http://wiki.csswg.org/spec/vendor-prefixes. It looks like that document does not exeactly support the claim made - it seems to contain proposed but not yet agreed upon guidance: Simple straw proposal guidance. at least some of which is explicitly marked as disputed, e.g.: * SHOULD NOT retain older, incompatible implementations with vendor-specific prefix * disputed, see also Transitions section I'm not familiar with this document, so perhaps it's out of date. But in any case, I suggest either softening the claim used to cite it to match what it says, or using a better reference. Tab, do you know what's the most up-to-date document to reference from the CSS working group about how implementors should handle vendor prefixes? Adam The impression I got is that the CSS WG is considering making a request that implementors remove support for vendor prefixed features and perhaps even is likely to, but hasn't quite done so yet. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
