[whatwg] Path API feedback

[Ian Hickson]

On Wed, 18 Sep 2013, Rik Cabanier wrote:
> On Tue, Sep 17, 2013 at 10:20 AM, Ian Hickson <ian at hixie.ch> wrote:
> > On Tue, 20 Aug 2013, Rik Cabanier wrote:
> > > > On Sat, 23 Mar 2013, Rik Cabanier wrote:
> > > > >
> > > > > The current path APIs suffer from conflating path segments and 
> > > > > geometry. To fix this, I proposed to modify the API so path just 
> > > > > describe the path segments.
> > > > >
> > > > > http://blogs.adobe.com/webplatform/2013/01/31/revised-canvas-paths/
> > > >
> > > > I disagree with the premise of this post -- it's not the case that 
> > > > you never want to add segments. It is in fact quite common to add 
> > > > segments to a path -- that's what constructing a path is.
> > >
> > > I disagree. How many times does an author want to add segments to an 
> > > existing path?
> >
> > Pretty much every time they create a path with more than one segment.
> 
> Maybe I phrased that wrong. The existing path is a path that was created 
> earlier (and could have already been used to draw). It's not often that 
> you would want to append to such a path.

Right, the current API is only about building paths, not about later 
combining paths. We haven't added that feature yet. That would be covered 
by: https://www.w3.org/Bugs/Public/show_bug.cgi?id=21835


> > > Let's say an application stores a circle in a path and now want to 
> > > draw a rectangle too. You propose that the application just appends 
> > > the rectangle.
> >
> > No, not necessarily. It depends on what they want to do. If they want 
> > a single path that is constructed of a circle and a rectangle in the 
> > same way that it would be if they did:
> >
> >    x.beginPath();
> >    x.arc(...);
> >    x.rect(...);
> >    x.fill();
> >
> > ...then yeah, they should just append the rectangle. But if they want 
> > the same effect as:
> >
> >    x.beginPath();
> >    x.arc();
> >    x.fill();
> >    x.rect(...);
> >    x.fill();
> >
> > ...then they should not just append them, since as you say, it won't 
> > work.
> 
> Yes, but for hit regions, you would have to calculate the area that 
> these 2 fill operations covered. This is why we need the extra 'union' 
> API.

I don't think anyone is arguing that we don't eventually need such an API.


> > Once the Path API is implemented, we can add any number of features, 
> > such as adding a path so as to form the union of both paths, adding a 
> > path so as to form the intersection of both paths, etc.
> 
> OK. In order to make that possible, 'addPath', 'addPathByStrokingPath', 
> 'addText' and 'addTextByStrokingText' should be cut from the interface.

Why?


> > Sure, for that you need a new API function, e.g. union, which as I've 
> > mentioned before, I think would be a logical addition to the API in 
> > due course. But I don't think we should add features too quickly, lest 
> > we get too far ahead of browsers.
> 
> That sounds reasonable.
> So please remove the APIs such as AddPathByStrokingPath that rely on 
> these difficult algorithms.

I don't understand why one implies the other. Can you elaborate on your 
reasoning here?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'