4 ms·

DOM is such a crufty old API/data structure to work with and with CSS, computationally it's a pig. Anything we can do to isolate bits and bobs on the page from

DOM is such a crufty old API/data structure to work with and with CSS, computationally it's a pig. Anything we can do to isolate bits and bobs on the page from one another and make DOM easier for the browser to render and emit events for, the better. I just think the Shadow DOM and Web Components are too complex to work with as designed. The componenty composability of React definitely seems real to me, whereas I don't have such optimism about Web Components. All I would want/need is a lightweight version of iframe whereby it functions like a javascript security and css styles sandbox, call it a subwindow. A subwindow could load html/css/js independently from the parent page like a Web Worker does, or it could borrow from assets the parent page has loaded and its HTML could be inlined as innerHTML statically/dynamically from the parent page (at creation time.) A subwindow would have an independent global/window object from the parent window. And, you could postMessage/onMessage communicate with the parent window if you needed. It could be constructed with its own dedicated DOM thread, or it could schedule on the parent's thread if you didn't want another thread spawned. Paints would have to be synchronized between the DOM threads, which could be a bummer. I just want an inline iframe, which I know is like saying I want an "inline inline frame". ;)

hayksaakian 11y ago
Isn't that how normal frames used to work? Before they were deprecated for iframes?
- rco8786 11y ago
  my thoughts exactly. what's old is new again
- seabee 11y ago
  Frames like frameset? It sounds more like Netscape 4 layers.
- EdSharkey 11y ago
  I don't want to partition the page the way frames/frameset did, I want to sandbox code and content the way iframe does, just in a more lightweight fashion. If I could couple that sandboxing with a component factory library like React, that could really be something else.
spankalee 11y ago
You don't explain how you think Shadow DOM is too complex. They're simple to me: basically just isolated tree of DOM attached to the document. The only slight complexity comes from projection, which really is just a way to plug in a child element into the shadow. Projection is absolutely necessary for composable widgets, you couldn't create containers without them.
- kuschku 11y ago
  One issue I have with this is that I won’t be able to apply a userstyle to restyle a page anymore, and I won’t be able to use websites without JS anymore. Just earlier today I had an issue where I was trying to read this article [1] and the page, after loading for around 3 minutes (I was on mobile and on the free plan of my ISP, which gives only 64kbps, but unlimited), had all the content, but neither JS nor CSS. There are already many websites which I can’t use at all anymore because they make everything invisible until JS and CSS are loaded. Flash of unstyled content is not an issue for me, it’s the whole reason I am able to read pages. [1] http://www.npr.org/2015/10/22/450583840/in-d-c-and-china-two-approaches-to-a-streetcar-unconstrained-by-wires http://www.npr.org/2015/10/22/450583840/in-d-c-and-china-two...
  - aaronharnly 11y ago
    > One issue I have with this is that I won’t be able to apply a userstyle to restyle a page anymore With the caveat that I only sorta understand this stuff -- if it emerges this way after the politics & process, you should be able to use the 'deep combinator' >>> to apply styles even across shadow DOM boundaries. https://drafts.csswg.org/css-scoping-1/#deep-combinator https://drafts.csswg.org/css-scoping-1/#deep-combinator
    - kuschku 11y ago
      > It’s currently disputed whether this combinator should exist. Also, it breaks about every existing userstyle, ever. And there should be a more general solution that also handles the shadow DOM of browser-internal elements like the <input type="file">
amelius 11y ago
The problem is that the HTML standard is being written for regular computer users instead of for seasoned developers.
DonHopkins 11y ago
You and me and lot of other people too. Get in line! ;) It was so nice to finally get inline SVG, instead of confined inside Adobe's plug-in. Crazy days.
nevir 11y ago
(Speaking as someone who worked on the Polymer team for a year, and has been writing React at a separate job for roughly half that) > The componenty composability of React definitely seems real to me, whereas I don't have such optimism about Web Components. Web components have pretty much the same levels of composability as React, but have promise for even more. The main reason I say this is that the components specs attempt to formalize a surface area for all web webcomponents libraries to interoperate with each other - though we're not to that point yet. Many of the Polymer core components are a great example of composed elements (sometimes overzealously so). Shadow DOM and insertion points (<content> or <slot>) do wonders for this. (Yes, Polymer 1.0+ backs off from this a little bit) React really only composes well with elements written in React. It can talk out to native components (and custom elements), but it's awkward enough that you tend to build wrappers to expose a more React-y interface (value, onChange, etc). --- > I just want an inline iframe, which I know is like saying I want an "inline inline frame". ;) Assuming that you want these inline frames on a per component basis, we're talking about a ton of overhead per component: * A new JS VM context (for the sandboxed global and security mechanisms) * A new render layer (and the the synchronized painting you mention) * All the other browser bits that would need to be built up --- DOM is a problem, but it's not the biggest problem, and performance-wise, there have been tremendous improvements in the last few years (Try running your benchmarks again). However, imagine a world where all elements are defined with a set of public APIs like web components. No more crazy special cased properties, magic methods, etc. Imagine how much cruft the browser vendors could remove from the DOM. Imagine how much faster things would be. Imagine all of HTML implemented purely in JS, and the browser only exposes the primitives needed to do that.
- cheapsteak 11y ago
  >Yes, Polymer 1.0+ backs off from this a little bit) I didn't know about this, any guidance on why?
  - nevir 11y ago
    Polymer 1.0 has support for shadow DOM, but also what they call "Shady DOM": https://www.polymer-project.org/1.0/articles/shadydom.html https://www.polymer-project.org/1.0/articles/shadydom.html TL;DR: Shady DOM provides an API that is similar to shadow DOM, but without all the crazy overhead when polyfilling it. The downside is that it's not quite transparent to someone outside of a Polymer element
recursive 11y ago
I think you're talking about a "seamless" iframe. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if...
- calebegg 11y ago
  Note that this is not supported in any browser, and Chrome support was first implemented and then removed over two years ago, so it seems unlikely to ever be supported. Also a seamless iframe is not CSS-isolated, something that the GP said they wanted. http://caniuse.com/#feat=iframe-seamless http://caniuse.com/#feat=iframe-seamless
- EdSharkey 11y ago
  I have sometimes thought about experimenting with rolling BLOB URL's for HTML, CSS, and JS and using that to initialize an iframe. I think that would work. One of the things I'd like to do is be able to build a frame sandbox using assets already loaded by the parent page. I believe iframes can be very costly for the browser to manage, but I don't understand all the reasons why that would be - perhaps something to deal with the cross-domain security concerns. It'd just be nice to have a stripped-down same-domain version of iframe that could layout nicely as a rectangle into the parent page, but not inherit styles nor Javascript namespace from the parent page. The idea of having multiple threads contributing to the DOM that builds the page really intrigues me. There's a proposed thing for HTML5+ called CanvasProxy, for example. The idea would be that you could detach a Canvas from the DOM thread and give it to a Web Worker. It could get a Canvas context in the worker from the proxy, and all draw commands would execute against the Canvas' pixel buffer in the worker. Meanwhile, back in the DOM thread, the actual canvas tag still lives on, just in detached mode, but you can still set CSS styles on that tag. You just can't get access to the Canvas context. It sounds rad, and would make a big difference to canvases that represent heavy computations or frequent draws. No browser vendor has attempted to implement CanvasProxy however, it sounds like it is a challenge to keep it actually performant, and/or there are GPU threading issues?

hayksaakian 11y ago

Isn't that how normal frames used to work? Before they were deprecated for iframes?

rco8786 11y ago
my thoughts exactly. what's old is new again
seabee 11y ago
Frames like frameset? It sounds more like Netscape 4 layers.
EdSharkey 11y ago
I don't want to partition the page the way frames/frameset did, I want to sandbox code and content the way iframe does, just in a more lightweight fashion. If I could couple that sandboxing with a component factory library like React, that could really be something else.

spankalee 11y ago

You don't explain how you think Shadow DOM is too complex. They're simple to me: basically just isolated tree of DOM attached to the document. The only slight complexity comes from projection, which really is just a way to plug in a child element into the shadow. Projection is absolutely necessary for composable widgets, you couldn't create containers without them.

kuschku 11y ago
One issue I have with this is that I won’t be able to apply a userstyle to restyle a page anymore, and I won’t be able to use websites without JS anymore. Just earlier today I had an issue where I was trying to read this article [1] and the page, after loading for around 3 minutes (I was on mobile and on the free plan of my ISP, which gives only 64kbps, but unlimited), had all the content, but neither JS nor CSS. There are already many websites which I can’t use at all anymore because they make everything invisible until JS and CSS are loaded. Flash of unstyled content is not an issue for me, it’s the whole reason I am able to read pages. [1] http://www.npr.org/2015/10/22/450583840/in-d-c-and-china-two-approaches-to-a-streetcar-unconstrained-by-wires http://www.npr.org/2015/10/22/450583840/in-d-c-and-china-two...
- aaronharnly 11y ago
  > One issue I have with this is that I won’t be able to apply a userstyle to restyle a page anymore With the caveat that I only sorta understand this stuff -- if it emerges this way after the politics & process, you should be able to use the 'deep combinator' >>> to apply styles even across shadow DOM boundaries. https://drafts.csswg.org/css-scoping-1/#deep-combinator https://drafts.csswg.org/css-scoping-1/#deep-combinator
  - kuschku 11y ago
    > It’s currently disputed whether this combinator should exist. Also, it breaks about every existing userstyle, ever. And there should be a more general solution that also handles the shadow DOM of browser-internal elements like the <input type="file">

amelius 11y ago

The problem is that the HTML standard is being written for regular computer users instead of for seasoned developers.

DonHopkins 11y ago

You and me and lot of other people too. Get in line! ;) It was so nice to finally get inline SVG, instead of confined inside Adobe's plug-in. Crazy days.

nevir 11y ago

(Speaking as someone who worked on the Polymer team for a year, and has been writing React at a separate job for roughly half that) > The componenty composability of React definitely seems real to me, whereas I don't have such optimism about Web Components. Web components have pretty much the same levels of composability as React, but have promise for even more. The main reason I say this is that the components specs attempt to formalize a surface area for all web webcomponents libraries to interoperate with each other - though we're not to that point yet. Many of the Polymer core components are a great example of composed elements (sometimes overzealously so). Shadow DOM and insertion points (<content> or <slot>) do wonders for this. (Yes, Polymer 1.0+ backs off from this a little bit) React really only composes well with elements written in React. It can talk out to native components (and custom elements), but it's awkward enough that you tend to build wrappers to expose a more React-y interface (value, onChange, etc). --- > I just want an inline iframe, which I know is like saying I want an "inline inline frame". ;) Assuming that you want these inline frames on a per component basis, we're talking about a ton of overhead per component: * A new JS VM context (for the sandboxed global and security mechanisms) * A new render layer (and the the synchronized painting you mention) * All the other browser bits that would need to be built up --- DOM is a problem, but it's not the biggest problem, and performance-wise, there have been tremendous improvements in the last few years (Try running your benchmarks again). However, imagine a world where all elements are defined with a set of public APIs like web components. No more crazy special cased properties, magic methods, etc. Imagine how much cruft the browser vendors could remove from the DOM. Imagine how much faster things would be. Imagine all of HTML implemented purely in JS, and the browser only exposes the primitives needed to do that.

cheapsteak 11y ago
>Yes, Polymer 1.0+ backs off from this a little bit) I didn't know about this, any guidance on why?
- nevir 11y ago
  Polymer 1.0 has support for shadow DOM, but also what they call "Shady DOM": https://www.polymer-project.org/1.0/articles/shadydom.html https://www.polymer-project.org/1.0/articles/shadydom.html TL;DR: Shady DOM provides an API that is similar to shadow DOM, but without all the crazy overhead when polyfilling it. The downside is that it's not quite transparent to someone outside of a Polymer element

recursive 11y ago

I think you're talking about a "seamless" iframe. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe https://developer.mozilla.org/en-US/docs/Web/HTML/Element/if...

calebegg 11y ago
Note that this is not supported in any browser, and Chrome support was first implemented and then removed over two years ago, so it seems unlikely to ever be supported. Also a seamless iframe is not CSS-isolated, something that the GP said they wanted. http://caniuse.com/#feat=iframe-seamless http://caniuse.com/#feat=iframe-seamless
EdSharkey 11y ago
I have sometimes thought about experimenting with rolling BLOB URL's for HTML, CSS, and JS and using that to initialize an iframe. I think that would work. One of the things I'd like to do is be able to build a frame sandbox using assets already loaded by the parent page. I believe iframes can be very costly for the browser to manage, but I don't understand all the reasons why that would be - perhaps something to deal with the cross-domain security concerns. It'd just be nice to have a stripped-down same-domain version of iframe that could layout nicely as a rectangle into the parent page, but not inherit styles nor Javascript namespace from the parent page. The idea of having multiple threads contributing to the DOM that builds the page really intrigues me. There's a proposed thing for HTML5+ called CanvasProxy, for example. The idea would be that you could detach a Canvas from the DOM thread and give it to a Web Worker. It could get a Canvas context in the worker from the proxy, and all draw commands would execute against the Canvas' pixel buffer in the worker. Meanwhile, back in the DOM thread, the actual canvas tag still lives on, just in detached mode, but you can still set CSS styles on that tag. You just can't get access to the Canvas context. It sounds rad, and would make a big difference to canvases that represent heavy computations or frequent draws. No browser vendor has attempted to implement CanvasProxy however, it sounds like it is a challenge to keep it actually performant, and/or there are GPU threading issues?