Re: hit testing and retained graphics

Charles Pritchard:
> That stated: Does anybody here object to the stringification methods
> I've put forward?

I think being able to get and set the current path as a string using SVG
path syntax is a fine idea, pretty useful.  As I mentioned I don’t
really see the need to wrap the string in an otherwise opaque object.

> They in no way "step on" the propriety of SVG -- they in fact enhance
> interoperability,

(Not sure how they enhance interoperability if nobody implements them
yet…)

> Cameron: I did see a minor aside from you about the arcTo command --
> I'd like to remind you that SVG normalized strings took this into
> account and it was decided that arcTo precision was not necessary; the
> curves handled by SVG normalization were deemed sufficient. If they
> are/were not sufficient, then arc would have to be included in the
> normalization spec....

I think the whole point of SVG exposing path data as either normalised
or un-normalised is that user script may find it easier not to have to
deal with both relative and absolute commands, arcs, etc.

> it has not been, I've not seen any technical reason why this decision
> should be changed.

I think for your use case, which deson’t involve author script
manipulating the path data returned from getCurrentPath, I don’t see the
need to have to normalise the path data before returning it.  All that I
was pointing out with the arcTo comment was that if you require the path
to be normalised before being returned to getCurrentPath, the script
author cannot always get back a path identical to one they built up
using the moveTo/lineTo/arcTo/etc. commands.

-- 
Cameron McCormack ≝ http://mcc.id.au/