Would be great to get deeper review of the spec above before I try to merge this into the HTML parser spec proper.

Do we have any interest in implementing this in the near future from non-WebKit vendors yet?

We are looking into implementing this in Gecko.

Henri, James: 

Have you guys had a chance to review the parser changes in the spec? We'd love to get more eyes on that.

Also, note that we opened bugs for the additional changes (XHTML parsing, XDM/XSLT/XPATH changes) we settled on at TPAC. It's on my schedule this week to dig into those.

Rafael: You said this was ready, right?

yup

https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html

*** Bug 22219 has been marked as a duplicate of this bug. ***

Going to wait until I've done 22322 before doing this.

(In reply to comment #10)
> Going to wait until I've done 22322 before doing this.

Actually I got started on this barely a few hours before this comment. I've checked the template import into the GH repo:

https://github.com/w3c/html/commit/2502feb541063a3834f1ef07e2a23d0824d96914
https://github.com/w3c/html/commit/daaf6bc1e76365b6678a14b47954bcf9c5db54c6

I reckon that it might be simpler to incorporate first so that the 22322 just apply to all of it.

Oh, cool, thanks!

Is it ok to use those patches in the WHATWG copy? (i.e. does the W3C put those patches in the public domain or equivalent?) (I presume yes, but just making sure so we don't end up with a political quagmire later...)

https://github.com/w3c/html/commit/845afeeb1cd52fa58a8c5de405ebbfd51af860f2

(In reply to comment #12)
> Oh, cool, thanks!
> 
> Is it ok to use those patches in the WHATWG copy? (i.e. does the W3C put
> those patches in the public domain or equivalent?) (I presume yes, but just
> making sure so we don't end up with a political quagmire later...)

I reckon it falls under fair use :)

If there's fallout, I'll take it.

Right-o, thanks.

I'll do this once Rafael's reviewed the patch. Rather than waiting for bug 22322 to be done, I'll do this first, that way it minimises the delta before merging.

(In reply to comment #15)
> Right-o, thanks.
> 
> I'll do this once Rafael's reviewed the patch. Rather than waiting for bug
> 22322 to be done, I'll do this first, that way it minimises the delta before
> merging.

I reckon this set of changes addresses Rafael's comments:

https://github.com/w3c/html/compare/89f7ed47d5c10b41da28b37bb224fb92e368d0d8...ced939ba849a4a30645e7916102b843cbf2d5482

LMK if it's good for you.

On a more general note, I'd be interested in knowing if this works for you coordination-wise for largish changes like this one.

changes lgtm.

I ended up not being able to use the diffs directly. I started doing so, but it left the spec with too many "comefrom"-style requirements, e.g. the foster parenting and the templating logic both trying to remote-control the insertion logic, and so on, which IMHO is just not workable (it was bad enough with just the foster parenting doing it, but having multiple spots trying to monkeypatch each other is too much). So I'm doing it manually from based on the doc by Tony and Rafael instead. Sorry about that. I'll try to make the changes match the diffs where this isn't an issue, though.

(In reply to comment #18)
> I ended up not being able to use the diffs directly. I started doing so, but
> it left the spec with too many "comefrom"-style requirements, e.g. the
> foster parenting and the templating logic both trying to remote-control the
> insertion logic, and so on, which IMHO is just not workable (it was bad
> enough with just the foster parenting doing it, but having multiple spots
> trying to monkeypatch each other is too much). So I'm doing it manually from
> based on the doc by Tony and Rafael instead. Sorry about that. I'll try to
> make the changes match the diffs where this isn't an issue, though.

Fair enough. That said, I reckon it's worth checking your changes against mine since I caught a few bugs along the way. Most were small, but at least one was of the kind that slips through easily (the additions to "in table" and "in frameset", for the end-of-file token, the delta states "If the current node is the root html element" whereas it should be "If the current node is *NOT* the root html element"). I think that's the biggest, but I didn't think to keep track of what I fixed as I went along, and it'd be a shame if something like that resurfaced.

Noted, thanks for the heads-up.

Ok, I've merged in the <template> element into the WHATWG spec. Here are the notes I took while doing it (hopefully mostly complete, though I'm sure I missed some things). As noted above, I ended up having to do this from scratch, because there were a lot of things that needed tighter integration with the HTML spec or just things that were inconsistent with the spec's style.

Editorial changes:
- "template contents" insertion mode renamed to "in template" for consistency
  with the other insertion modes.
- Avoided the indirection through the "html element scope" thing; instead I just
  said to look in the stack directly.
- Different terminology around the stack of template insertion modes, to avoid
  the mistake I made with the downwards-growing stack of open elements.
- Cleaned up the "reset the insertion mode" algorithm for processing <head>, and
  used the indigenous terminology rather than comparing the nodes directly.
- Made foster parenting and template off-document parsing an explicit part of
  the parser, rather than using internal "comefrom"-style monkeypatching.
- The precise place where I put some things was adjusted to be more consistent
  with the style of the spec. (For example, inserting markers into the 
  list of active formatting elements before inserting them into the DOM.)
- I didn't add the "template contents case" annotations. I think I'm going to
  remove all the fragment case annotations.
- I removed some more "fragment case" annotations, e.g. <template><td></td><tr>
  ignores the implied </tr>, which thus causes the <tr> to be ignored as well,
  even though there's no fragment case going on.
- I didn't change the end-of-file token handling. As far as I can tell, the
  proposed additions actually amounted to a no-op (except for the case of
  innerHTML on <template>, which was left undefined if I am reading it right).
- The AAA changes ended up being unnecessary due to earlier changes to the AAA
  logic to factor out the foster parenting. (I think...)
- I used a less complicated phrasing for the <template><col></colgroup> case.
- I simplified the description of EOF handling for the "in frameset",
  "in table", "in colgroup", and "in select" cases by just deferring to the
  rules for EOF in "in body".
- Simplified the "template contents"/"in template" insertion mode prose (e.g.
  didn't list "template" start tag twice, deferred to "in body" for more stuff).
- Fixed things like "a start tag whose name is" (should say "a start tag whose
  tag name is"), punctuation (sentences should end with a period), cross-
  references (e.g. insertion mode names should be linked), and so on, for 
  consistency with the rest of the spec.
- I phrased things in the XHTML section differently, for precision and clarity,
  and to avoid introducing new terms redundant with existing ones.
- Avoided some misuse of RFC2119 terms (e.g. "when something must, it must"
  doesn't really make any sense in an RFC2119 context, and using RFC2119 terms
  in a non-normative section is nonsensical).
- Revamped the way "template contents" is initialised so that it's just one
  algorithm and so that it's consistent with the style of the rest of the spec.

Normative changes:
- Added "template" to the list of things that end the "has an element in scope" 
  algorithm (also affects button and list item scope). See also bug 22482.
     http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2373 *
     http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2375 *
- Made the ownerDocument requirement apply to children of elements in templates
  as well, not just children of the template, so that all nodes in a template
  are created and remain inert.
- Made foster parenting when there's a <table> in a <template> go above the 
  <table>, not below it, for consistency with the non-template case.
     http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2376 *
- Made the "reset the insertion mode" algorithm detect when it should reset to
  "in select in table" rather than just "in select". See also bug 22484.
     http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2374 *#
- The "in select" mode needed work for its end-of-file token handling.
- I've dumped <frameset> support. The <template> spec didn't support it
  fully anyway (there were weird bugs like <template><frame><frameset>
  </frameset> not closing the nested frameset, <template><frame> working but
  <template><frameset> not), and the elements involved have been deprecated for
  over a decade. As part of this I made <template> trigger the frameset-ok flag,
  so that <body><template></template><frameset> doesn't blow away the template;
  and I removed "frame" from the list of tokens handled in the "in template"
  mode. See also bug 22486.
- Made the <template> fragment case handle EOF by calling "stop parsing".
- Added base, basefont, bgsound, noframes, and title to the list of elements
  that don't imply in-body parsing in <template>. See also bug 22501.
- I made the content model of <template> be more specific, so that things like:
   <template><col><select></template>
  ...are not valid (since they would not parse as expected).
- Allowed <template> to be used in non-flow/non-metadata elements like <table>
  or <select>.
- Adjusted a bunch of stuff relating to content models and syntax to make them
  work with the way <template> holds things off-document (e.g. see the term
  'contents' at #concept-html-contents).

(Tests marked "*" are those where Firefox implemented the spec as it was, and will need to change to match these changes. "#" indicates the same but for Chrome.)

I'm sure I made lots of mistakes, so if anyone wants to review this, I would be most grateful. :-)

Note that I didn't attempt to address bug 16153, and bug 21293 still exists (though it's not quite as bad as described given the way I phrased the spec), but that'll get fixed when I fix bug 21292, which should be relatively soon (hopefully next week or the week after).

Checked in as WHATWG revision r8000.
Check-in comment: Integrate <template> into HTML.
http://html5.org/tools/web-apps-tracker?from=7999&to=8000