This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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)
[[ 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.
Rafael, any opinion? Seems like something we should fix, to me.
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> ?
Yes.
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?
Consistency with <script> et al, yeah.
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 =-(.
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.
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.
Tony, Travis, do you have any opinions on whether we should make this change?
Replied in the other bug (in favor of this change).
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
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.
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.
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).
What do you consider making a decision about parsing based on the state in the document here?
checking the head element pointer. are we sure we'll always check the *right* document?
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?
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.
We should test this case too: <body></body><template>
@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).
So should I try doing what comment 14 suggests?
Let me try it blink before you spend time on specing it. I'll post the patch here.
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.
Ok. Done. Let me know if I missed anything.
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
lgtm