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.

Philip



On Thu, Aug 15, 2013 at 4:34 PM, Rik Cabanier <cabanier@gmail.com> wrote:

> I agree.
> Let's remove it from the browsers.
>
>
> On Thu, Aug 15, 2013 at 3:56 PM, Robert O'Callahan <robert@ocallahan.org>wrote:
>
>> We never implemented instanceTree in Gecko and I can't even find a single
>> Bugzilla bug asking for it. There's
>> https://bugzilla.mozilla.org/show_bug.cgi?id=265895, 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  *
>> *
>>
>
>