Re: Revert request r7023

On 3/13/12 7:16 PM, Cameron McCormack wrote:
> Charles Pritchard:
>> 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 issue here is actually WebGL. I'd love to get a discussion going on 
this and I'm absolutely behind a great "Path" object. But if the 
semantics of graphics hardware and APIs are not taken into account, 
we're selling ourselves short.

I'm not OK simply merging SVGPath and CanvasPath without addressing WebGL.

Even with a merger, we can let Canvas support the new path API with one 
method addition and one reference, instead of bloating up the spec 
semantically and otherwise.

I do want a win here, but it's not easy work.

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

Well, I'm still looking for replicate in SVG2, so I don't have to use 
Canvas to do Ink.
The thing is, Replicate has the features we want along a path, as authors.

It's not in SVG2, nor is it in this proposal. This proposal is more like 
the "marker" feature of SVG2, so we can drape shapes onto a path. It's 
an ok feature, but it's really not needed, it's a higher level feature 
and it doesn't add much. It also adds the "use" feature, so we can do 
Sierpinski carpets. And while it'd be neat to have the carpets match the 
drapes in Canvas, those features are far from critical. And us canvas 
authors already know how to follow a path. It's a low level API, we do 
it all the time.

Again though, these kind of features do make sense for an advanced high 
level API which can straddle various techniques as well as hardware and 
software. They make little sense in the simple Canvas 2D API that's 
headed through Last Call.

Thing that burns me is that we have higher priorities. They've been 
voiced. Instead they're being backed up being this one.

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

Tab stated that we ought to presume the author has made the correct 
choice here. I disagreed, stating that there is a credibility issue with 
the author. As an editor, he's not soliciting feedback nor taking 
existing proposals. He's acting as an author. He asked that we defer to 
the authority/credibility of the author-editor, I stated that the 
author-editor has a lack of credibility due to a lack of experience.

I want that to be in context. Tab opened the door, your Honor. [Law and 
order reference about the credibility of a witness].

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

He's setting himself up to be editing the Path object API, not sending 
it to the SVG WG for review. As part of his editing, the SVG WG would 
not have authority beyond appealing to the chairs. The SVG could 
certainly fork "Path", but they'd probably have to name it "SVGPath" as 
the "Path" global would already be taken, by his spec.

I'm happy for him to propose a Path object API too. I don't want it 
mashed onto Canvas 2D; it could work gracefully, instead. I want to see 
it go up for discussion, with SVG, Canvas and GL experts. And I'd like 
to see it edited outside of the HTML spec.

-Charles

Received on Wednesday, 14 March 2012 02:36:59 UTC