Re: [dom] Comments on heycam's new SVG DOM

I really like this proposal. I think it's a clear win for both usability
and interoperability. A few questions and comments are below:

1) I think it's important to keep open the possibility of better SVG and
canvas interaction.
I'd like a future where CanvasImageSource includes SVGGraphicsElement so
users can render SVG in canvas while maintaining styles (for caching, etc).
Issue #2 (HTML content in SVG) opens a bunch of possibilities but I'd like
to make sure it doesn't break the
canvasContext.drawImage(SVGGraphicsElement) dream :)

Similarly, allowing <canvas> in SVG without jumping through data:uri
encoding hoops would be convenient and fast, even if it's not useful for
standalone documents.

2) I love the new non-live path segments.
The new path definition has both a string setter/getter and a sequence
setter/getter. I think this could be improved, possibly with a union type.

3) Why keep around normalized paths at all?

4) +1 to killing the old instance tree.


On Thu, Aug 15, 2013 at 4:34 PM, Rik Cabanier <> wrote:

> I agree.
> Let's remove it from the browsers.
> On Thu, Aug 15, 2013 at 3:56 PM, Robert O'Callahan <>wrote:
>> We never implemented instanceTree in Gecko and I can't even find a single
>> Bugzilla bug asking for it. There's
>>, which requests
>> support for SVGElementInstance but the testcases in that bug don't even
>> need it and interest in the bug is minimal.
>> So I recommend just ripping out SVGElementInstance and instanceTree from
>> your implementation.
>> Rob
>> --
>> Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
>> le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
>> stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
>> 'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
>> waanndt  wyeonut  thoo mken.o w  *
>> *

Received on Friday, 16 August 2013 23:37:52 UTC