- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 11 Nov 2011 02:11:49 -0800
- To: Anne van Kesteren <annevk@opera.com>
- Cc: Simon Pieters <simonp@opera.com>, Henri Sivonen <hsivonen@iki.fi>, public-webapps WG <public-webapps@w3.org>
On Fri, Nov 11, 2011 at 1:49 AM, Anne van Kesteren <annevk@opera.com> wrote: > On Fri, 11 Nov 2011 10:44:10 +0100, Jonas Sicking <jonas@sicking.cc> wrote: >> >> 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. > > Not if you have "<a><g>". Indeed, <a> is a problem. I can't think of any great solutions here. One possibility *might* be to always output the <a> in the HTML namespace, but make the parser go back to the initial state after having parsed the <a> start tag. Hence for the string "<a><g>" we'd parse the <a> into the HTML namespace and the <g> into the SVG namespace. But that would require changes to the rendering code to treat HTML and SVG <a>'s the same. Another solution would be to move the logic into the parser such that we don't output the <a> until after having looked at the next token. But this might require too much surgery to the HTML parser as I'm not sure that it currently stalls outputting elements until it's looked ahead to the next token. >> 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). > > I do agree it would make sense to parse these consistently throughout > text/html. For what it's worth, every time I bring this subject up, the claim comes up that things are defined the way they currently are since the SVG WG wanted all existing SVG to parse "correctly" when pasted into HTML. However when actually talking to the SVG WG, they say they prefer to have consistent parsing between HTML and SVG <script>/<style> too. This remains true even after explaining in which situations existing SVG markup couldn't be pasted into HTML markup. / Jonas
Received on Friday, 11 November 2011 10:14:24 UTC