- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 12 Sep 2007 10:22:21 -0700
- To: Ian Hickson <ian@hixie.ch>
- Cc: Boris Zbarsky <bzbarsky@MIT.EDU>, "public-html@w3.org" <public-html@w3.org>
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">. Regards, Maciej
Received on Wednesday, 12 September 2007 17:22:37 UTC