1367449 - SVG currentcolour specificity

Status: RESOLVED DUPLICATE of bug 265894

(Core :: SVG, defect)

Description

[ste.matchboxhero]

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

Steps to reproduce:

Create a basic HTML page with an SVG, reference the SVG to output it on the page. Apply basic CSS rules to apply a colour to the body element (blue), set the basic styles of SVGs fill to 'currentcolor'. Create a class with a different fill colour (green) and apply that class to the SVG in the HTML. https://codepen.io/matchboxhero/pen/JNxVKN


Actual results:

The SVG is blue.

https://codepen.io/matchboxhero/pen/JNxVKN


Expected results:

The SVG should be green.

https://codepen.io/matchboxhero/pen/JNxVKN

Comment 1

[Loic]

Blue in Firefox, green in Chrome.

Comment 3

[Robert Longson [:longsonr]]

This is because of the targetting of the use element.

Comment 4

[u459114]

The root cause of this bug is a little bit different with bug 265894, but I will fix them at once in that bug

In bug 265894 comment 27, Amelia gave really useful information(thanks)
- 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.

We clone a symbol referenced element as an SVG element at:
https://hg.mozilla.org/mozilla-central/file/c6af127dce9d/dom/svg/SVGUseElement.cpp#l278

So the cloned element instance, which is an SVG element, matches
svg {
  fill: currentcolor;
}

Bug 265894 violates another item:
- 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.