![]() |
C++ library for DOM (lib-dom) |
Introduction Screenshots Mailing Lists and IRC Alternative Browsers Special Thanks
FAQ
Download binaries Platforms Compiling Mnemonic Other useful software
Core Message modules Library modules Object modules Coding Guidelines Browse Source Using CVS
Website questions to: |
The lib-dom is a C++ library implementing the w3c Document Object Model. That is, it contains the classes necessary to store a document tree and provides the DOM methods to manipulate it. All of level 1 and most of level 2 will be supported. It is, however, purely C++; a CORBA wrapper can easily be written on top of this library when required since almost all interfaces and methods follow the DOM recommendation. There is also support for storage of CSS stylesheets, but we do not follow the DOM here. For all practical purposes, the CSS 2 DOM working draft is completely useless and braindead. The DOM specification uses a rather old-fashioned (at least when compared to the C++ STL) way of addressing containers. Wherever possible, faster and more efficient C++ interfaces, which can be fed to the standard STL algorithms, have been provided in lib-dom as well. Some of them are based on the preliminary DOM level 2 specifications. All of the DOM standard access methods are however present and can be used at the same time. All parts of the DOM that are tagged as `deprecated' have not been implemented. (some of those things are really stupid, like those zillions of HTMLElement descendants). All names are 100% identical to the DOM specification. The entire library is placed in the namespace `DOM' to avoid name clashes with other libraries. The CSS part of the DOM level 2 working draft is completely useless for our purposes (it requires a CSS parser to be present behind almost all interfaces, for example). The implementation in lib-dom therefore differs quite a bit from the DOM level 2 working draft. Warning: the DOM level 2 specification is in a miserable state right now. Not even iterators are designed right. Things will change, hopefully.
The css part of lib-dom serves two purposes. Firstly it provides a convenient way to store the CSS rules internally, and secondly it provides methods to determine, for any node in a DOM::Document tree, all the CSS properties. As the rules which determine the particular effect of a CSS property on a given DOM element are rather complicated (and differ a lot between various properties), all CSS2 properties are hardcoded in the library. On the positive side, this means that you can lookup a property using an enum as identifier rather than the entire string, which increases the lookup speed. It is up to the user of the implementation to decide whether properties that should be inherited by child elements are stored in the children as well, or whether a layout tree is used that can refer to parent elements for these properties. The lib-dom is able to serve both needs, as it returns both the actual property value as well as an indicator of whether the property is inherited or specified on the particular element. /* More grumbling follows. @media : This is EXTREMELY stupid. It is not even a proper rule, since the declaration block is a stylesheet by itself. Can't these people see that `media' is just something that should be attached to an entire sheet? @page : Why can't this just be a set of properties on <BODY>, like page-size: page-margin: Or on <HTML> if you want. This does not make sense AT ALL. O well, we'll just make this a pseudo-class. (so we'll get . : # and @ as class/pseudoclass/id/atrule. @font-face : Must be a Micro$oft invention. This is sooooo pathetic. For any serious work it is useless. Again, we will store this as an atrule thingy. */
node--+ | | firstChild | +----->-------node | | | | | V nextSibling | | | | +-------------node | | | | | V nextSibling | | lastChild | | +----->-------node--+ | | firstChild V nextSibling +------>--------node | . | . node--+ | | firstChild | +----->-------node | | | | | V nextSibling | | | | +-------------node . .
As long as a
The basic reason for the above logic is that the
This section contains a few remarks on unimplemented parts of DOM that can be done in a more elegant way using mnemonic-core. Level 2 defines events. These are basically just messages for mnemonic. There are several types, normal events, UI events and mutation events. These will be mapped to mnemonic messages, see the msg-dom module. The level 2 draft does not address priority issues at the moment. |