Re: [w3c/webcomponents] How should various document internal references work when SVG is being used in shadow DOM (#179)

As far as sharing SVG definitions between multiple web component instances, the best solution is to put the SVG content in a separate file. No additional primitive or API is needed, though browser support needs to improve.  All current browsers support use-element references to other files (like `<use xlink:href="icons.svg#home">`), but only Firefox reliably supports references in SVG graphical effects properties (like `<g clip-path="effects.svg#star" filter="effects.svg#sparkle">`).

(The reason constructible stylesheets are necessary for external CSS files is because the CSS OM generated from them is modifiable. Currently, each shadow DOM tree might have its own, slightly modified version of that CSS OM that needs to be kept separate. In contrast, external SVG files are not accessible as a DOM from user scripts, and are certainly not modifiable, so there is no problem with the browser sharing the representation of those documents internally.)

This of course assumes that any URL reference that includes a file name (or more) would continue to be resolved relative to the base URL for the whole page.  Only hash-only URLs would resolve inside the same shadow tree.  A special behavior for hash-only URLs is also consistent with the latest spec (and some implementations) for resolving URLs in CSS stylesheets.

This would also mean that you could always reference back to the main document by including its own file name in the URL. Which isn't ideal, but it keeps the option available if necessary.  As an author, I prefer the flexibility of the recursive-search approach (option 3 in my poll)—but I accept that it might be too much of an implementation headache that threatens performance.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/179#issuecomment-432865325