[Bug 20924] New: [Templates]: processing an EOF token deep within a template which was opened in <head> may fail to run after-head work

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20924

            Bug ID: 20924
           Summary: [Templates]: processing an EOF token deep within a
                    template which was opened in <head> may fail to run
                    after-head work
    Classification: Unclassified
           Product: WebAppsWG
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Component Model
          Assignee: dglazkov@chromium.org
          Reporter: rafaelw@chromium.org
        QA Contact: public-webapps-bugzilla@w3.org
            Blocks: 15476

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?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Saturday, 9 February 2013 01:32:50 UTC