Re: DOM4 Core

On Mon, 19 Oct 2009 11:26:15 +0200, Geoffrey Sneddon <gsneddon@opera.com>  
wrote:

> 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.

Indeed.


> 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!)

I think it would probably be disruptive to change the error checking in  
the DOM at this point.


> - 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?).

* The "legal hierarchy" checking is wrong and should be revamped and  
probably be part of appendChild/insertBefore/etc.

* At some point, I had hope that we could somehow drop support for Attr  
nodes and related methods, but I think Web compat requires at least some  
of the methods to be supported, so it's probably better to just spec them  
to the extent that browsers have implemented them.


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

-- 
Simon Pieters
Opera Software

Received on Monday, 19 October 2009 10:12:31 UTC