[whatwg] Intergrating the DOM and JavaScript (JSDOM)

[Andrew Fedoniouk]

----- Original Message ----- 
From: "Dean Edwards" <dean at edwards.name>
To: <whatwg at lists.whatwg.org>
Sent: Wednesday, May 10, 2006 4:38 PM
Subject: [whatwg] Intergrating the DOM and JavaScript (JSDOM)


|
| At the moment, DOM objects are specified in a language neutral way.
| That's fine. However, this makes these objects uninteresting and
| cumbersome to script with.
|
| Mozilla has a more integrated programming environment. It exposes DOM
| objects as native JavaScript objects. That means I can do things this
| like this:
|
| Object.prototype.foo = "bar";
| alert(document.body.foo);
|
| ==> "bar"

I don't know how this implemented in Mozilla but the most
interesting thing what makes real interest is "dynamic subclassing"

var MyBehavior =
{
    prototype: Element;
    attached: function( element )  { ....  }
    onMouseEnter: function( evt )  { ....  }
    onMouseLeave: function( evt )  { ....  }
    ...
}

....
root.getElementByID("myid").prototype = MyBehavior; // subclassing

This way it is enough to define class of elements once and
all DOM elements with such prototype will behave appropriately.

I went even further and introduced 'prototype' CSS attribute, so
in CSS I can define:

.myclass {
   color: red;
   prototype: MyBehavior; /* see var MyBehavior above */
}


|
| A trivial example but it demonstrates that the DOM and JavaScript are
| not totally separate on a Mozilla platform. This is very cool. 8-)
|
| It would be great if NodeLists were subclasses of JavaScript Array
| objects (especially with the introduction of Mozilla's Array Extras
| [1]). This makes iteration over DOM queries more flexible.
|
| I guess what I'm proposing is a new DOM API. One which is specified with
| JavaScript in mind. A redefinition of DOM objects as subclasses of
| JavaScript objects. Mozilla already does this by and large. It makes
| that browser a dream to program with.
|
| Is this within the remit of the Web Apps spec? This seems like a
| fundamental change in terms of browser architecture so I would
| understand if it was too difficult to implement in the short term.

Such thin wrapper is easier than full DOM implementation.

Benefits here are: on complex UI such a wrapper will 1) work significantly 
faster,
2) Memory consuming will be a lot less (instead of per element handlers you will
have handlers references only in one place - MyBehavior).
3) Markup will be clean - free from any scripting attributes.
4) If css will have attribute prototype (or behavior) then binding dom 
element-script could be done
solely by CSS.

|
| But it would be cool.

Oh , yeh.

Andrew Fedoniouk.
http://terrainformatica.com