- From: Benjamin Aster <notifications@github.com>
- Date: Mon, 31 Jul 2023 06:02:52 -0700
- To: whatwg/dom <dom@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/dom/issues/1217/1658332535@github.com>
> Yes they are. They're absolutely coupled to documents. That's why they aren't available in workers. Of course it will be some work to implement, but all of the things like computed CSS styles, layout, scripts, resource loading, ... aren't a thing in documents created by `DOMParser` or `DOMImplementation::createHTMLDocument`. That's what I meant by "not architecturally coupled to the main thread". I remember that when implementing OffscreenCanvas, that was a lot of work because suddenly stuff like font rendering and CSS parsing (via context2d.{font, fillStyle, etc.}) needed to work in workers. The only thing related to this that comes to my mind now is `Document::styleSheets`, which gives access to **parsed** CSS stylesheets and I think currently works also with "fake" documents. For this to work in workers, yes, there would have to be a basic CSS parser available in workers, but if that's too difficult to implement, I guess for the "minimum viable product" of worker DOM APIs, browsers could just leave this empty and not parse the CSS at all? I think the use cases for parsing CSS in a worker are minimal anyways. > I don't believe browsers run iframes in a different thread, even if they have the sandbox attribute. I know @WebReflection already mentioned that now, but at least in Chrome where I tested it, it seems that iframes with a sandbox attribute *do* run in their separate thread. You can try it out with e.g. this setup: *index.html*: ```html <!DOCTYPE html> <html lang="en"> <head> <script type="module"> const frame = () => { millis.textContent = performance.now() requestAnimationFrame(frame) } requestAnimationFrame(frame) </script> </head> <body> <div id="millis"></div> <iframe src="iframe.html" sandbox="allow-scripts"></iframe> </body> </html> ``` *iframe.html*: ```html <!DOCTYPE html> <html lang="en"> <head> <script type="module"> const frame = () => { millis.textContent = performance.now() requestAnimationFrame(frame) } requestAnimationFrame(frame) block.onclick = () => { while(true); } </script> </head> <body> <div id="millis"></div> <button id="block">block</button> </body> </html> ``` If you click the "block" button in the iframe, the iframe is totally blocked but the parent frame continues to run. -- Reply to this email directly or view it on GitHub: https://github.com/whatwg/dom/issues/1217#issuecomment-1658332535 You are receiving this because you are subscribed to this thread. Message ID: <whatwg/dom/issues/1217/1658332535@github.com>
Received on Monday, 31 July 2023 13:02:58 UTC