W3C home > Mailing lists > Public > public-html@w3.org > March 2012

Re: Revert request r7023

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 13 Mar 2012 18:28:21 -0700
Message-ID: <CAAWBYDCqbQDDV8c2s9OsjFVefeJG569Ym0fRGH=HEtjco8xsgw@mail.gmail.com>
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

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.)

Received on Wednesday, 14 March 2012 01:29:10 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:50 UTC