[whatwg] Form-associated elements and the parser

[Adam Klein]

Hixie opened my eyes last week to parser-association behavior of the
sort found at http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2428.
In that case, an <input> in a detached tree is associated with a
<form> in the main document. This causes badness in WebKit and Blink
because the association between the <form> and the <input> (e.g., as
exposed in the HTMLFormElement.elements collection) is only weakly
held to avoid reference loops (and thus memory leaks). And that
weakness occasionally results in crashes when one of these objects is
collected before the other.

While all modern HTML parser implementations I tested seemed to agree
on their treatment of the above example (they all return "1" as
elements.length), this feature doesn't strike me as terribly useful.
And for what it's worth, it doesn't seem to be present in legacy IE.

I'm interested what others would think about changing the parser to
only associate a <form> with an <input> if both are in the same "home
subtree" (http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#home-subtree).
Or is there some deep web-compat reason for this parsing oddity?

- Adam