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

> I think there are some fringe cases for DOM-in-Worker that make this particularly tricky.

All of the problems you mentioned have already been solved when browsers implemented `DOMParser` and `DOMImplementation::createHTMLDocument()`. If DOM APIs in workers would be spec'd, we could simply use the behavior that currently exists with them, only now in workers.

> what happens to inline scripts when parsing?

Nothing. JS doesn't get executed, as is currently the case on the main thread with DOMParser and createHTMLDocument()

> 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?)

External content (iframe, embed, img, ...) doesn't get loaded at all. `<foreignObject>` gets parsed normally & on the same thread.

> how would things like the media attribute work given that a document and its nodes have no direct relationship with display?

It doesn't. The media attribute in e.g. 
```html
<link rel="styleheet" href="dark.css" media="(prefers-color-scheme: dark)" />
```
would do absolutely nothing, and it doesn't matter since the CSS file doesn't get loaded anyway. Again, all of this is already the case *today* with "fake" documents created *on the main thread* via `DOMParser` or `DOMImplementation::createHTMLDocument()`.

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

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