Re: DOM4 Core

Doug Schepers wrote:
> However, I think it makes more sense at this point to simply include 
> these new attributes in DOM4 Core, along with the indispensable bits of 
> Element Traversal (that is, everything except the childElementCount, 
> which is superfluous to childElements.length).     I'd like this to also 
> contain the work that Simon Pieters did on Web DOM Core [4], if he's 
> willing to have that folded in (I left it out pending word from him... 
> he's BCCed on this message).

I started playing around with Web DOM Core back in the end of August, 
mainly from a viewpoint of getting a complete test suite for DOM Core. I 
did, however, also edit the spec a bit (mainly just adding one or two 
missing exceptions from DOM Level 3 Core). What I did is in the hg repo 
at [1].

That said, there are quite a few issues with the spec (both DOM 3 Core 
and Web DOM Core) as it stands today from a browser POV:

- There isn't in any sense of an abstract model, and browsers (through 
their HTML parsers) can create DOMs that could not be created via the 
scripting interface to the DOM (e.g., an <a@b> tag). There is no way to 
explain the current DOM behaviour in DOM 3 Core.

- Likewise, from that above point, it seems better to try and sort out 
the current mess of the error checking: sometimes it matches what can be 
serialized in XML 1.0 Fourth Edition, sometimes it matches some of the 
restrictions in XML 1.0 Fourth Edition (but not all!), and sometimes it 
doesn't do any error checking. This leads to a state of play in which 
the error checking doesn't actually help ensure the DOM can be 
serialized as XML, and as such, little is gained by it. It would be nice 
to resolve the above issue with element local names such as "a@b" by 
just removing error checking. (However, this can't be done blindly as IE 
supports weirdness like document.createElement("<div title=magic>") to 
create a "div" element with a "title" attribute whose value is "magic". 
To prevent this from seeming too sensible, this appears to use a 
different HTML tokenizer to the one normally used. In this case, content 
relies upon browsers throwing exceptions to work in other UAs!)

- The behaviour of several operations in the DOM needs to depend upon an 
HTMLness bit. The current state of play is that HTML 5 redefines certain 
operations for HTMLDocument. (However, HTML 5 also states: "All Document 
objects (in user agents implementing this specification) must also 
implement the HTMLDocument interface, available using binding-specific 
methods. (This is the case whether or not the document in question is an 
HTML document or indeed whether it contains any HTML elements at all.) 
Document objects must also implement the document-level interface of any 
other namespaces that the UA supports.").

- Probably quite a few other things I've forgotten off the top of my 
head (Simon, can you think of other major things?).

[1]: http://hg.gsnedders.com/web-dom-core/

HTH,

Geoffrey Sneddon — Opera Software
<http://gsnedders.com/>
<http://www.opera.com/>

Received on Monday, 19 October 2009 09:26:53 UTC