Re: innerHTML in DocumentFragment

On Thu, Nov 3, 2011 at 4:03 PM, Yehuda Katz <wycats@gmail.com> wrote:
> It would be useful if there was a way to take a String of HTML and parse it
> into a document fragment. This should work even if the HTML string contains
> elements that are invalid in the "in body" insertion mode.
> Something like this code should work:
>   var frag = document.createDocumentFragment();
>   frag.innerHTML = "<tr><td>hello</td></tr>"
>   someTable.appendChild(frag)
> At present, this can sometimes be achieved if the context of the HTML string
> is known in advance. However, this is not always the case. For instance,
> jQuery supplies an API that looks like this:
>   $("html string").appendTo("#table")
> At the time that jQuery is creating the document fragment for the HTML
> string, it does not yet know what its context will be. This approach is used
> in order to enable convenient setup code. Here is a very contrived example
> to illustrate the point:
>   var frag = $("html string")
>   // replace the HTML content of a descendent <span> with the contents of
> its data-title attribute
>   frag.find("span[data-title]").html(function() { return
> this.attr("data-title"); })
>   html.appendTo("#table")
> In general, this makes it easier to build abstractions that work with
> Strings of HTML, without always needing to make sure consumers of the
> abstraction know and pass in the existing context.
> This would probably require a new, laxer insertion mode, which would behave
> similarly to the body insertion mode, but with different semantics in the "A
> start tag whose tag name is one of: "caption", "col", "colgroup", "frame",
> "head", "tbody", "td", "tfoot", "th", "thead", "tr"" case. One way to handle
> those cases would be to immediately enter an appropriate insertion mode if
> an unexpected tag was found. For instance, if a start tr tag was encountered
> "at the root", the parser could go into "in table" or "in table body"
> insertion mode instead of treating it like a parse error and ignoring the
> token.

This sounds good to me. I actually thought that we already had
something like this.

No matter what, we'll need a definition for how to do context-less
parsing sometime in the future in order to support html quasi-literals
per ES6 [1].

But we also need this short-term in order to support better developer
ergonomics as well as to support existing library APIs.

[1] http://wiki.ecmascript.org/doku.php?id=harmony:quasis

/ Jonas

Received on Friday, 4 November 2011 00:14:06 UTC