22400 2013-06-18 21:00:21 +0000 [Templates]: Form-associated elements inside templates should not be associated with forms by the parser 2013-08-01 20:15:07 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - Component Model unspecified PC Linux RESOLVED FIXED P2 normal --- 15476 1 adamk ian dglazkov hsivonen ian rafaelw robin tross w3c wchen public-webapps-bugzilla oldest_to_newest 89506 0 adamk 2013-06-18 21:00:21 +0000 For markup such as (a) <form><template><input></template></form> or (b) <template><form><template><input></template></form></template> the spec currently requires that the <input> be associated with the <form>. But that is incorrect: in case (b), the form and input are in different trees. And in case (a), they are not even in the same document! The existing implementations in WebKit, Blink, and Gecko all make this "mistake". To correct it, I propose that the paragraph in the section on "Creating and inserting elements" (http://www.w3.org/html/wg/drafts/html/master/syntax.html#creating-and-inserting-elements) which currently reads: "If an element created by the insert an HTML element algorithm is a form-associated element, and the form element pointer is not null, and the newly created element doesn't have a form attribute, the user agent must associate the newly created element with the form element pointed to by the form element pointer when the element is inserted, instead of running the reset the form owner algorithm." have an additional clause added, requiring that the element has an ownerDocument with a browsing context. This will keep this special-casing of form association from taking place inside templates. I've implemented this in Blink in https://codereview.chromium.org/17033002/ (this misbehavior was causing some crashes, which is why I'm landing the code before a spec update). An alternate approach would have been to compare the <form>'s ownerDocument with the <input>, but that would lead to the wrong answer in case (b) above (since both <template>'s contents share the same browsing context-less document). 89539 1 rafaelw 2013-06-19 02:09:30 +0000 +1 90694 2 ian 2013-07-13 00:17:56 +0000 Note that it doesn't really much matter, since when the template is stamped out, the associations will be reset anyway, if I'm not mistaken. Anyway, I agree that it's unclean as is. I'm happy to update the spec if you want (the suggestion above seems reasonable at first glance). If you want me to take care of it, reassign the bug to me. 91519 3 ian 2013-08-01 18:18:49 +0000 This test shows that Chrome is not following the spec here, but Firefox is: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2424 91520 4 adamk 2013-08-01 18:43:02 +0000 (In reply to comment #3) > This test shows that Chrome is not following the spec here, but Firefox is: > > http://software.hixie.ch/utilities/js/live-dom-viewer/saved/2424 What output do you see when you run this in Chrome and Firefox? 91523 5 adamk 2013-08-01 19:53:41 +0000 To clarify: Chrome is already following the recommendation of this bug, while Firefox is not. Since I've heard no objections to changing the spec, assigning to Hixie for him to update it. 91525 6 contributor 2013-08-01 20:15:07 +0000 Checked in as WHATWG revision r8115. Check-in comment: Make <form><template><input> not result in the <input> being in the <form>. http://html5.org/tools/web-apps-tracker?from=8114&to=8115