User-Agent: Mozilla/5.0 (X11; Linux x86_64; en-US; rv:2.0b2pre) Gecko/20100716 Minefield/4.0b2pre Build Identifier: Mozilla/5.0 (X11; Linux x86_64; en-US; rv:2.0b2pre) Gecko/20100716 Minefield/4.0b2pre According to the spec, a foreignObject can be defined inside a defs element and reuse through a use element. Unfortunately, it does not work. (see http://www.w3.org/TR/SVG/struct.html) Reproducible: Always Steps to Reproduce: 1. open the attach test case Actual Results: You can see a red and a green square Expected Results: You should see two green squares.
The left square represent the use case for foreignObject, the right square represent a reference use case made with a SVG Image.
struct.html says: Any ‘svg’, ‘symbol’, ‘g’, graphics element or other ‘use’ is potentially a template object that can be re-used (i.e., "instanced") in the SVG document via a ‘use’ element. "graphics element" links to http://www.w3.org/TR/SVG/intro.html#TermGraphicsElement which says: One of the element types that can cause graphics to be drawn onto the target canvas. Specifically: ‘circle’, ‘ellipse’, ‘image’, ‘line’, ‘path’, ‘polygon’, ‘polyline’, ‘rect’, ‘text’ and ‘use’. So as far as I can tell, the spec says that a <foreignObject> is not a valid target for <use>. Where do you see otherwise?
Note that nsSVGUseElement::CreateAnonymousContent implements exactly the check the spec requires: 272 if (tag != nsGkAtoms::svg && 273 tag != nsGkAtoms::symbol && 274 tag != nsGkAtoms::g && 275 tag != nsGkAtoms::path && 276 tag != nsGkAtoms::text && 277 tag != nsGkAtoms::rect && 278 tag != nsGkAtoms::circle && 279 tag != nsGkAtoms::ellipse && 280 tag != nsGkAtoms::line && 281 tag != nsGkAtoms::polyline && 282 tag != nsGkAtoms::polygon && 283 tag != nsGkAtoms::image && 284 tag != nsGkAtoms::use) 285 return nsnull;
Mmmh I think I have misunderstood the specification. I think this is the conjuction of two point : - First, it's possible to set a 'foreignObject' inside a 'defs' element (any valid child for a 'g' element is a valid child for a 'defs' element), which means that there must be a way to reuse it at some point. Naively, I was thought that the 'use' element could be the way. - Second, when I've read the definition of the target for the 'use' element, the word "potentially" make me confused and I've assumed that the list of target were a non-restrictive list (which is obviously wrong). As a non native English speaker I'm used to that kind of mistake, my apologies. But, this interpretation is reinforce by the way the spec define how the use element handle its visual effect : "A ‘use’ element has the same visual effect as if the ‘use’ element were replaced by the following generated content [...] In the generated content, the ‘use’ will be replaced by ‘g’" And because 'foreignObject' is a valid child for a 'g' element, I've assumed that 'foreignObject' could be a valid target. The point is that I'm unable to find something in the spec that explicitly said how a 'foreignObject' inside a 'defs' element can be reused. Of course, because a 'foreignObject' can embed anything, it is not necessarily a graphic element. So the 'use' element is maybe not the better way to handle it. However, which is puzzling me the most is that it's possible to bypass this problem by surounding the 'foreignObject' element with a 'g' element which can be use as specified with a 'use' element. At some point, it's very weird that any valid child of a 'g' element can not be a valid target for a use element. Maybe there is something to discuss in the W3C SVG Working Group here.
Boris in comment 2 is right as usual. Feel free to take this up with the w3c svg wg as it seems an arbitrary restriction.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INVALID
Stuff in <defs> can be used for things other than <use>. For example, it can be used for filters, masks, etc. Those don't have the same restrictions as <use> does.
Please ignore my attachment - I attached it to the wrong bug. Bug 593266 is _somewhat_ related to this closed bug.
You need to log in before you can comment on or make changes to this bug.