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 01:44:10 -0800
Message-ID: <CA+c2ei_fvK-0QVFzuFSj_BNeTS_-VoF2pKF0xJ608PA7BXJWLg@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:48 GMT