Re: [whatwg/dom] Proposal: DOM APIs in web workers? (Issue #1217)

Might be worth splitting the discussion here up into two topics:
1. Ergonomic differences between iframe-as-thread and worker-with-dom
2. Spec + technical feasibility (of exposing a DOM to Workers, and of allowing `<iframe sandbox>` to strictly imply OMT)

For #1:

It seems like any ergonomic warts in the process of constructing an iframe are either solvable in userland (essentially add an optimized mechanism for using `<iframe sandbox>` in a JS-loading-JS scenarios rather than just HTML-loading-HTML).

The ergonomics of the DOM-in-Worker are clearer to me, the issues there seem to be more on the spec and implementation side.

For #2:
I think there are some fringe cases for DOM-in-Worker that make this particularly tricky. Some potential cases off the top of my head:
- what happens to inline scripts when parsing?
- what happens to iframe or other nested documents (`<svg foreignObject>`, `<embed>` et al) in parsed documents within the Worker (do they get forced into the same thread?)
- how would things like the `media` attribute work given that a document and its nodes have no direct relationship with display?

I can think of possible answers to these things, but they would all seem to require substantial revisions to DOM specs. Seems like it would be easier to spec out a "lite" DOM interface that avoids all of these issues by omitting presentation-related APIs.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1217#issuecomment-1658442071
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/1217/1658442071@github.com>