Re: Question about mis-nested form controls and parsing

On Sep 4, 2007, at 7:36 PM, Ian Hickson wrote:

> On Sun, 2 Sep 2007, Boris Zbarsky wrote:
>> What we are considering doing right now is allowing <input  
>> type="hidden"> (but
>> not other kinds of inputs) to be direct children of TABLE, TBODY,  
>> and TR.
> This would be the first step down the slippery slope of making the  
> tree
> construction stage in the parser generate DOMs that depend on  
> attribute
> values rather than being exclusively based on tag names. This scares  
> me,
> as it immediately precludes a significant possible set of  
> optimisations.

For what it's worth, we also ran into a regression in WebKit when we  
stopped allowing <input type="hidden"> to be a direct child of table  
structure elements, on a different site than the one mentioned in the  
Mozilla bug. We will likely restore that parsing quirk, and I think it  
would be good to make the spec require it.

>> Thoughts?
> Would it be possible to instead make the <input> elements remember  
> their
> parse order and use that during submission? (e.g. when doing the  
> foster
> parenting of a form control, look at whatever the last form control  
> in the
> form is at that point, associate it with the one being foster- 
> parented,
> and when doing submission, we go in tree order but then insert the
> controls that have this flag after the ones they refer to (in tree  
> order
> if there are many with the same association, and if one is removed  
> from
> the list, we ignore the association).

That actually sounds more complicated to implement and more likely to  
interfere with potential optimizations than the special case for  
<input type="hidden">.


Received on Wednesday, 12 September 2007 17:22:37 UTC