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 24017 - template is not in ancestor chain for template contents in "Parsing HTML fragments" algorithm
Summary: template is not in ancestor chain for template contents in "Parsing HTML frag...
Status: RESOLVED FIXED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-06 06:02 UTC by William Chen
Modified: 2013-12-10 22:50 UTC (History)
4 users (show)

See Also:

Attachments

Description William Chen 2013-12-06 06:02:41 UTC 
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#parsing-html-fragments

In the "Parsing HTML fragments" step 4, sub-step 7, it says:

"[...] (If there is no such form element, or if there's a template element in the ancestor chain, the form element pointer keeps its initial value, null.)"

It looks like the intent is to make sure that the form pointer is null for descendents of template contents. However, the ancestor chain of those descendents will not contain the hosting template element. It will contain the the template content document fragment (at the root).
Comment 1 Ian 'Hixie' Hickson 2013-12-06 18:28:07 UTC 
Hm. I guess there's no way to know from just looking at a node whether or not the node is template contents, huh. I wonder how to fix this.
Comment 2 William Chen 2013-12-06 18:35:33 UTC 
(In reply to Ian 'Hixie' Hickson from comment #1)
> Hm. I guess there's no way to know from just looking at a node whether or
> not the node is template contents, huh. I wonder how to fix this.

You can get to the template content document fragment by walking up to the root and you can check the host (http://dom.spec.whatwg.org/#concept-documentfragment-host) to see if it is a template element.
Comment 3 Ian 'Hixie' Hickson 2013-12-06 18:46:55 UTC 
Ah, interesting. Thanks.
Comment 4 Ian 'Hixie' Hickson 2013-12-09 21:17:28 UTC 
On further reflection, I removed the special-casing of <template> there. It doesn't make any sense if you think about it, because if the innerHTML contents _do_ include a <form>, the form element pointer gets set and everything — the parser logic doesn't know it's in a template there.

This does mean we're in a weird spot here, where this:

   <form><template><form><form>

...parses differently than the similar case where a <template> element's contents are set to "<form><form>" using innerHTML.
Comment 5 contributor 2013-12-10 22:50:06 UTC 
Checked in as WHATWG revision r8337.
Check-in comment: innerHTML on template contents works like outside templates, when it comes to forms.
http://html5.org/tools/web-apps-tracker?from=8336&to=8337