WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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
Add attachment
proposed patch, testcase, etc.
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.
Top of Page
Format For Printing
XML
Clone This Bug