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

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.