- From: Richard A. O'Keefe <ok@atlas.otago.ac.nz>
- Date: Wed, 23 May 2001 10:36:57 +1200 (NZST)
- To: Valeri.Atamaniouk@nokia.com, html-tidy@w3.org
Valeri.Atamaniouk@nokia.com wrote:
What about DOM core level 1 implementation? Actually tidy has it's
proprietary DOM tree but _may_ be it would be better to implement a standard
one? Tidy then could be splitted into following parts: DOM tree building
(input), DOM tree optimisation, DOM tree saving.
No. It would be a lot of work to make a good program *worse*.
Remember: the DOM was designed to provide scripting languages (Java and
Javascript) with access to the data structure used by a web browser (but
not TOO much access). It may well be adequate for that task. It falls
between two stools: it forces far too much accidental detail about the
source form on your notice to be anything like convenient for structure-
controlled applications, but it hides far too much about the source form
to be really effective for markup-sensitive applications. In my own
XML-in-C work, I have a data structure that takes LESS THAN HALF the
memory that is forced by the W3C DOM spec (if the required operations are
to be even halfway reasonable). Finally, consider the fact that the DOM
was designed for programming languages that have
- immutable strings
- automatic storage reclamation
- exceptions
NONE of which applies to C. There isn't the slightest trace of any suggestion
in the DOM specification (or any document I could find in the public areas of
the W3C site) that suggests how you might reasonably map the W3C DOM into a
language like C.
The next time someone suggests that Tidy should use the W3C DOM, let's
require them to implement, oh, one of the W3C suggestions:
change <I>...</I> to <EM>...</EM>
and <B>...</B> to <STRONG>...</STRONG>
in both the W3C DOM and Tidy's data structure, and see whether they still
think it would be a good idea. If they do, then demand that they do it.
Received on Tuesday, 22 May 2001 18:37:20 UTC