Re: Revert request r7023

Charles Pritchard:
> 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.

I think I can, I think I 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.

Agreed!

> 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

Please note that many of the ideas on that page are strawman proposals. 
  The SVG WG has decided to improve the SVG DOM APIs, including for 
paths, but we have not yet decided on the way to do this.

I would very much prefer to see a single, nice-to-use Path object that 
is common to Canvas and SVG.  I don't want to see separate SVGPath and 
CanvasPath objects with similar functionality.

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

I agree this is something that is difficult, and I would not be 
surprised if implementors pushed back on this.  On the other hand, 
authors would love it.  We've discussed this functionality in the SVG WG 
before (perhaps even at the F2F you attended) but so far we have not 
resolved to include such functionality in SVG2.

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

We should criticise the proposals based on their technical problems, not 
on whether the editor has particular experience.

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

I don't see it as Ian "dragging SVG2 into his control".  On the 
contrary, I'm happy for him to propose a Path object API and for us (SVG 
WG folks) to review it.

Received on Wednesday, 14 March 2012 02:17:11 UTC