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

Re: innerHTML in DocumentFragment

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 10 Nov 2011 08:23:07 -0800
Message-ID: <CAAWBYDCoZFA9wYYH0bQ5gJiMySE4ueJu9T0u0V2jAMQ+eL6WRg@mail.gmail.com>
To: Henri Sivonen <hsivonen@iki.fi>
Cc: public-webapps WG <public-webapps@w3.org>
On Thu, Nov 10, 2011 at 5:54 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
> On Thu, Nov 10, 2011 at 2:05 PM, Yehuda Katz <wycats@gmail.com> wrote:
>> My thinking on this has evolved a bit since my original post. I wrote a
>> patch to the spec that creates a new "unknown context" insertion mode that,
>> in fact, only affects the problematic table case, and otherwise delegates to
>> the in-body insertion mode.
>> You can see it in full glory
>> at http://www.w3.org/Bugs/Public/show_bug.cgi?id=14694
>> Please let me know if that doesn't clear it up for you :)
> What's your rationale for adding DWIM for those particular elements as
> opposed to adding DWIM for all elements?
> I don't want to add DWIM to support <html>, <frameset>, etc., but I'd
> like to have good confidence that the selection of elements that we
> add DWIM support for is the right set (neither too broad to drive up
> implementation cost without use cases nor too narrow to end up needing
> whack-a-mole tweaking later).

Those are the sum total of in-body elements that need special handling
to work properly.  The only other elements are the page-structure
ones, which I don't believe have any use-cases, as there's only one of
them for <html>, <head>, and <body> and they already exist, or they're
obsolete in the case of <frame> and <frameset> and don't need to be
handled specially.

SVG and MathML fragments need to be handled properly, though, as
they're currently misparsed as HTMLUnknownElement.

Received on Thursday, 10 November 2011 16:23:56 UTC

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