Re: innerHTML in DocumentFragment

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.

~TJ

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