W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: innerHTML in DocumentFragment

From: Jonas Sicking <jonas@sicking.cc>
Date: Fri, 11 Nov 2011 02:11:49 -0800
Message-ID: <CA+c2ei96nmv5LhAPw9VXgJvFqjvGO961HmwDjzvJ6jtxs92wDg@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:36 UTC