- From: <bugzilla@jessica.w3.org>
- Date: Wed, 05 Feb 2014 15:43:27 +0000
- To: public-webapps-bugzilla@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24181 --- Comment #3 from Tab Atkins Jr. <jackalmage@gmail.com> --- (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. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 5 February 2014 15:43:29 UTC