20924 2013-02-09 01:32:48 +0000 [Templates]: processing an EOF token deep within a template which was opened in <head> may fail to run after-head work 2013-03-13 23:30:47 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC All RESOLVED FIXED P2 normal --- 15476 1 rafaelw dglazkov adamk annevk dglazkov hsivonen ian tross wchen public-webapps-bugzilla oldest_to_newest 82816 0 rafaelw 2013-02-09 01:32:48 +0000 e.g. #data <template><div> #errors #document | <html> | <head> | <template> | #document-fragment | <div> | <body> With the current spec-text, the body element will fail to be produced because the EOF was reached in "in body" insertion mode which just stops parsing. We could obviously solve this by disallowing <template> inside of <head>, but I think the impacts the design consistency of <template> and possibly cuts off legitimate use cases. It seems like the right way to approach this is that the stack needs to unwind back past the first open template element, reset the insertion mode, and then reprocess the EOF token (thus if it was inside a <head> context, the parser will act as if </head> and <body> had been seen). Right now, "in cell", "in caption" defer to "in body" for EOF (as "anything else"), "in table body", "in row", and "in select in table" defer to "in table". So the logic to pop past the first open template can go into "in body" and "in table" when processing EOF. That leaves "in coloumn group" and "in frameset". It seems to me that "in column group" is table element, so it makes sense to make it defer to "in table" for EOF (its behavior is the same). "in frameset" has the same behavior as "in table", so it could either be spec'd independently, or defer to "in table", which might be a tad confusing (spec wise) since framesets aren't related to tables. Webkit will implement like the former, but I'm fine with the later. Thoughts? 82817 1 rafaelw 2013-02-09 01:35:37 +0000 Note that popping back to the first opened template is a matter of popping from the stack, removing a template insertion mode if the popped node was a template, stopping either when the node about to be popped is the root node, or when all template insertion modes have been popped. 82827 2 rafaelw 2013-02-09 02:34:23 +0000 Here's the webkit implementation of this: https://bugs.webkit.org/show_bug.cgi?id=109338 Note that this patch implements everything described in comments 0 & 1, AND in addition: For "in coloumn group", the rule for EOF must be: -If the current node is the root html element, then stop parsing. (fragment case) -Act as if an end tag with the tag name "colgroup" had been seen -*AND* defer to the rules for "in table" for encountering a EOF. 82932 3 wchen 2013-02-11 23:40:17 +0000 Another approach we can take is to generate an implicit </template> on EOF in the "template contents" mode. And then defer "in body", "in table", "in column group" and "in frameset" modes to "template contents" if in the "template contents case". The algorithm to handle </template> will pop the stack to the last template and it will generate parse errors for some weird looking markup. This should have the same tree output as the Rafael's solution because each nested template will pop the stack to the previous template until there are none left (instead of popping them all in one go). I think this solution is simpler because we don't create a new algorithm that does almost the same thing as </template>. Also, the spec is simpler because we don't need as much language, it's almost all just deferring cases to "template contents". I think it's also easier to understand that we are handling a quirk in templates when we defer to "template case" rather than to "in table" for column group and frameset. 82935 4 rafaelw 2013-02-12 00:08:24 +0000 Will makes a strong case for the conceptual cleanliness of his approach, and I'd be happy with it. My only question is about the behavioral difference. In his approach, we process the EOF for every parent of a <template>, as opposed to just the parent of the outer-most <template>. Anyone else have input here? 83841 5 rafaelw 2013-02-28 21:42:50 +0000 I talked live with Tony about this and he agrees that the difference between the two approaches wouldn't currently be observable, but that Will's approach to specification is preferable. I'm fine with this. I will update the spec to reflect Will's proposal. 84375 6 rafaelw 2013-03-13 23:30:47 +0000 Ok. I've made the changes that Will suggests here: https://dvcs.w3.org/hg/webcomponents/rev/2323115e29dd Note that the EOF handling for "in column group" now *always* defers to "in table". I believe this is simpler, and was always the case (the fake </colgroup> tag can't be ignored in this EOF case because the previous step established that the root node is not <html>).