(still not a browser engineer - others will know better). It doesn't need to be the same API... but implementing a new DOM API that doesn't meet the w3c standa

(still not a browser engineer - others will know better). 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/blink/renderer/core/dom 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.