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 20924 - [Templates]: processing an EOF token deep within a template which was opened in <head> may fail to run after-head work
Summary: [Templates]: processing an EOF token deep within a template which was opened ...
Status: RESOLVED FIXED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Component Model (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Dimitri Glazkov
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 15476
  Show dependency tree / graph
 
Reported: 2013-02-09 01:32 UTC by Rafael Weinstein
Modified: 2013-03-13 23:30 UTC (History)
7 users (show)

See Also:

Attachments

Description Rafael Weinstein 2013-02-09 01:32:48 UTC 
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?
Comment 1 Rafael Weinstein 2013-02-09 01:35:37 UTC 
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.
Comment 2 Rafael Weinstein 2013-02-09 02:34:23 UTC 
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.
Comment 3 William Chen 2013-02-11 23:40:17 UTC 
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.
Comment 4 Rafael Weinstein 2013-02-12 00:08:24 UTC 
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?
Comment 5 Rafael Weinstein 2013-02-28 21:42:50 UTC 
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.
Comment 6 Rafael Weinstein 2013-03-13 23:30:47 UTC 
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>).