23002 2013-08-18 20:44:35 +0000 Hoist <template> to head when found between </head> and <body> for consistency with <script> 2013-10-10 00:38:08 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#the-after-head-insertion-mode P1 blocker Unsorted 23032 1 contributor ian ian mike rafaelw travil tross w3c zcorpan contributor oldest_to_newest 92245 0 contributor 2013-08-18 20:44:35 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html Multipage: http://www.whatwg.org/C#the-after-head-insertion-mode Complete: http://www.whatwg.org/c#the-after-head-insertion-mode Referrer: http://www.whatwg.org/specs/web-apps/current-work/multipage/ Comment: Hoist <template> to head? Posted from: 90.230.218.37 User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/29.0.1547.49 Safari/537.36 OPR/16.0.1196.45 (Edition Next) 92246 1 zcorpan 2013-08-18 20:45:43 +0000 [[ A start tag whose tag name is one of: "base", "basefont", "bgsound", "link", "meta", "noframes", "script", "style", "title" ]] <template> isn't in this list. Shouldn't it be? For all elements that can appear in head we hoist it to head if it appears after </head> but before the body. 92362 2 ian 2013-08-20 17:53:07 +0000 Rafael, any opinion? Seems like something we should fix, to me. 92375 3 rafaelw 2013-08-20 18:37:16 +0000 Just so I'm clear, we're talking about how <head></head><template> parses? i.e. right now it will be <html> <head> <body> <template> and you're saying maybe it should be <html> <head> <template> <body> ? 92376 4 zcorpan 2013-08-20 19:05:28 +0000 Yes. 92378 5 rafaelw 2013-08-20 19:16:58 +0000 I'm not against it -- although I'm a little fuzzy on what value it provides. Is it just consistency with elements which *can* appear in head...that we assume if they came after head but before body, we assume you meant head? 92381 6 zcorpan 2013-08-20 19:33:55 +0000 Consistency with <script> et al, yeah. 92391 7 rafaelw 2013-08-20 21:54:49 +0000 Meh. I'll let you guys decide. I'm happy to make the change in blink - depending. Also, it's worth getting travis & tony ross's opinion, but I think we'll need a w3c bug for that =-(. 92411 8 zcorpan 2013-08-21 11:40:44 +0000 Made a clone https://www.w3.org/Bugs/Public/show_bug.cgi?id=23032 I don't know what their addresses in bugzilla are so I haven't cc-ed them. 92412 9 zcorpan 2013-08-21 11:50:54 +0000 From #whatwg: <zcorpan> hsivonen: do you have an opinion on the above bug? <hsivonen> zcorpan: I don't care much either way, but it's weird not to be consistent with <script>. might be good to check with wchen. <zcorpan> seems unlikely anyone will have a strong opinion on this :-P <jgraham> I think "just do it" is the right approach. It doesn't seem like it should need explicit buy in from lots of people since it's such a small thing I agree with jgraham. 92472 10 ian 2013-08-22 20:21:03 +0000 Tony, Travis, do you have any opinions on whether we should make this change? 92480 11 travil 2013-08-22 21:05:12 +0000 Replied in the other bug (in favor of this change). 93311 12 contributor 2013-09-12 20:25:30 +0000 Checked in as WHATWG revision r8179. Check-in comment: Have </head><template></template> go in the <head> for consistency with other elements. http://html5.org/tools/web-apps-tracker?from=8178&to=8179 94049 13 rafaelw 2013-09-30 23:33:13 +0000 Ok. Sorry, I'm just now getting around to trying to implement this in blink, and there's a problem here. consider: <head></head><template> This example actually breaks the current parser (as spec'd). -The <template> is now handled by "after head" which pushes the <head> back on, processes the <template> for "in head", then pops the <head> off. -EOF is reached, which processes a fake "</template>", which pops the <template> off and -resets the insertion mode appropriately The problem here is that "reset the insertion mode" is going to inspect the bottom-most element on the stack which is now <html> and it will set the mode to "before head". Nothing good happens after this. Unless someone has a simple fix for this that I'm missing, I'm inclined to back out this spec change and just live without <template> getting hoisted into <head> if it appears immediately after </head>. I think the benefit is questionable and the problem it's causing is fairly bad. 94095 14 ian 2013-10-01 17:51:01 +0000 That example is fine since it's an EOF, nothing happens. But it's true that <html><head></head><template></template><head> ends up crazy. We could handle this by having the reset algorithm check if the head element pointer is set, and if so, go to after head instead of before head, I think. 94096 15 rafaelw 2013-10-01 18:00:06 +0000 Is there any where else in the parser that we make decisions about parsing based on state in the document (as opposed to the stack of open elements)? My mental model is that the parser operates on an incoming stream and the stack of open elements (whose elements may or may not, at any given time, still be in the document they started in). 94109 16 ian 2013-10-01 20:28:53 +0000 What do you consider making a decision about parsing based on the state in the document here? 94128 17 rafaelw 2013-10-01 23:08:30 +0000 checking the head element pointer. are we sure we'll always check the *right* document? 94206 18 ian 2013-10-02 21:01:58 +0000 The head element pointer is parser state, not document state. It's similar to the form element pointer. http://whatwg.org/html/#the-element-pointers Does that change your conclusion? 94208 19 rafaelw 2013-10-02 21:08:57 +0000 I guess it's no grosser than it already is (because in order to do this we push that head pointer element onto the stack). Adding adam since he shared my reluctance. 94209 20 w3c 2013-10-02 21:10:47 +0000 We should test this case too: <body></body><template> 94211 21 rafaelw 2013-10-02 21:28:22 +0000 @adam: <body></body><template> is fine since AfterBody defers to InBody for "anything else" (and </body> doesn't pop the <body> element), but I've added a test to html5lib in blink (which I'll shortly upstream). 94257 22 ian 2013-10-03 19:00:49 +0000 So should I try doing what comment 14 suggests? 94260 23 rafaelw 2013-10-03 19:04:08 +0000 Let me try it blink before you spend time on specing it. I'll post the patch here. 94443 24 rafaelw 2013-10-08 03:09:50 +0000 Ok, this has landed in blink as https://src.chromium.org/viewvc/blink?revision=159064&view=revision. Note that the above change implies not only the current language in "After Head" which includes "template" amongst the start tags which are hoisted into <head>, it also implies: -Reset the insertion mode appropriate, step 3 should no longer be marked as "fragment case" -Reset the insertion mode appropriately, step 15 should check the head element pointer, switching to "After Head" if it is set and "Before Head" if not, and aborting the steps in either case. 94524 25 ian 2013-10-09 22:33:42 +0000 Ok. Done. Let me know if I missed anything. 94525 26 contributor 2013-10-09 22:35:06 +0000 Checked in as WHATWG revision r8218. Check-in comment: Update the HTML parser to handle <html><head></head><template></template> http://html5.org/tools/web-apps-tracker?from=8217&to=8218 94527 27 rafaelw 2013-10-09 23:10:34 +0000 lgtm