This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 23002 - Hoist <template> to head when found between </head> and <body> for consistency with <script>
Summary: Hoist <template> to head when found between </head> and <body> for consistenc...
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P1 blocker
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
Depends on:
Blocks: 23032
  Show dependency treegraph
Reported: 2013-08-18 20:44 UTC by contributor
Modified: 2013-10-10 00:38 UTC (History)
7 users (show)

See Also:


Description contributor 2013-08-18 20:44:35 UTC

Hoist <template> to head?

Posted from:
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)
Comment 1 Simon Pieters 2013-08-18 20:45:43 UTC
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.
Comment 2 Ian 'Hixie' Hickson 2013-08-20 17:53:07 UTC
Rafael, any opinion?

Seems like something we should fix, to me.
Comment 3 Rafael Weinstein 2013-08-20 18:37:16 UTC
Just so I'm clear, we're talking about how



i.e. right now it will be


and you're saying maybe it should be


Comment 4 Simon Pieters 2013-08-20 19:05:28 UTC
Comment 5 Rafael Weinstein 2013-08-20 19:16:58 UTC
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?
Comment 6 Simon Pieters 2013-08-20 19:33:55 UTC
Consistency with <script> et al, yeah.
Comment 7 Rafael Weinstein 2013-08-20 21:54:49 UTC
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 =-(.
Comment 8 Simon Pieters 2013-08-21 11:40:44 UTC
Made a clone

I don't know what their addresses in bugzilla are so I haven't cc-ed them.
Comment 9 Simon Pieters 2013-08-21 11:50:54 UTC
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.
Comment 10 Ian 'Hixie' Hickson 2013-08-22 20:21:03 UTC
Tony, Travis, do you have any opinions on whether we should make this change?
Comment 11 Travis Leithead [MSFT] 2013-08-22 21:05:12 UTC
Replied in the other bug (in favor of this change).
Comment 12 contributor 2013-09-12 20:25:30 UTC
Checked in as WHATWG revision r8179.
Check-in comment: Have </head><template></template> go in the <head> for consistency with other elements.
Comment 13 Rafael Weinstein 2013-09-30 23:33:13 UTC
Ok. Sorry, I'm just now getting around to trying to implement this in blink, and there's a problem here.



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.
Comment 14 Ian 'Hixie' Hickson 2013-10-01 17:51:01 UTC
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.
Comment 15 Rafael Weinstein 2013-10-01 18:00:06 UTC
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).
Comment 16 Ian 'Hixie' Hickson 2013-10-01 20:28:53 UTC
What do you consider making a decision about parsing based on the state in the document here?
Comment 17 Rafael Weinstein 2013-10-01 23:08:30 UTC
checking the head element pointer. are we sure we'll always check the *right* document?
Comment 18 Ian 'Hixie' Hickson 2013-10-02 21:01:58 UTC
The head element pointer is parser state, not document state. It's similar to the form element pointer.

Does that change your conclusion?
Comment 19 Rafael Weinstein 2013-10-02 21:08:57 UTC
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.
Comment 20 Adam Barth 2013-10-02 21:10:47 UTC
We should test this case too:

Comment 21 Rafael Weinstein 2013-10-02 21:28:22 UTC
@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).
Comment 22 Ian 'Hixie' Hickson 2013-10-03 19:00:49 UTC
So should I try doing what comment 14 suggests?
Comment 23 Rafael Weinstein 2013-10-03 19:04:08 UTC
Let me try it blink before you spend time on specing it. I'll post the patch here.
Comment 24 Rafael Weinstein 2013-10-08 03:09:50 UTC
Ok, this has landed in blink as

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.
Comment 25 Ian 'Hixie' Hickson 2013-10-09 22:33:42 UTC
Ok. Done. Let me know if I missed anything.
Comment 26 contributor 2013-10-09 22:35:06 UTC
Checked in as WHATWG revision r8218.
Check-in comment: Update the HTML parser to handle <html><head></head><template></template><!---->
Comment 27 Rafael Weinstein 2013-10-09 23:10:34 UTC