Re: [svgwg] SVG2 spec means elements within a <use> tag can not be targeted for styling (#367)

The SVG Working Group just discussed `SVG2 spec means elements within a <use> tag can not be targeted for styling`, and agreed to the following:

* `RESOLVED: child content of foreignObject is stripped out of a use element shadow tree clone -- check browsers for exact impl details`
* `RESOLVED: No change to spec around use element styling, but focus on getting feedback from implementors about feasibility of current SVG 2 model`

<details><summary>The full IRC log of that discussion</summary>
&lt;heycam> Topic: SVG2 spec means elements within a &lt;use> tag can not be targeted for styling<br>
&lt;heycam> github: https://github.com/w3c/svgwg/issues/367<br>
&lt;heycam> emilio: SVG 1 says you take the style rules from the reference element<br>
&lt;heycam> ... that not only changes the behavior of decendant combinators, but also element specific states<br>
&lt;heycam> AmeliaBR: it wasn't clear in SVG 1, the way it was implemented was the specified style gets copied over, so any style rules directly set on the element get cloned with it<br>
&lt;heycam> ... and then inherited styles are inherited in<br>
&lt;heycam> ... nothing in Web Components shadow DOM that's at all like that<br>
&lt;heycam> ... trying to harmonize with shadow DOM, we defined it so that the style sheet is cloned in the shadow trees<br>
&lt;heycam> ... but that could break some select matching compared with the original element<br>
&lt;heycam> ... what gets fixed is the interactive selectors<br>
&lt;heycam> rniwa: do we know what implementations do?<br>
&lt;heycam> AmeliaBR: Firefox matches SVG 2 spec<br>
&lt;heycam> emilio: Blink and WebKit, in order to resolve style in the use subtree, you match the referenced element<br>
&lt;heycam> rniwa: so the original source element is used for styling<br>
&lt;heycam> emilio: so when you hover over the reference, all the clones get hover styles<br>
&lt;heycam> ... the Firefox behavior is a bit unfortunate, regarding the combinators, but we haven't received many bugs about that<br>
&lt;heycam> krit: how long has it been shipping?<br>
&lt;heycam> emilio: more than 2 years<br>
&lt;heycam> AmeliaBR: Firefox had never implemented the SVG 1.1 spec<br>
&lt;heycam> heycam: right<br>
&lt;heycam> myles: did you have to add special case SVG code?<br>
&lt;heycam> emilio: not really<br>
&lt;heycam> ... in special of the special casing code being on the "compute the style" function, the code checks if the element is in a use shadow tree, then also look at your tree parent scope for rules<br>
&lt;heycam> AmeliaBR: it can probably be represented by the adopted style sheets concept<br>
&lt;heycam> emilio: yeah....<br>
&lt;heycam> ... but to implement it efficiently, you just look up to the parent scope<br>
&lt;heycam> rniwa: conceptually you're copying the rules<br>
&lt;heycam> emilio: yes<br>
&lt;heycam> ... conceptually you just look at the outside use shadow tree<br>
&lt;heycam> AmeliaBR: when this has previously come up, Rossen has been cautious of breaking changes<br>
&lt;heycam> ... but we don't have a sensible spec<br>
&lt;heycam> ... in the existing SVG 1.1 match browsers, there were inconsistencies in terms of interactive styles, animations, whether htings get copied<br>
&lt;heycam> ... so in the details, we don't have a spec to define how those things work in a way that's actually corss browser<br>
&lt;heycam> ... so either way, implementations would have to change if we want truly consistent behavior<br>
&lt;heycam> ... I'm OK with making that be closer to SVG 1.1, but I need a spec proposal for that if people want to do that<br>
&lt;heycam> ... that also takes care of interactions, animations, etc.<br>
&lt;heycam> rniwa: the question to me is which behavior is more compatible with existing content<br>
&lt;heycam> ... also author expectations<br>
&lt;heycam> emilio: regarding author expectations, it's tricky.  SVG 1 kind of matches "I'm styling the element I'm cloning"<br>
&lt;heycam> ... so ancestor combinators work<br>
&lt;heycam> ... however it doesn't match expectations of :hover<br>
&lt;heycam> ... the SVG 2 behavior works the other way around<br>
&lt;heycam> ... for authors who are familiar with shadow trees, it probably makes sense<br>
&lt;heycam> AmeliaBR: we have had some bug reports on SVG spec and Firefox about people whose selectors didn't work because they were using these ancestor selectors<br>
&lt;heycam> ... but when you explain how to fix it, it was OK<br>
&lt;heycam> ... the :hover not working, that's a much more intrinsic confusion<br>
&lt;heycam> ... and there's no easy way to explain that<br>
&lt;heycam> rniwa: whatever solution we come up with, it should handle :hover.  :focus would even be a bigger problem<br>
&lt;heycam> AmeliaBR: SVG 1 really didn't discuss keyboard focus.  but now we have a model, you can have focus in the shadow tree, so your :focus rules should reflect the element that's actually focused<br>
&lt;heycam> rniwa: there's also some niceness in that if we had adopted style sheets, it could be described in that way<br>
&lt;heycam> AmeliaBR: I need to talk to Antti and folks to check what they think<br>
&lt;heycam> s/AmeliaBR/rniwa/<br>
&lt;heycam> AmeliaBR: we should probably poke a Chromium engineer for feasibility too<br>
&lt;emilio> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=7216 is a testcase that shows the difference of behaviors<br>
&lt;heycam> krit: we've had this issue for a long time, it's been waiting for implementor view for a while<br>
&lt;heycam> emilio: I recall having a WebKit patch for that in the past...<br>
&lt;heycam> emilio: there's a test case I've pasted<br>
&lt;heycam> krit: how does the shadow content know about the viewport size?<br>
&lt;heycam> AmeliaBR: that's the same as regular shadow DOM, it uses the document viewport for MQs etc.<br>
&lt;heycam> rniwa: might want to consider what happens if you support shadow root on an SVG element at some point<br>
&lt;heycam> AmeliaBR: definitely want to support custom SVG elements with shadowRoot<br>
&lt;krit> q?<br>
&lt;heycam> [some discussion about use elements pointing to foreignObject]<br>
&lt;emilio> rniwa: https://github.com/w3c/svgwg/issues/511<br>
&lt;heycam> krit: but in general we agree we don't want foreignObject in the shadow tree?<br>
&lt;heycam> rniwa: yes, that would get hairy<br>
&lt;heycam> ... then you can have SVG, MathML, plugins....<br>
&lt;heycam> RESOLVED: child content of foreignObject is stripped out of a use element shadow tree clone -- check browsers for exact impl details<br>
&lt;heycam> RESOLVED: No change to spec around use element styling, but focus on getting feedback from implementors about feasibility of current SVG 2 model<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/svgwg/issues/367#issuecomment-532968985 using your GitHub account

Received on Thursday, 19 September 2019 05:14:01 UTC