You are currently viewing a snapshot of www.mozilla.org taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to www.mozilla.org, please file a bug.



Contribute code

Fabian Guisset <fguisset@softhome.net>

What is there to code?

First of all, before starting to write anything, mail Johnny Stenback with your project and ideas. He is the module owner of the DOM, so he will be able to help you and get started better than anyone else.

Here are some useful resources for the coders who would like to help hacking on the DOM.

  • The introduction to XPCOM for the DOM. Since the DOM relies so heavily on XPCOM, it is a good idea to start here if you have no idea how it all works.
  • The Mozilla DOM Hacking Guide. This document describes advanced DOM topics like DOMClassInfo.
  • You can also implement new DOM Level 3 interfaces, but make sure you talk with Johnny Stenback first, as mentioned above.

The following areas of the DOM more specifically need work. I'll try to be more precise in a future revision of this document.

  • DOM Level 2 CSS and Stylesheets. Numerous interfaces are not yet implemented. Please contact Boris Zbarsky if you are interested. He certainly has some work for you.
  • Implement support for entities and entity references (as defined by the DOM Core specs).
  • DOM Level 3. Also contact Johnny Stenback first, please.

Why hack on the DOM?

The DOM implementation in Mozilla is critical for several reasons:

  1. The whole User Interface of Mozilla relies heavily on the DOM. Just like XUL is used to describe the graphical interface, the DOM is used to make this interface interactive. An example is the Composer module, that does almost everything using the DOM (inserting new elements, etc). Any bug in the DOM code has a strong influence on the software as a whole.
  2. People expect Mozilla to render their pages and execute their scripts correctly if they coded it by the W3C specs. A bug in the DOM is therefore very frustrating for web developers, who have other things to do than to work around the bugs in a browser much praised for its standards-compliance.
  3. Mozilla targets, among others, the Web Application world. This means that applications built on the web have to be entirely interactive, only by using HTML/XUL and the DOM.

For all these reasons, it is very important that Mozilla achieves a very high level of compliance with the W3C DOM. And even though we are certainly on the right track, lots still has to be done.

In any case, the DOM Team will be glad to answer any question you have regarding the DOM implementation.
(Please, no questions about how to use the DOM. Those belong in the newsgroups and in the various DOM mailing lists, thank you)