It doesn't need to be the same API... but implementing a new DOM API that doesn't meet the w3c standard is a bit on the nose. It's meant to be language independent hence the IDL.
Looking into it, the IDL might insulate the existing API implementation from JS to a greater degree than I assumed above. Apparently there might be horrors lurking in the binding generation code though. You can poke around in blink:
https://github.com/chromium/chromium/blob/main/third_party/b...
> isn't Dom access in essence an ability to change html tree
It might be more accurate to look at it the other way: our current DOM implementations were created to implement the "DOM API Standard". The standard dictated the types and how reading/mutation works.
> need type mappings
I can't imagine how it can avoid type mappings for things like e.g. creating unattached bits of DOM or binding callbacks that receive bits of DOM.
Personally I might be happy for a tiny WASM api... but then foresee 10 years of maddening omissions, security bugs and endless moaning because they didn't just implement the standard everyone already knew.