[webkit-dev] New Feature: Canvas Path object
Hi WebKit, I would like to ask if there are objections to implement the canvas Path object. The HTML Canvas specification and the WHAT WG HTML specification define the Path object [1][2]. The Path object and the CanvasRenderingContext2D share some graphics operations[3]: - closePath - lineTo - moveTo - arc - arcTo - ellipse (not implemented yet) - quadraticCurveTo - cubicCurveTo - rect But instead of drawing onto a Canvas, the operations get applied to a Path object. Furthermore the object allows adding other Paths with transforms. A Path object can then be drawn onto a Canvas. I opened https://bugs.webkit.org/show_bug.cgi?id=97333 for a patch and detailed discussions. Greetings, Dirk [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#path-objects [2] http://dev.w3.org/html5/2dcontext/#path-objects [3] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#2dcontext ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] the switchover to the new TestExpectations syntax is complete; the old syntax is no longer supported
As of http://trac.webkit.org/changeset/129265 . (There are still some things to clean up in the code now that the old syntax is gone, but hardly anyone will care about that). I am not aware of any open bugs or issues with the new syntax. Speak now or I'll assume we're all good :). Cheers, -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Skipped files are going away
Hi all, Now that we're on the new TestExpectations syntax, I'm planning to remove the Skipped files (and support for them from NRWT). I have a change posted that will add minimal support for the syntax to old-run-webkit-tests in https://bugs.webkit.org/show_bug.cgi?id=97276 ; basically any file or directory listed in a TestExpectations file will be skipped *regardless of the expectation listed*. I can make things smarter if need be, but it's not clear to me how many people if any are still using ORWT so the need doesn't seem to be there. Please comment on the bug ASAP if you disagree and would like ORWT to be smarter in this area :). Once that change lands, my plan is to copy all of the entries from the existing Skipped files over into their corresponding TestExpectations files, and then delete the Skipped files, and then delete the code that supports the Skipped files in NRWT and ORWT. I hope to do this early next week. If you have any objections, now would be a good time to speak up! Note that all of this is being done in the oft-requested name of simplifying the number of different ways we have to handle failing tests. Also, I will remind people that the new TestExpectations syntax is a superset of the old Skipped file syntax, so there shouldn't be any good reason to keep the old files around. However, if you know something I don't, please mention it :). Thanks, -- Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] Updated https://trac.webkit.org/wiki/DeprecatingFeatures (was Re: Removing the prefix from webkitPostMessage)
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. Please let me know if you have any feedback. Thanks, 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 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
