External SVG imported with <use> via fragment identifier can be styled from outside
Categories
(Core :: SVG, defect)
Tracking
()
People
(Reporter: danburzo, Unassigned)
Details
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:145.0) Gecko/20100101 Firefox/145.0
Steps to reproduce:
With the setup below.
index.html:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Importing SVG with fragments</title>
<style type='text/css'>
#root {
fill: red;
}
#symbol {
fill: green;
}
</style>
</head>
<body>
<svg>
<use href='./root.svg#root'/>
</svg>
<svg>
<use href='./symbol.svg#symbol'/>
</svg>
</body>
</html>
root.svg:
<?xml version="1.0" encoding="UTF-8"?>
<svg id="root" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100">
<rect x='0' y='0' width='100' height='100'/>
</svg>
symbol.svg:
<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 100 100">
<symbol id='symbol'>
<rect x='0' y='0' width='100' height='100'/>
</symbol>
</svg>
Actual results:
In Firefox, external SVGs referenced in <use> via the fragment identifier, regardless of whether the referenced element is the root <svg> container or a <symbol>, can be styled from the outside HTML. The rectangles in the testcase are red and green, respectively.
Expected results:
The rectangles should stay black, as is the case in Chrome and Safari.
|
||
Updated•1 month ago
|
|
||
Comment 1•1 month ago
|
||
I think Chrome/Safari simply haven't implemented this (they haven't yet implemented SVG 2.0 compatible use elements, although Chrome is working on support).
I haven’t been able to make sense of the numerous <use>-related issues, and the conversations accompanying their resolutions. In this particular scenario, is it expected that styles in the host document can pierce the shadow DOM and address elements directly in the <use> element?
From § 5.5.3. Style Scoping and Inheritance, emphasis mine:
The use-element shadow tree, like other shadow trees, exhibits style encapsulation, as defined in the CSS Scoping module [css-scoping-1]. This means that elements in the shadow tree inherit styles from its host ‘use’ element, but that style rules defined in the outer document do not match the elements in the shadow tree. Instead, the shadow tree maintains its own list of stylesheets, whose CSS rules are matched against elements in the shadow tree.
|
|
||
Comment 4•1 month ago
|
||
It also says later on...
In most cases, the element instance in the shadow tree will match the same style rules as its corresponding element in the original document.
Feel free to take this up with w3c via https://github.com/w3c/svgwg/issues but SVG use elements should behave the same as HTML shadow tree elements e.g. the HTML template element. If SVG is inconsistent with HTML then it's SVG that needs to change.
The passage you quote seems to refer to how styles cloned along with an element from its original context will in most cases, but not always, be applicable to its new context in the shadow tree.
I'm describing a situation where external CSS styles, defined outside the source SVG (root.svg), are applying directly to elements inside the <use> shadow DOM, whose styling should be possible only by inheriting from the <use> element. I can’t find any support in the spec for the assertion that Firefox is conforming in this case.
For the benefit of others running into this situation — as well as for my own comprehension — can you please elaborate how Firefox’s behavior in this specific case correlates with the SVG 2 spec? I will gladly take this up with the SVGWG once I understand what passages in the specification text drive this.
|
|
||
Comment 6•1 month ago
|
||
Firefox implements use cloning via the same shadow tree technology that is used for HTML templates i.e. a shadow DOM. Chrome and Safari do not currently do that. The SVG 2 specification was written to be compatible with shadow DOM (unlike SVG 1.1). If there is anything in the SVG 2 specification that is not compatible with shadow DOM as implemented for HTML then the SVG specification should be changed.
Thanks! I understand that to mean that following the HTML model for Shadow DOM, as intended by the SVG 2 spec, to its logical conclusion produces some surprising outcomes, such as the fact that SVG content fetched from external sources can be matched by CSS selectors in the host HTML document, crossing over into the shadow tree produced by the <use> element. I’ve opened an SVGWG issue here: https://github.com/w3c/svgwg/issues/1030
As per the conversation in the SVGWG issue, is there any chance Firefox is misattributing external SVGs to the destination context, and therefore grabbing the CSS styles defined in the HTML as pertaining to the source element and bringing them over into the shadow DOM?
Fetching external SVG content should not behave as if it were declared inline, as in the example below:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Importing SVG with fragments</title>
<style type='text/css'>
#symbol {
fill: green;
}
</style>
</head>
<body>
<svg viewBox="0 0 100 100">
<defs>
<symbol id='symbol'>
<rect x='0' y='0' width='100' height='100'/>
</symbol>
</defs>
<use href='#symbol'/>
</svg>
</body>
</html>
I want to point out Amelia Bellamy-Royds’ diagnosis and conclusion on the SVGWG issue:
However, when the content being cloned comes from a different file, SVG 2 is quite clear that the style rules that should be cloned into the shadow tree are those defined in the external file. […] The current Firefox behaviour reported by @danburzo is inconsistent with the SVG spec (version 1 or 2). It is also inconsistent with shadow DOM built from HTML templates (which do not by default clone stylesheets from the parent document into the shadow tree unless the style element itself is part of the cloned template).
(As long as this issue remains closed, people are prevented from commenting directly on this thread.)
|
|
||
Comment 10•1 month ago
|
||
I guess we'll wait and see what Chrome does.
Description
•