- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Wed, 4 Jun 2008 16:57:06 +0300
- To: elharo@metalab.unc.edu
- Cc: "public-html@w3.org WG" <public-html@w3.org>, www-tag@w3.org
On Jun 4, 2008, at 16:17, Elliotte Harold wrote: > And of all the things XML has brought to the table, about the only > one I can think of that is worse than namespaces is DOM. It's ugly, > inconsistent, memory-intensive, slow, thoroughly despised by users, > and frankly just hideous. I'm not a fan of the design of the DOM, either. In non-browser applications, people have the luxury of writing their own XML tree models like you and I both have done. In the case of browsers, though, the DOM is both the data model and the API, and the model and API is shared across implementations and has tons of scripts written against it. The value of having different browsers implement the same model and API and the code out there written against the API is so great that the DOM isn't going to go away in browsers. Trying to fix the DOM would probably do more harm that letting it be the way it is across browser code bases and the time axis inside a browser code base. > To define a single model while allowing many different syntaxes is > precisely the opposite of what XML is about, and why XML has > succeeded. It may be so in XML language design that doesn't target browsers, but in the case of designing languages that are primarily meant for sending content to browsers ((X)HTML, SVG and MathML), the purpose of the bytes on the wire is to get parsed into DOM. The scripting, style and rendering systems operate on the DOM data model. It is feasible to swap the parser from underneath a dynamic SVG renderer to an HTML5 parser or to an EXI parser, but changing the tree model to something would not be feasible considering all the code that has been written to operate on the DOM (including scripting libraries "out there" beyond the browser's own code base). Even the XPath view to the data has to be implemented on top of the DOM model with its quirks. Therefore, browser-targeted languages should be considered to be defined in terms of the DOM. Ignoring the DOM doesn't work. "Fixing" the DOM doesn't work, either, where existing code expects the DOM to behave as it behaves now. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Wednesday, 4 June 2008 13:57:50 UTC