[whatwg] Form-associated elements and the parser

[Jonas Sicking]

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.

/ Jonas

/ Jonas

On Tue, Aug 6, 2013 at 2:01 PM, Adam Klein <adamk at 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