On Tue, Aug 6, 2013 at 4:21 PM, Jonas Sicking <jo...@sicking.cc> wrote: > As I recall it (it was ages since I dealt with this), the tricky case > that you need to handle is this one: > > http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2432 > > In this case, web compatibility requires that the <input> is > associated with the form. Specifically hidden <input> elements would > often end up moved, but still had to show up in form.elements as well > as get submitted along with the form.
That case definitely makes sense to me, and I think it's fine to keep that behavior for compat. The only one I'm asking to change is the case when the <input> and <form> end up in different trees. > On Tue, Aug 6, 2013 at 2:01 PM, Adam Klein <ad...@chromium.org> wrote: >> 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