[Shadow]: There's isn't a way to append shadow elements in SVG (bugzilla: 24181)

[hayatoito]

Title: [Shadow]: There's isn't a way to append shadow elements in SVG (bugzilla: 24181)

Migrated from: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24181

---

comment: 0
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24181#c0
Philip Rogers wrote on 2013-12-31 00:14:24 +0000.

Multiple shadow roots aren't very useful in SVG because it's not possible to append a shadow element to an SVG element (they are in different namespaces). I think we may need SVGShadowElement to achieve this glorious goal.

A fun historical anecdote:
The only reference I found to "SVGShadowElement" was this post from a decade ago :)
http://lists.w3.org/Archives/Public/www-svg/2003Nov/0085.html

---

comment: 1
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24181#c1
Tab Atkins Jr. wrote on 2014-01-03 19:36:57 +0000.

Nope, nope nope nope nope nope. We are not adding more "exactly like the HTML element, but with a different interface name" things.

Consider this further impetus for the glorious "just put SVG in the HTML namespace already" future.

---

comment: 2
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24181#c2
Erik Dahlström wrote on 2014-02-05 09:44:19 +0000.

(In reply to Tab Atkins Jr. from comment #1)

Nope, nope nope nope nope nope. We are not adding more "exactly like the
HTML element, but with a different interface name" things.

Consider this further impetus for the glorious "just put SVG in the HTML
namespace already" future.

I agree that in the best of worlds svg and html would just interleave nicely and everything would just work. However, we do need to make some changes for that to happen.

Issues:

1. Parsing of the shadow element (and content, template and possibly others). This assumes that the HTML parsing algorithm doesn't break out of "svg-mode" if encountering a shadow/content/template element inside an svg fragment. I expect that if using svg standalone (aka in xml mode) you'd still have to XHTML namespace these elements (horribly ugly, but unless we require some sort of special handling to push the elements into the html namespace that's what we have to do).
2. Rendering of non-svg elements in an svg context - we need the svg spec to allow and require that at least for the Shadow DOM elements.
   2.1. Note that https://svgwg.org/svg2-draft/embedded.html already imports/renames a bunch of html elements. We should strive to solve these in a similar way.
3. Assuming the Shadow DOM elements stay in the html namespace and do render in svg, should they (if inside of svg content) have partial interfaces that append some SVG traits like getting the current transform, bbox and so on? Should that be decided on an element to element basis, or should there be a default fallback partial interface?

---

comment: 3
comment_url: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24181#c3
Tab Atkins Jr. wrote on 2014-02-05 15:43:27 +0000.

(In reply to Erik Dahlström from comment #2)

(In reply to Tab Atkins Jr. from comment #1)

Nope, nope nope nope nope nope. We are not adding more "exactly like the
HTML element, but with a different interface name" things.

Consider this further impetus for the glorious "just put SVG in the HTML
namespace already" future.

I agree that in the best of worlds svg and html would just interleave nicely
and everything would just work. However, we do need to make some changes for
that to happen.

Issues:

1. Parsing of the shadow element (and content, template and possibly
   others). This assumes that the HTML parsing algorithm doesn't break out of
   "svg-mode" if encountering a shadow/content/template element inside an svg
   fragment. I expect that if using svg standalone (aka in xml mode) you'd
   still have to XHTML namespace these elements (horribly ugly, but unless we
   require some sort of special handling to push the elements into the html
   namespace that's what we have to do).

"Standalone" and "XML mode" are not necessarily synonymous. We should continue to push for them to be different, so that SVG is tied to the HTML parser both standalone and when embedded in HTML.

1. Rendering of non-svg elements in an svg context - we need the svg spec to
   allow and require that at least for the Shadow DOM elements.
   2.1. Note that https://svgwg.org/svg2-draft/embedded.html already
   imports/renames a bunch of html elements. We should strive to solve these in
   a similar way.

Yup, and all of these are a terrible mistake which should be rectified by making them be in the HTML namespace. (I didn't realize we'd imported them :/ )

1. Assuming the Shadow DOM elements stay in the html namespace and do render
   in svg, should they (if inside of svg content) have partial interfaces that
   append some SVG traits like getting the current transform, bbox and so on?
   Should that be decided on an element to element basis, or should there be a
   default fallback partial interface?

The Shadow DOM elements and aren't ever rendered, so I don't think they need any of those.

[annevk]

There are no shadow elements anymore.