This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
e.g. #data <body><template><tr></tr><template></template><td></td></template> #errors #document | <html> | <head> | <body> | <template> | #document-fragment | <tr> | <template> | #document-fragment | <td> I actually don't have an opinion as to whether this is a bug, I just wanted to call it out (and I'm including the above in the initial webkit patch). In order to enforce a *single* implied context, a stack of template->contextTagNames would need to be kept along side the stack of open elements. I kind of feel like its added complexity and there's no obvious harm to the above behavior. Opinions?
After thinking more about this, I think it's worth adding a bit more logic to the parser to ensure that, for any given parse, each template element has at most one implied context. Here's the case which convinced me: Consider the following, which seems totally reasonable: #data <body><template><thead></thead><tr></tr><tfoot></tfoot></template> #errors #document | <html> | <head> | <body> | <template> | #document-fragment | <thead> | <tbody> | <tr> | <tfoot> Now insert a template after the <thead> #data <body><template><thead></thead><template></template><tr></tr><tfoot></tfoot></template> #errors #document | <html> | <head> | <body> | <template> | #document-fragment | <thead> | <template> | #document-fragment | <tr> (i.e. because the implied element became <tbody> after the inner template was popped, the <tfoot> got thrown away. ----- I propose that the parser maintain a map of open template elements to implied context tag. In Template Contents Mode, when the insertion mode gets set to something else, the corresponding tagName is set as the implied context tag for the template element. In resetInsertionModeAppropriately, if the current node is a template tag and it has a mapped context tag already, use that to set the insertion mode, otherwise set it to In Template Contents mode.
This has been fixed as per Rafael's suggestion in WebKit in http://trac.webkit.org/changeset/138059
http://dvcs.w3.org/hg/webcomponents/rev/281c9049bf2f