I sent this to Ian a looong while ago following an answer of his to my original post, I'm not sure how relevant it is nowadays but I figured I'd post it up on the public mailing list (where it was meant to belong).

(About section 4.10.18 Association of controls and forms currently in latest Revision 1.4001)


thanks you for your explanations and details.
After reading that my suggestions would be welcome to improve the readability of this section about the "nested forms or not" matter, I spent some thinking about it. I couldn't find any smart twist that I'm fully satisfied with, so instead of that, I'll report bellow the best I could come up with, introduced by the few points that my time spent on the matter made clearer to me.

Starting by "de-briefing" why I was confused when I first read this section, I pointed out to myself this was because I had the point of view of an author and so was more focused on the side matter of the possibility to nest forms, rather than the subject itself which clearly is focused on user agent behaviour. This first observation led me to the following points :
- Whatever the point of view when reading the section, meeting occurrences of "nearest ancestor" in the text raises questions.
- An answer to why the word "nearest" is needed only comes at the end of the section, with the (very instructive) example.
- Although the "nested forms" matter is closely related to the reset form owner algorithm, and readability would benefit from a bit of prose about it, it is off-topic in the section. And on the topic, associating form-associated elements with a form owner, the section says what it should.

>From that last point I'd say there's room only for a "Note". I think it should be placed after the second paragraph of the section, because this upper 'zone' is still about defining terms and presenting the relation between form owners and form-associated elements. Also placing it here makes it come right after the first occurrence of "nearest ancestor", thus clarifying the need for it from the start, having the matter cleared away for the rest of the reading.

Now about what the "Note" should say, I think the clearest explanation is the one you gave me: "...but we still have to define what happens when it happens because it _is_ possible to do it (e.g. in XML or with the DOM, or with some obscure cases in the parser).".
That would give a note that may read:
"Note: Nesting forms is not conforming, but cases can occur from scripts or other where an element have more than one form element ancestor. The form element a form-associated element is associated with by default is always its nearest ancestor form element."
"Note: Even though nested forms are not conforming, user agents must consider such cases possible, and make the form element a form-associated element is associated with by default be the nearest ancestor among its form element ancestors."
(I'm not too sure about mentioning user agent behaviour so early in the section, as it quite doesn't belong in the midst of defining specification terms.)

I hope this long message actually brings something, and that my point of view about this section is fit to improve its ease to read and comprehend.
Lobotom Dysmon