User-Agent: Mozilla/5.0 (Windows; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100718 Minefield/4.0b2pre
Build Identifier: Mozilla/5.0 (Windows; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100718 Minefield/4.0b2pre
while I'm still working around 'defs', 'foreignObject' and 'use', I have found this strange behaviour.
If you set a 'canvas' element inside a 'foreignObject', itself inside a 'g' element and if you paint some things on the canvas, it works well. But if you do the same and put the 'g' element inside a 'defs' element, when you call the 'g' element trough the 'use' element, the canvas element is never rendered.
If you use an HTML img element in replacement of the canvas element, it work well.
Steps to Reproduce:
1. Open the test case
You can see 3 green squares and 1 red square.
You should see 4 green squares
Created attachment 458294 [details]
The first square is using a rect and act as a reference redering
The second square use an HTML img
The third square use a canvas element outside the defs element
The fourth square use a canvas element inside the defs element
Created attachment 458312 [details]
I have run some more tests and 'defs' is not the issue. I think the issue is based on how 'use' handle it's rendering zone with 'canvas'.
This simpler test case remove the 'defs' element and focus on 'use'.
The left column show how it behave with 'canvas' the right column show how it behave with 'img';
Note that in this test case, the 'use' element is affected by bug 578309
Ok, sometimes I'm dull! Forget about 'use' and bug 578309. This has nothing to do here. Sorry.
But the problem of not rendering canvas vs. rendering HTML img remain.
<use> clones the elements it references, in the cloneNode sense (or must act as if it does). It says so right in the spec (SVG 1.1 second edition, section 5.6):
The effect of a ‘use’ element is as if the contents of the referenced element
were deeply cloned into a separate non-exposed DOM tree which had the ‘use’
element as its parent and all of the ‘use’ element's ancestors as its
For an <img>, cloning clones the src attribute, so the clone also loads the image.
For a <canvas>, cloning clones attributes but does NOT clone the actual backing store. So you don't see the image.
Similarly <input> elements with text typed in would not show that text when <use>d, etc. <use> works on the DOM level, so it doesn't faithfully represent data that's not part of the DOM.
Ok, so I supposed that if the cloned DOM tree is non-exposed, it means that there is no way of accessing the cloned Canvas. Is that right?
Because the SVG spec is a bit old and the HTML5 spec is really new, it looks to me that this particular use case is something that no one imagine in the early time of SVG.
Now that HTML5 allow to use direct inline SVG inside the HTML dom tree, there is maybe something to discuss with the HTML and SVG working group here?
I agree that for standalone SVG document, the way the 'use' element is defined make sens : it's impossible to imagine all the use case that foreignObject could bring and its necessary to have a reasonable behavior on that matter.
But when we talk about SVG and HTML5 so intimately mixed, for what is worth, I think it would be interesting to go further. Sadly, I'm just a "end user" so I have no skills nor ideas on how is it possible to achieve this, but I'm pretty sure that there will be a lot of web designers that enjoyed such a possibility.
> it means that there is no way of accessing the cloned Canvas
There's no way to access the canvas api parts of it, correct.
> it looks to me that this particular use case is something that no one imagine
> in the early time of SVG.
Probably. Most of <foreignObject> isn't all that well thought out.
> there is maybe something to discuss with the HTML and SVG working group here?
Sure. firstname.lastname@example.org and email@example.com respectively.
*** Bug 593266 has been marked as a duplicate of this bug. ***