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
(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
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
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
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