Re: innerHTML in DocumentFragment

On Thu, Nov 10, 2011 at 7:32 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> I don't think we should make up rules for where it makes sense to
> insert DOM and where it doesn't. After all, we support .innerHTML on
> all HTML elements (and soon maybe all Elements), and not just a subset
> of them, right?

Yes, but with innerHTML on elements, we always have a context node, so
there isn't magic DWIM involved.

But you don't need to look far to find special cases with difficult
elements: We also support createContextualFragment with all possible
contexts except we special-case things so that if the context is html
in the (X)HTML namespace, the behavior is as if the context had been
body in the (X)HTML namespace.

On reasonable view is that solutions should always be complete and
make sense (for some notion of making sense) for all inputs. Another
reasonable view is that we shouldn't do anything with "for compleness"
as the rationale and that everything that needs notable additional
engineering needs to be justified by use cases. If no one really wants
to use DWIM parsing to create a DocumentFragment that has the html
element in the (X)HTML namespace as its child, why put the engineering
effort into supporting such a case?

Currently, per spec (and Ragnarök, Chrome and Firefox comply and
interoperate), if you take take an HTML document that has head and
body (as normal) and assign document.body.outerHTML =
document.body.outerHTML, you get an extra head so that the document
has 2 heads. Would you expend engineering effort, for the sake of
making sense in all cases for completeness, to get rid of the extra
head even though there are likely no use cases and 3 out of 4 engines
interoperate while complying with the spec?

> And requiring that a context node is passed in in all cases when HTML
> is parsed is terrible developer ergonomics.

One possibility is that instead of adding innerHTML to
DocumentFragment, we add three methods to Document:
DocumentFragment parseFragment(DOMString htmlMarkup);
DocumentFragment parseSvgFragment(DOMString svgMarkup);
DocumentFragment parseMathFragment(DOMString mathmlMarkup);

parseFragment would do roughly the kind of DWIM Yehuda suggested. That
is, you'd get to use <tr> with it but not <html>. parseSvgFragment
would invoke the HTML fragment parsing algorithm with svg in the SVG
namespace as the context. parseMathFragment would invoke the HTML
fragment parsing algorithm with math in the MathML namespace as the
context.

As a bonus, developers would need to call createDocumentFragement() first.

> frag.innerHTML = "<g></g>";
> someSVGElement.appendChild(frag);
>
> seems very possible to make work

Making it work is a problem with <a>.

I think we should have three DocumentFragment-returning parsing
methods instead of packing a lot of magic into innerHTML on
DocumentFragment, when having to obtain a DocumentFragment first and
filling it as a separate step sucks as far as developer ergonomics go.

> someTableElement.innerHTML = "<tr>...</tr><div></div>";
>
> will just drop the div on the floor.

By what mechanism? (It didn't implement and run Yehuda's suggestion,
but I'm pretty sure it wouldn't drop the div. Why would we put
additional effort into dropping the div?)

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Friday, 11 November 2011 11:43:21 UTC