579853 - Canvas element inside defs elements are not rendered

Status: RESOLVED INVALID

(Core :: SVG, defect)

Description

[Jeremie Patonnier :Jeremie]

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.

Reproducible: Always

Steps to Reproduce:
1. Open the test case
 
Actual Results:  
You can see 3 green squares and 1 red square.

Expected Results:  
You should see 4 green squares

Comment 1

[Jeremie Patonnier :Jeremie]

Attachment: testcase

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

Comment 2

[Jeremie Patonnier :Jeremie]

Attachment: Simpler testcase

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

Comment 3

[Jeremie Patonnier :Jeremie]

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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

<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
  higher-level ancestors.

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.

Comment 5

[Jeremie Patonnier :Jeremie]

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 can see some others use cases that could handle the same "problem". All the forms element as Boris mentions or some video usage. For example, if I defined a video element and that I attach some control to it through Javascript. If I reused that video element through the 'use' element, the Javascript controls only match the first element, not both. Sometimes it's require, sometimes it's not. As a user, if I want to build separate controls, it makes sens to clone myself the video element. But if I want a unified control system for all my clone, it would be very intuitive to use the 'use' element to perform a "fake" cloning.

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.

Comment 6

[Boris Zbarsky [:bzbarsky]]

> 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.  [e-mail] and [e-mail] respectively.