- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Fri, 7 Sep 2007 12:05:57 +0300
- To: Ian Hickson <ian@hixie.ch>
- Cc: Boris Zbarsky <bzbarsky@MIT.EDU>, "public-html@w3.org" <public-html@w3.org>
On Sep 5, 2007, at 05:36, 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. I agree on the slope being slippery but... > This scares me, as it immediately precludes a significant possible > set of optimisations. What kind of optimizations? I'm currently interning element names in the tokenizer and then comparing the memory addresses in the tree builder. The obvious next optimization step would be assigning a carefully-crafted element group enumeration to each tag token in a custom interning function so that the tree builder could dispatch on groups of similar elements instead of testing for each element name. If there were such a group enumeration, the tokenizer could associate a different group value to hidden inputs and the other inputs. >> Thoughts? > > Would it be possible to instead make the <input> elements remember > their > parse order and use that during submission? This would add more secret data (data not exposed through the API) to the DOM nodes. Now the only anomalies are the document mode and the form pointer. Do we really want to go down the road of adding more? -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Friday, 7 September 2007 09:06:19 UTC