RESOLVED DUPLICATE of bug 179724 212902
[SVG2] SVGUseElement spec contains breaking changes.
https://bugs.webkit.org/show_bug.cgi?id=212902
Summary [SVG2] SVGUseElement spec contains breaking changes.
ian
Reported 2020-06-08 07:55:59 PDT
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.
Attachments
Said Abou-Hallawa
Comment 1 2020-06-08 11:35:19 PDT
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 ***
ian
Comment 2 2020-06-08 12:27:31 PDT
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.
Said Abou-Hallawa
Comment 3 2020-06-08 13:25:19 PDT
(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.
Said Abou-Hallawa
Comment 4 2020-06-08 13:26:15 PDT
Reopening for further discussion and maybe a different resolution.
ian
Comment 5 2020-06-08 13:40:36 PDT
> 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.
Said Abou-Hallawa
Comment 6 2020-06-08 16:03:41 PDT
*** This bug has been marked as a duplicate of bug 179724 ***
Note You need to log in before you can comment on or make changes to this bug.