This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This was was cloned from bug 16789 as part of operation convergence. Originally filed: 2012-04-18 18:30:00 +0000 ================================================================================ #0 contributor@whatwg.org 2012-04-18 18:30:49 +0000 -------------------------------------------------------------------------------- Specification: http://www.whatwg.org/specs/web-apps/current-work/ Multipage: http://www.whatwg.org/C#tree-construction Complete: http://www.whatwg.org/c#tree-construction Comment: specify parsing of the template element Posted from: 2620:0:1002:1005:72cd:60ff:feab:f3a User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.24 Safari/536.5 ================================================================================ #1 Rafael Weinstein 2012-04-18 18:33:05 +0000 -------------------------------------------------------------------------------- For reference: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html#dfn-template ================================================================================
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