W3C home > Mailing lists > Public > public-canvas-api@w3.org > April to June 2011

Re: hit testing and retained graphics

From: Charles Pritchard <chuck@jumis.com>
Date: Thu, 23 Jun 2011 19:58:16 -0700
Message-ID: <4E03FD48.9080802@jumis.com>
To: Frank Olivier <Frank.Olivier@microsoft.com>, Richard Schwerdtfeger <schwer@us.ibm.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, Cynthia Shelly <cyns@microsoft.com>, david.bolter@gmail.com, Mike@w3.org, public-canvas-api@w3.org, public-html@w3.org, public-html-a11y@w3.org
On 6/23/2011 7:50 PM, Cameron McCormack wrote:
> 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.
I only separated it from the opaque object to separate the two proposals;
one being a Path object, the other being a set of stringify methods for
transformations and paths.

>> 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…)
Some vendors do implement normalized strings. This enhances interop, 
even without
normalized strings, as it allows the scripting environment to create 
normalized strings
and then use them, both with canvas, and with SVG paths.

I've personally implemented SVG, and I've worked with other developer's 
implementations
of SVG which worked atop canvas. I've also worked with issues where 
method calls had
unfortunate overhead. In all cases, it's a big help to have the Canvas 
implementation
recognize normalized SVG strings. And it's relatively inexpensive to add 
to Canvas implementations.

>> 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.
And the implementation. It's a lot of extra work, and it's not really 
necessary,
as it can be handled at other points in the pipeline.

>> it has not been, I've not seen any technical reason why this decision
>> should be changed.
>> author cannot always get back a path identical to one they built up
>> using the moveTo/lineTo/arcTo/etc. commands.
That's correct; they do not need identical information either. There's 
nothing
in the spec requiring such precision, nor is there anything in the 
target environments.



-Charles
Received on Friday, 24 June 2011 02:58:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:10:30 UTC