- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 11 Nov 2011 01:44:10 -0800
- To: Simon Pieters <simonp@opera.com>
- Cc: Henri Sivonen <hsivonen@iki.fi>, public-webapps WG <public-webapps@w3.org>
On Fri, Nov 11, 2011 at 12:27 AM, Simon Pieters <simonp@opera.com> wrote: > On Thu, 10 Nov 2011 18:32:36 +0100, Jonas Sicking <jonas@sicking.cc> wrote: > >> And yes, this does create a lot of edge cases which needs to be >> defined. But the goal should be to make sane calls sane, that seems >> imminently possible. So >> >> frag.innerHTML = "<g></g>"; >> someSVGElement.appendChild(frag); >> >> seems very possible to make work. > > How? For all element names defined in SVG 1.1 (for now), make the parser treat it just as it would have if it had parsed "<svg><g>...", except that it obviously wouldn't output the <svg> element. There are a few tags where this is a big problem. At least for <a>, <script> and <style> appear both in SVG and HTML and so for markup like "<a>...", "<style>..." and "<script>..." we don't know which namespace to create the element in. Fortunately these elements behave mostly the same no matter which namespace they are created in. Unfortunately <style> and <script> are parsed differently depending on if they live in foreign content or not. However this is something we can fix, and would lead to a lot of other benefits (such as scripts parsed consistently when moved around in the markup). / Jonas
Received on Friday, 11 November 2011 09:45:25 UTC