W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2013

[whatwg] Form-associated elements and the parser

From: Adam Klein <adamk@chromium.org>
Date: Tue, 6 Aug 2013 14:01:43 -0700
Message-ID: <CAEvLGcJMUTFVcjzfKRALvZYqt2HDAtznbWmOZQ_Ecs_kHkOc=g@mail.gmail.com>
To: WHATWG List <whatwg@whatwg.org>
Cc: Kent Tamura <tkent@chromium.org>, Ryosuke Niwa <rniwa@webkit.org>
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
Received on Tuesday, 6 August 2013 21:02:09 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:23 UTC