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

Re: Revert request r7023

From: Charles Pritchard <chuck@jumis.com>
Date: Tue, 13 Mar 2012 18:54:20 -0700
Message-ID: <4F5FFA4C.6070000@jumis.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: HTML WG <public-html@w3.org>
On 3/13/12 6:28 PM, Tab Atkins Jr. wrote:
> On Tue, Mar 13, 2012 at 6:16 PM, Charles Pritchard<chuck@jumis.com>  wrote:
>> 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.

Presumably, the author of the spec would have more experience 
implementing and using it. But, he doesn't. So he's doing the best he 
can. Presumably the editor would solicit authoring materials and/or 
solutions from experts and act as an editor. But, he doesn't. So he's 
doing the best he can.

There's nothing in the Path object that's unique or restricted to the 
Canvas 2D API. It makes a lot of sense for SVG to have a short and easy 
path building API. And that's likely the intention behind the "Path" 
API. Note the lack of prefix. Items from Canvas usually have "Canvas" 
prefixed to their names. Take a look at that Path API, it'd fit just 
fine in SVG.

In fact, it's already included in the SVG2 Wiki:
http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM#Specific_Commands_for_Paths


The path method extends painting and stroking subpaths along a path. And 
while that's a noble goal, it creates a lot of work on implementers and 
it's not flexibly defined. We'd have a better chance as authors by using 
SVG and drawImage onto our Canvas. It's a half-solution to a rarely 
brought up issue; that Canvas paths are not "programmable".

That's the only place it diverges from CanvasPath... That, and it is not 
an opaque immutable object. CanvasPath is opaque and immutable to allow 
for optimization in implementation.

We can't simply presume that the editor has worked with existing 3D and 
2D software and hardware solutions. One person can only cover so much 
ground in their limited time on this earth.

So I'm challenging those presumptions. And I'm challenging his attempt 
to drag SVG2 into his control.

It does seem that this is an early step to bring the belongings of SVG2 
into the HTML living draft, instead of keeping good fences. The W3C may 
be alright with that, but I'm concerned.


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

That's also been called the "piecemeal approach". And I'd be fine with 
it, if it were exactly what you're describing. This one is not a 
smallish patch. The iterations on minor details is what we've been 
working on; but they're being pushed aside as "piecemeal". And prior 
names, structures and agreed methods are changed regardless of group 
consensus or W3C chair decisions. That's why I see this as an issue of 
instability.

I'm quite happy to see surgical alterations to the spec. I've been 
trying for well over a year to get very small, basic changes that would 
address issues.

The spec editor has requested that "solutions" not be provided. He only 
wants "use cases", and he will find the solutions.

And that's cool, except he has limited time and skills. So I watch him 
repeat the same mistakes I worked through when I was finding the 
solutions... And it's painful to see. Only because of his position and 
the way he authors his document. Otherwise it'd be fine. He does not 
work with experts. He listens, sometimes, and does what he understands 
the best he can.


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

I'm clueless [I have no clue] as well.

-Charles
Received on Wednesday, 14 March 2012 01:54:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:47 GMT