So the issue here is that by the time we're resolving the style context we no
longer know that the element is an anonymous child of <use>, and more
importantly don't know what it was cloned off of.
One possible solution is to change <use> to implement CreateFrameFor() and
expose apis on the frame constructor to do that, somehow.
Another possible solution is to make it possible for nsIAnonymousContentCreator
to hand back not just nodes, but style contexts to be used for them.
I sort of like this last solution... David, what do you think?
Probably the real solution is to reverse the style context <-> frame
relationship. Using anonymous content creation mechanisms really doesn't make
What really needs to happen is:
* To implement svg:use across documents, we need an SVG document manager object
that manages all the SVG documents involved.
* Each of those documents needs a style set object. (This really requires
splitting nsStyleSet in half, since some parts of it involve rule tree and style
context tree ownership, and we shouldn't have more than one of those per document.)
* SVG frame construction needs to get the right style context from the right
Created attachment 184975 [details]
I was about to file a bug on this testcase. I presume fixing this bug will fix
the problem it demonstrates?
the testcase worksforme
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
Created attachment 255916 [details]
SVG + CSS match error
I just bumped over this problem minutes ago. Here's a TC for the bug. This shows that one can match the <circle /> as if it's a child of the <g>. This is explicitly not allowed by the W3C SVG 1.1 specification:
"CSS2 selectors cannot be applied to the (conceptually) cloned DOM tree because its contents are not part of the formal document structure."
The TC doesn't fail in Opera 9.
Shouldn't this first testcase be obsoleted? It works for me also. The second test case does exhibit the described problem.
*** Bug 553626 has been marked as a duplicate of this bug. ***
2nd testcase is still valid.
Mozilla/5.0 (Windows; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100716 Minefield/4.0b2pre
*** Bug 581362 has been marked as a duplicate of this bug. ***
I think I've encountered a similar issue but relating to markers instead. In my example I have 3 files:
#1 arrow.svg - Contains a path
#2 marker.svg - Contains a triangle marker
#3 style.css - Applies the triangle marker in marker.svg to the path in arrow.svg and styles it green.
Example File: http://www.mikehemesath.com/svg_markers/demo2/arrow.svg
Although the external stylesheet rule does successfully place the marker in marker.svg onto the path in arrow.svg, it doesn't apply the green fill style. This test case does work in Opera.
I'm fairly sure this use bug is unrelated to any marker issue.
*** Bug 589643 has been marked as a duplicate of this bug. ***
*** Bug 997362 has been marked as a duplicate of this bug. ***
Comment on attachment 184975 [details]
First testcase is WFM (and has been since soon after it was posted back in 2005, per comment 4 / comment 6). Obsoleting it.
*** Bug 1003185 has been marked as a duplicate of this bug. ***
*** Bug 984220 has been marked as a duplicate of this bug. ***
Note that nsIAnonymousContentCreator can in fact hand back style contexts with the nodes now.
*** Bug 1081999 has been marked as a duplicate of this bug. ***
*** Bug 1107038 has been marked as a duplicate of this bug. ***
*** Bug 1172900 has been marked as a duplicate of this bug. ***
*** Bug 1194246 has been marked as a duplicate of this bug. ***
*** Bug 1196748 has been marked as a duplicate of this bug. ***
I came across this bug on my own without finding this one first. I just wanted to provide some further examples. I'm not sure what good it will do, being that the issue is 10 years old, but here it is:
*** Bug 1223645 has been marked as a duplicate of this bug. ***
If anybody stumbles on this issue in the future, there's a good explanation and workaround by AmeliaBR here: http://stackoverflow.com/a/27872310/681179
*** Bug 1268431 has been marked as a duplicate of this bug. ***