Re: Revert request r7023

On Mar 13, 2012, at 6:54 PM, Charles Pritchard wrote:

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

To be clear, is your objection to the fact that the name is "Path" instead of "CanvasPath", or other API details you disagree with? Can you cite a reference for the CanvasPath proposal? I couldn't find it through web searching.

Regards,
Maciej

Received on Wednesday, 14 March 2012 02:07:53 UTC