Without DOM access, you're simply running a virtual machine isolated from everything else, and that would serve no purpose aside from burning clock cycles :).
It is currently felt that Webassembly shouldn't be given access to the DOM until after a garbage collection interface is created. Until that happens, any object given to the WASM runtime cannot be safely destroyed, as the browser doesn't know, and WASM has no way of indicating, that something, such as a reference to a div element, is still needed.
Currently, the simplest[1] and most secure way of working out how a given runtime should interface with the browser is to build that compatibility layer in javascript, and expose callbacks to the WASM runtime(which is defined). This lets developers write their own DOM-interface shim, allowing them to explore the possibility space, and not accidentally restrict which languages can be implemented in WASM.
[1] From the point of view of browser vendors and standards bodies.
So you allways have one and only one canvas for the output in which you write directly, via webgl or without. No need for a gc here as that canvas inly gets removed qhen the site closes.
(This would be one of the major design questions with such a thing. Not insurmountable! But given you’re already connecting it to JS functions...)