SVG2 spec contains breaking changes around SVGUseElement, some of which can not be worked around. See https://github.com/w3c/svgwg/issues/367#issuecomment-640272972 Apologies if this is the wrong way to do this, but I'm looking for a way to get pinged if/when this lands in STP/Safari in the event the item is buried by more significant update notes.
I think this problem is already reported in bug 179724. Also a reduced test case is https://www.w3.org/TR/SVG2/images/struct/Use-changed-styles.svg. *** This bug has been marked as a duplicate of bug 179724 ***
Ah, that report is certainly relevant. However, my specific concern is with the default appearance of the targeted element sans any styling of <use>. In SVG1.1, absent a `use` rule, the re-presented circle element should always display per `.special circle{}`. (Given a `use` related rule, there is indeed ambiguity regarding which style rules take precedence and unexpected behavior may result, hence the bug report) According to the SVG2 spec however, `.special circle{stroke:green}` should have no baring on the re-presented element, ever. That circle will technically be outside of `.special` and so those rule will not apply. Combined with the rules for shadowDOM (which underlies the SVG use element spec), in the test case, the re-presented circle will have neither a green stroke or purple stroke but no stroke at all — both instance styling and re-presentation are compromised. But while instance styling can be patched around via CSS variables, the ability to re-present an element whose appearance is determined by its source context will be eliminated entirely.
(In reply to ian from comment #2) > Ah, that report is certainly relevant. > > However, my specific concern is with the default appearance of the targeted > element sans any styling of <use>. > > In SVG1.1, absent a `use` rule, the re-presented circle element should > always display per `.special circle{}`. (Given a `use` related rule, there > is indeed ambiguity regarding which style rules take precedence and > unexpected behavior may result, hence the bug report) > Let's be clear here. We are planning to implement SVG2. We already started doing that but we have not finished yet, please see bug 191292. So any behavior in WebKit SVG which is not working according to SVG2, even it works according to SVG1.1 specs, is a bug. > According to the SVG2 spec however, `.special circle{stroke:green}` should > have no baring on the re-presented element, ever. That circle will > technically be outside of `.special` and so those rule will not apply. > And this is not the case in both WebKit and Blink right now. But it works as expected in FireFox. > Combined with the rules for shadowDOM (which underlies the SVG use element > spec), in the test case, the re-presented circle will have neither a green > stroke or purple stroke but no stroke at all — both instance styling and > re-presentation are compromised. > What does this part mean? And what is the meaning of "compromised" in this context? Does the shadowDOM specs contradict the SVG2 specs? > But while instance styling can be patched around via CSS variables, the > ability to re-present an element whose appearance is determined by its > source context will be eliminated entirely. I can't follow this part also. Is this a bug in the specs or a bug in WebKit? Can you please alter the test case and state your expectations or concerns if SVG2 rules are applied.
Reopening for further discussion and maybe a different resolution.
> Let's be clear here. We are planning to implement SVG2. We already started doing that but we have not finished yet, please see bug 191292. So any behavior in WebKit SVG which is not working according to SVG2, even it works according to SVG1.1 specs, is a bug. For brevity, I think that finalizes discussion -- my concerns are with the spec so I will direct my attention accordingly, bow out here, and keep an eye for when <use>-related updates land. Appreciate the response but this can be re-closed. Sorry to create any confusion.
*** This bug has been marked as a duplicate of bug 179724 ***