Add support for DOM standard interfaces

[mindplay-dk]

This is a great library and it's already been extremely useful for a number of things. 🙂👍

Is there a design reason why the APIs deviate from the DOM standard, or is it just the way it ended up?

I won't go into too much detail here, but the fact that property names and functions have different names and types is extremely disruptive, if you're trying to integrate with existing code and tests, etc. - and especially in TypeScript.

To be clear, I'm not asking for or expecting a full implementation of the DOM standard - I'm not asking for any new features per se. But even code that requires a subset of a DOM interface does not immediately work without remapping the node model to something compatible first.

Would you be at all open to changing this? I might be able to help. (It would be a break change, of course.)

(I apologize if this has already been asked and answered - it seems unlikely I could be the first person to ask, but I did search your issues and, to my surprise, I didn't find anything.)

[fb55]

The DOM structure was inherited from the original node-htmlparser project. There are aliases available for a lot of the DOM names, eg. tagName will get a node's tag name; the same is true for eg. childNodes, nodeType and attributes.

I don't want to introduce any breaking changes here, as there is a lot of code depending on this library. But if there are any aliases you'd like to see, feel free to add them to the domhandler module.

[fb55]

Transferred to domhandler, as this is more appropriate here.