This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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
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.
(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?
(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. > 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. 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 :/ ) > 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? The Shadow DOM elements <content> and <shadow> aren't ever rendered, so I don't think they need any of those.
Moved to https://github.com/w3c/webcomponents/issues/96