1406418 - SVG <use> not inheriting CSS when using class instead of style

Status: RESOLVED INVALID

(Core :: SVG, defect)

Description

[philraj]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170926190823

Steps to reproduce:

Here's a codepen which displays the problem in FF56 (works as expected in previous versions and in Chrome):
https://codepen.io/anon/pen/QqQGQQ

Scenario 1:
1. Create some SVG symbols.
2. Define the attributes fill and stroke with some colors.
3. Give them a class "reset-fill" which you define in your stylesheet with rules "fill: inherit; stroke: inherit;"
4. Create some <use> elements which reference the symbols.
5. Apply a class to those <use> elements which sets the fill and stroke to different colors than the ones specified on the symbols' attributes.

Scenario 2:
1. Repeat steps 1-5 from Scenario 1.
2. Add inline styles to the SVG symbols, with the value "fill: inherit; stroke: inherit;"


Actual results:

Scenario 1:
In Firefox 56, the symbols do not inherit the rules applied to the <use> elements via the stylesheet and remain with their default attribute values for fill and stroke. In Chrome and Safari, and in previous versions of Firefox, this works properly.

Scenario 2:
The symbols inherit the rules defined in the stylesheet and change color.


Expected results:

Scenario 1:
In FF56, the values for fill and stroke on the SVG symbols should be inheriting from the CSS rules applied to the <use> elements which are referencing them, regardless of whether the inheritance rules are being set via a class or inline styles.

Scenario 2:
Working fine.

Comment 1

[Robert Longson [:longsonr]]

if you make the style just .reset_fill rather than svg .reset_fill it does what you want.

In SVG 2 (https://www.w3.org/TR/SVG2/struct.html#UseStyleInheritance)

If a CSS rule uses a complex selector to match an element based on its ancestors or siblings, and those ancestors or siblings are not cloned as part of the shadow tree, then that rule would no longer match the element instance.

Which is what we have here I think. So I don't think this is valid. Note that Firefox is the first browser to implement this part of SVG 2 which is why it's now different.

Comment 3

[philraj]

Hmm I'm a bit confused. You're saying that because the <svg> ancestor of the symbol is not cloned into the <use> element's shadow DOM, the selector "svg .reset-fill" doesn't match? But when I inspect the shadow DOM I see an <svg> element surrounding the cloned content. Since the selector is targeting any generic <svg>, I don't understand why it won't match anymore.

Comment 4

[Robert Longson [:longsonr]]

Correct you've not cloned an <svg> element ancestor when you clone the content so the CSS selector doesn't match anything.

Comment 5

[philraj]

Attachment: Inspecting <use> shadow DOM in Chrome

This is the structure of the shadow DOM of the <use> element after cloning from the SVG symbol.

Comment 6

[philraj]

I see an <svg> element ancestor in the attached image. Are you saying Firefox doesn't create an <svg> inside the shadow root the way Chrome does?

Comment 7

[Robert Longson [:longsonr]]

that's an artifact of the way we render things internally, it's not real and you can't target it with CSS. You could raise an inspector bug, perhaps we can get the inspector to hide that element somehow.

Comment 8

[philraj]

Well I don't know how it appears in the Firefox inspector as I can't seem to find any way to actually inspect the shadow DOM in Firefox. That was how it looks in the Chrome dev tools. Is it possible to view the <use> element's shadow DOM so I can confirm whether Firefox has that issue?

Comment 9

[Robert Longson [:longsonr]]

Sorry, I thought that was Firefox you were talking about, as I said, Chrome doesn't implement SVG 2 <use> elements, they still do it per SVG 1.1.

The DOM Inspector does show the correct tree with shadow DOM elements: https://developer.mozilla.org/en-US/docs/Tools/Add-ons/DOM_Inspector

The internal tools seem not to as far as I can tell. You could raise a bug on that of course if there isn't one already.

Comment 10

[philraj]

Ah I see. Well thank you for your help!

Comment 11

[Robert Longson [:longsonr]]

This is the link you want for the DOM inspector: https://addons.mozilla.org/en-GB/firefox/addon/dom-inspector-6622/