Re: innerHTML in DocumentFragment

On Fri, Nov 11, 2011 at 3:42 AM, Henri Sivonen <hsivonen@iki.fi> wrote:
> 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.

That fails the main requirement in the initial email. Being able to
implement a function that doesn't require context but still can parse
markup to be inserted into the page.

We have also identified one possible future API where this will be
needed: When/if we add support for a html-parsing ES.next
quasi-literal.

Another use case that I realized earlier today is the need for the
same thing when parsing the contents of a <template> element.

The functionality here is the important thing, the exact syntax is
something we can debate separately.

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

This is a goal that we can easily archive no matter what.

>> 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.

This just moves the complexity from UA authors to library authors and
web authors. I don't think that is a win.

>> 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?)

I'm saying that this is what we do today. Note that my example doesn't
set innerHTML on a DocumentFragment, but on a <table> element.

However trying this out in Gecko it appears that we simply insert the
<div> as a direct child of the <table> element. So I retract this
point as it is moot.

/ Jonas

Received on Tuesday, 15 November 2011 02:03:43 UTC