W3C home > Mailing lists > Public > public-html-comments@w3.org > March 2010

Re: form owner - embedded forms or not ?

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 26 Mar 2010 07:04:09 +0000 (UTC)
To: Lobotom Dysmon <lobotom.da.dismon@free.fr>
Cc: public-html-comments@w3.org
Message-ID: <Pine.LNX.4.64.1003260645170.29348@ps20323.dreamhostps.com>
On Mon, 15 Feb 2010, Lobotom Dysmon wrote:
> my wonder is about the step 1 of the steps to be run by user agents for 
> resetting the form owner of a form-associated element, described in 
> section 4.10.16 :
> "1. If the element's form owner is not null, and the element's form 
> content attribute is not present, and the element's form owner is one of 
> the ancestors of the element after the change to the ancestor chain, 
> then do nothing, and abort these steps."
> At first I thought it missed "the element's form owner is the nearest 
> form ancestor of the element", but then realized that nesting form 
> elements wasn't conforming to begin with.
> Yet now I'm confused : should nested forms be considered just not 
> conforming and omitted in the above-mentioned algorithm? And if so, why 
> bother to define the default form owner as the "nearest ancestor form 
> element" at the top of the section.
> Should form elements be considered potentially nested, or not ?
> Unless I'm mistaken, I believe there are situations (consecutive 
> scripted ancestor changes) where this first step would allow a 
> form-associated element to remain associated with a form owner which is 
> actually not its nearest ancestor form element... And no form content 
> attribute to reflect or correct this. If so it could lead to cases where 
> there's no certainty about which form an element is associated with.

Indeed, this was a mistake. I have corrected the text you quote above.

However, I think in practice this makes no difference, because it's 
impossible currently to insert, move, or remove an ancestor without at 
some point making the form control element's form owner no longer be in 
the ancestor chain. This is because it is not possible to insert an 
element while moving children of the new element's new parent into the new 
element in one operation, nor is it possible to move elements from one 
element to another in one operation: one must always remove the elements 
to be moved from the true at some point.

> On the overall, I find the "nearest ancestor" versus "forms can't be 
> nested" duality is made rather unclear in the section

I'm not exactly sure how to make it simpler... If you have any suggestions 
I'm very open to them. We can't sanely allow forms to be nested because 
the parser makes that very difficult for historical reasons, 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 

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 26 March 2010 07:04:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:26:26 UTC