[Webkit-unassigned] [Bug 174977] [Shadow DOM] Use elements not resolved when SVG is nested in shadow root

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Aug 4 03:02:08 PDT 2017


https://bugs.webkit.org/show_bug.cgi?id=174977

--- Comment #8 from Sebastian Müller <seb.p.mueller at gmail.com> ---
(In reply to Ryosuke Niwa from comment #7)

> We certainly need to define what that means. For example, what happens if
> there are multiple shadow trees in which there are two distinct #circle
> defined and referenced. From what you've described, it seems to indicate
> that each reference should be using the one defined in its own shadow tree.

Yes - just like if you had two divs with the same id in two different shadow trees. querySelector('#theDuplicateId') works just as well in this case (inside the respective tree), or not?

> Unfortunately, this would not mesh well with the existing SVG 2.0 spec which
> states that use element's href uses a URL reference to reference the source
> element (see https://svgwg.org/svg2-draft/struct.html#UseElement) because
> fragment URLs do not have a mechanism to differentiate two IDs defined in
> each shadow tree. For my interpretation of what you're proposing to work, we
> need to invest a wholly different semantics for use element.

The by far most common use-case for the "use" element is to reference elements in a "defs" element in the *same* svg document in the web context. Referencing defs from another document is almost never used (there are many issues with that in web browsers). So even though it *can* be a full-fledged URL, in most cases it is simply the anchor and for this case, I think it is totally obvious what the behavior should be. The living SVG 2.0 spec (which is not implemented anywhere, yet) should probably be adjusted to work with the most frequent use-case. If it does not work at all with shadow dom, then no one will be using it. 

> 
> > Moving the self-contained (with no refernces to anything
> > else outside the svg element) SVG image from the top-level DOM into a shadow
> > dom should *not* break it completely.
> 
> That's a good first principle for making SVG work better with shadow trees.
> However, someone has to do the work of defining what it means to reference a
> SVG element inside a shadow tree in the same tree, from an inner shadow tree
> or from outside. Nothing is well defined in this regard.

I totally agree with you here - but I don't believe it is necessary to have a solution for all absurd corner-cases (referencing *across* shadow-dom boundaries!?) before you can get the main use-case (crossing no boundaries) to work. 

I also don't understand at all why  fill="url(#someId)" should work, whereas href="#someId" does not. Can you explain why one thing is simple, whereas the other one is not?


> I agree that SVG use element not
> working is a huge limitation of the shadow DOM API today but it would not
> totally undermine the usefulness of shadow DOM API in my opinion.

Until SVG use elements work in Safari in the context of shadow dom "as expected", we are going to have to tell our customers either not to use shadow DOM or not to use Safari. It's as simple as that. I know what their choice will be...

> 
> Anyway, I welcome your contribution to
> https://github.com/w3c/webcomponents/issues/179 so that we can define the
> behavior and implement it in WebKit.

Thanks!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20170804/fe96d83d/attachment-0001.html>


More information about the webkit-unassigned mailing list