Re: [svg2] Empty path data + getPointAtLenght / getPathSegAtLength

On Tue, Jun 24, 2014 at 12:56 PM, Dirk Schulze <dschulze@adobe.com> wrote:

>
> On Jun 24, 2014, at 7:41 PM, Rik Cabanier <cabanier@gmail.com> wrote:
>
> >
> >
> >
> > On Tue, Jun 24, 2014 at 8:35 AM, Erik Dahlström <ed@opera.com> wrote:
> > On Tue, 24 Jun 2014 17:14:09 +0200, Dirk Schulze <dschulze@adobe.com>
> wrote:
> >
> >
> > On Jun 24, 2014, at 3:15 PM, Erik Dahlström <ed@opera.com> wrote:
> >
> > Hi,
> >
> > what should SVGPathElement.getPointAtLength[1] and getPathSegAtLength[2]
> return if there's no path data (or if the path data has no valid segments)?
> >
> > This topic was discussed on last week's call[3], but no consensus was
> reached.
> >
> > A testcase[4] shows the following behavior:
> >
> > Firefox: gPAL throws, gPSAL returns 2**32-1.
> > Chrome/Opera: gPAL returns SVGPoint(0,0), gPSAL returns 0
> > IE11: gPAL throws, gPSAL returns 0
> > For reference, Opera 12 (Presto): gPAL returns SVGPoint(0,0), gPSAL
> returns "undefined"
> >
> > Proposals:
> >
> > 1a) gPAL should return SVGPoint(NaN, NaN)
> > 1b) gPAL should throw INVALID_ACCESS_ERR (or NOT_SUPPORTED_ERR)
> > 1c) gPAL should return SVGPoint(0,0)
> >
> > 2a) gPSAL shoud throw INVALID_ACCESS_ERR (or NOT_SUPPORTED_ERR)
> > 2b) gPSAL should return 0
> > 2c) gPSAL should return undefined
> > 2d) gPSAL should return MAX_LONG
> >
> > My preference for
> >         gPAL is 1d) returning undefined (or, if not accepted, 1a) 1c) )
> >         gPSAL is 2d) returning NaN (or, if not accepted, 2b) )
> >
> > Returning undefined where a number is expected seems strange to me.
> >
> > gPSAL returns an "unsigned long" according to the IDL, so returning NaN
> seems a bit strange.
> >
> > Maybe we can change it to unrestricted float in the IDL.
> > Otherwise, we could a new hasPathSegAtLength call.
>
> unsigned length makes sense. It is an index that gPSAL returns. What about
> a nullable type?
>
>         unsigned long? getPathSegAtLength(..)
>
> It would be interpreted as 0 but 0 !== null.
>

Is that allowed in WebIDL? It seems not (but I might be misreading it):

The return type of the operation is given by the type (matching ReturnType)
that appears before the operation’s optional identifier. A return type of
void indicates that the operation returns no value. If the return type is
an identifier or an identifier followed by ?, then the identifier must
identify an interface, dictionary, enumeration, callback function ortypedef.



> So existing implementations and future implementations wouldn’t be
> affected, but a type check would still reveal if the segment exists.
>
> I would actually suggest the same for SVGPathElement.getPointAtLength.
>

1: http://www.w3.org/TR/WebIDL/#dfn-return-type