Support SVG CSS selector matching rules for <svg:use>




13 years ago
4 hours ago


(Reporter: tor, Unassigned)


(Blocks: 4 bugs)

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(1 attachment, 1 obsolete attachment)

640 bytes, application/xml


13 years ago


13 years ago
Depends on: 237020
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
sense here.

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
style set.
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?

Comment 4

12 years ago
the testcase worksforme 

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

Comment 5

10 years ago
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.
Assignee: general → nobody
QA Contact: ian → general

Comment 6

7 years ago
Shouldn't this first testcase be obsoleted?  It works for me also.  The second test case does exhibit the described problem.


7 years ago
Duplicate of this bug: 553626


7 years ago
Blocks: 554013

Comment 8

7 years ago
2nd testcase is still valid.
Mozilla/5.0 (Windows; Windows NT 5.1; en-US; rv:2.0b2pre) Gecko/20100716 Minefield/4.0b2pre


7 years ago
Duplicate of this bug: 581362

Comment 10

7 years ago
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:

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.

Comment 11

7 years ago
I'm fairly sure this use bug is unrelated to any marker issue.
Duplicate of this bug: 589643


3 years ago
Duplicate of this bug: 997362
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.
Attachment #184975 - Attachment is obsolete: true
Duplicate of this bug: 1003185
Duplicate of this bug: 984220
Note that nsIAnonymousContentCreator can in fact hand back style contexts with the nodes now.


3 years ago
Duplicate of this bug: 1081999


3 years ago
Duplicate of this bug: 1107038


2 years ago
Duplicate of this bug: 1172900


2 years ago
Duplicate of this bug: 1194246


2 years ago
Duplicate of this bug: 1196748

Comment 23

2 years ago
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:


2 years ago
Duplicate of this bug: 1223645

Comment 25

a year ago
If anybody stumbles on this issue in the future, there's a good explanation and workaround by AmeliaBR here:


a year ago
Duplicate of this bug: 1268431
Summary: Support SVG CSS cascading rules for <svg:use> → Support SVG CSS selector matching rules for <svg:use>
No longer depends on: 237020

Comment 27

8 months ago
FYI to anyone working on this (or thinking about starting):

Style matching rules for cloned content in `use` elements have been updated in SVG 2:

The new rules are consistent with the shadow DOM style scoping and inheritance used for web components, with the extra requirement that stylesheets from the source document are cloned into the shadow tree's scope.

This actually results in a few edge cases where Firefox already matches the new rules & the other browsers don't (see the example in that section about changes from SVG 1.1 to SVG 2).  But there are still important changes that need to be made to get Firefox to spec:

- Symbol elements should be cloned as symbol, not as svg.  The distinction about whether a symbol should be rendered or not depends on whether it is a direct child of a use element's shadow root.

- Selectors should not cross the shadow DOM boundary.  E.g., use > circle should never match, even if the use element duplicates a circle, because the cloned circle is in the shadow DOM, not the main DOM.  Hopefully that will be easier to implement now that these rules are consistent with the broader web platform concept of Shadow DOM.

- When the cloned content is from an external file, any <style> blocks in that file should be parsed and cloned into the shadow DOM's scope, after adjusting any URLs if required.

PS:  If anything in the spec is unclear or impossible to implement, please raise a bug on the SVG Working Group's GitHub repo:


8 months ago
Duplicate of this bug: 1298557
This appears to break, reported @


8 months ago
Duplicate of this bug: 1305078
Priority: -- → P3
Blocks: 1262352
Blocks: 1366722
You need to log in before you can comment on or make changes to this bug.