- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 13 Mar 2012 18:28:21 -0700
- To: Charles Pritchard <chuck@jumis.com>
- Cc: HTML WG <public-html@w3.org>
On Tue, Mar 13, 2012 at 6:16 PM, Charles Pritchard <chuck@jumis.com> wrote: > The HTML editor recently made a wide reaching, unilateral change to the > Canvas 2D specification from its Last Call presentation. > > Note the large change in IDL between these two Working Drafts. > http://www.w3.org/TR/2dcontext/ > http://dev.w3.org/html5/2dcontext/Overview.html > http://html5.org/tools/web-apps-tracker?from=7022&to=7023 > > While I appreciate his attention to the Canvas 2D spec, I would hope that > his changes would reflect existing vendor implementations and/or group > consensus about late alterations to the Canvas 2D specification. > > I'm concerned that the change will create undo burden on implementers and > authors. A much simpler change set was proposed last year and has not been > addressed by the editor. > > It's my contention that the editor's "Path" object, as it is authored, is > not appropriate for Canvas 2D but may be appropriate for SVG2. An > alternative "CanvasPath" object, much simpler and effective, was proposed > last year. The Path object being added to the spec right now is a result of addressing many bugs asking for added canvas functionality since the last time Hixie touched that part of the spec. Presumably if the simpler CanvasPath addressed the use-cases implied by the bugs he's addressing, he would have used it. Simpler's usually better, after all. It makes little sense for SVG to define a <canvas> API. > The editor did not originate this API, and should be taking greater care to > follow its structure as part of its independent maintenence. Instead, it > seems to be suffering from a lot of instability, instability which is > harming implementation of needed features as commented on by responders of > the Last Call poll. It's not "instability" when it's just been added. It's writing the spec in smallish patches and iterating on minor details. > I'd like to see this specification working for LC, not burdened with > guesstimates as to what implementers are willing to endure on their journey > across time with the one true HTML Editor. I oppose this revert request. (I have no clue if it's possible to oppose one, or if anyone can get anything reverted unilaterally just by getting a few other people to +1 their request.) ~TJ
Received on Wednesday, 14 March 2012 01:29:10 UTC