- From: <keshlam@us.ibm.com>
- Date: Mon, 4 Oct 1999 17:00:02 -0400
- To: steve@rsv.ricoh.com (Stephen R. Savitzky)
- cc: www-dom@w3.org
So far, ASP syntax is the best argument I've heard for extending the node types. I still don't like the idea -- the risk of breaking code that runs under "real" DOMs seems excessive to me, and I'm not sure I really feel compelled to support all the prior-art kluges that relied on browser toleration of poorly-formed HTML -- but at least this one makes some sense to me as an actual insertion into the document. Parsing the content of a <script> _doesn't_ do it for me. That's string content, as far as the document itself is concerned. If you want to preparse it and hang the parse tree off the side of that node, great... but in my opinion that's clearly outside the DOM's scope. Re low-memory/large-document: Remember that the DOM is only an API; how the data is stored behind it is up to the implementation. There is room for cleverness and tradeoffs here. I just went through such an experiment; I admit that what I came up with isn't a full DOM, but it could be made so if I was willing to grow the nodes just slightly; it performs abysmally at some tasks, but it shoud be small and fast at the ones it's intended for. (I'm waiting for user feedback.) As Steve said, there is no "_THE_ DOM" -- there are many legitimate implementations, tuned for different needs, and there will also be tasks for which a document model other than the DOM is the best answer. ______________________________________ Joe Kesselman / IBM Research
Received on Monday, 4 October 1999 17:03:43 UTC