Bug 14694 - innerHTML in DocumentFragment
Summary: innerHTML in DocumentFragment
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: DOM Parsing and Serialization (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Travis Leithead [MSFT]
QA Contact: public-webapps-bugzilla
Depends on:
Blocks: 15658
  Show dependency treegraph
Reported: 2011-11-04 14:36 UTC by Ms2ger
Modified: 2014-10-04 16:38 UTC (History)
12 users (show)

See Also:

Adds an "unknown context" insertion mode, that would be used when using innerHTML= on a document fragment (4.34 KB, patch)
2011-11-04 19:00 UTC, Yehuda Katz
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Comment 1 Yehuda Katz 2011-11-04 19:00:13 UTC
Created attachment 1042 [details]
Adds an "unknown context" insertion mode, that would be used when using innerHTML= on a document fragment
Comment 2 Anne 2011-11-05 16:52:14 UTC
We first need to add the insertion mode to the HTML parser, then it can be used in DOM Parsing.
Comment 3 Ms2ger 2011-11-06 20:31:37 UTC
Anne, this is a bug for my own tracking purposes. Please file another bug on HTML if you need one.
Comment 4 Dimitri Glazkov 2012-02-28 21:41:13 UTC
For those interested, I am working on this as part of the HTML templates spec.

See a slightly out-of-date spec here: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html#parsing

It's out of date because I then went to play with WebKit's HTML parser to make it do this, purely to learn more about parsing: https://bugs.webkit.org/show_bug.cgi?id=78734, which revealed a few more places that still need spec work.

Since that templates are defined as a vehicle to build document fragments declaratively, the DWIM insertion mode (called "template contents" mode in HTML Templates draft) effectively describes the behavior of DocumentFragment.prototype.set.

However for templates, there's also another degree of freedom of the context in which a <template> tag can appear.

I am ok with keeping both together or separate. Whatever makes things move faster. I have both time, energy, and now a bit of expertise to write the modifications. Just need a consensus on the path :)
Comment 5 Dimitri Glazkov 2012-03-08 00:25:04 UTC
A quick update: I went ahead and drafted up the changes to HTML parser based on my WebKit experiments: http://dvcs.w3.org/hg/webcomponents/raw-file/4e492832df60/spec/templates/index.html
Comment 6 Rafael Weinstein 2012-04-30 23:53:56 UTC
Current proposal (which doesn't presently have any detractors): http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0334.html

Summary: DF.innerHTML chooses an "implied context element" based on the first start tag in the provided HTML. This requires no changes to the parser.

Webkit patch here: http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0334.html
Comment 7 Rafael Weinstein 2012-11-28 18:55:41 UTC
I'm going to go ahead and close this one.

-We've got good consensus on the template element
-With it, DocumentFragment.innerHTML is a 4 or 5 line polyfill for those who choose to do that.
-Hixie made a strong case against adding explicit API for DF.innerHTML