Explore using an IFrame to sandbox CSS for the Off Canvas tray

I haven't looked to closely at the patch but from the start I'm not for an iframe solution for a couple of reasons:

1. Most of the problems described in #4 we had with the overlay. And the 1k lines of JS that came with the module to deal with them is gone for a reason.
2. Duplication of many scripts. There will be JS inside the canvas iframe, which means the same JS will be loaded. Just like that the JS is doubled on the page. Knowing that there is about 600kb of JS loaded on the front page when logged in (quickedit/toolbar/etc), When the iframe opens, there is about 1.3MB of JS on the page! this is nuts.
3. Will need to introduce a new API or something to reference elements within the iframe, can't jQuery it like before, that'll introduce quite a bit of overhead (from the overlay, about a few hundred lines of JS at least).

Purely on the performance aspect that's a no-go for me.

The overlay was one thing, but at least it was a whole page where no direct interactions with the opened page was supposed to happen, this is not the case here. If you have an ajax call on the main page, attachBehaviors will not be called inside the iframe. So you need to initialize things twice or introduce something new somewhere. If a contrib module makes content appear in the off canvas thing, and expect the content to be quick-editable, what happens? I don't want to have attachbehavior look for iframes or be monkey-patched by the outside-in module to do it.

@nod

The overlay was one thing, but at least it was a whole page where no direct interactions with the opened page was supposed to happen, this is not the case here. If you have an ajax call on the main page, attachBehaviors will not be called inside the iframe. So you need to initialize things twice or introduce something new somewhere.

Yes, but that is simply a description of the nature of this challenge which is 'how do we achieve administrative interactions that directly manipulate rendered content on the page in a fluid and intuitive way'.

Overlay never did anything like that. It seems obvious to me that a solution that does would be more complex and would require more code. Remember though that this is a performance hit that is *only* incurred by an administrator and not by a site visitor.

The trade off of having a much more direct path to editing almost everything in a site with immediate preview is well worth that cost IMO.

Having said all that, if you have up your sleeve a clever way to achieve the same goal without iFrame I would be very eager to hear it. :)

we do have control over the css we could prefix all css rules from a specific frontend-admin library with some id at least that'll boost the rules specificity. Or add !important to everything during preprocess

we do have control over the css we could prefix all css rules from a specific frontend-admin library with some id at least that'll boost the rules specificity. Or add !important to everything during preprocess

That's exactly the CSS nightmare that the iframe-based solution would avoid :)

#5:

2. Most JS is not relevant in the Off-Canvas Tray. We don't need Quick Edit or the Toolbar there, for example. Nor do we need Contextual Links.
3. Why? JS in the main window should not be altering the DOM in the Off-Canvas Tray. Communication between frames can happen via window.postMessage() IIRC.

To be clear: I'd rather not use iframes either. But given that we can't use Shadow DOM, I don't see how else we can arrive at a sane, workable solution, that doesn't require every single bit of CSS to be duplicated, hence making Off-Canvas Tray-specific CSS an absolute nightmare. That's the only reason I even proposed this.

@Nod

There is another benefit of iFrame that has not been mentioned, Without iFrame, special CSS needs to be written for content in the tray to make it behave like it's in a narrow viewport. With iFrame the narrow viewport media queries for mobile also apply to the tray (when it's used at it's default narrow width). It essentially gives us the equivalent of an element query.

One other option we have not suggested yet AFAICR is putting the tray styling in the javascript and injecting it inline, which will always win out in specificity.

#11:

I think eventually though we will want JS in the tray to altering DOM elements in the main page.

But you can still have that. Ensure you have different JS in the main frame and in the Settings Tray iframe, and have them communicate via window.postMessage(). That probably even results in a cleaner separation of concerns.

EDIT: or I guess https://developer.mozilla.org/en-US/docs/Web/API/Channel_Messaging_API.

#12: How are you going to gather the appropriate CSS to inject? You'd need to parse CSS, and run every single CSS selector through JS, scoped to the Settings Tray root element, and then generate style attributes for each selector's style rules.

#12: How are you going to gather the appropriate CSS to inject? You'd need to parse CSS, and run every single CSS selector through JS, scoped to the Settings Tray root element, and then generate style attributes for each selector's style rules.

Yeah, I was thinking of some kind of pre-render but @mattgrill explained the huge pitfalls of that.

Some thoughts,

#5

Duplication of many scripts. There will be JS inside the canvas iframe, which means the same JS will be loaded. Just like that the JS is doubled on the page. Knowing that there is about 600kb of JS loaded on the front page when logged in (quickedit/toolbar/etc), When the iframe opens, there is about 1.3MB of JS on the page! this is nuts.

Looking at an obviously contrived example, loading the 'Main Navigation' edit form in the tray executes another 276 requests with aggregation turned off. I don't think we are going to want to re-render an entire form and all the weight that comes with it. U+1F44D

#5, #9, #11

I think @tedbow is correct. At some point in the future we'd like to have optimistic feedback that can escape the confines of the iframe. Even if we used window.postMessage(), we would still want to provide a consistent interface that other developers could take advantage of. Additionally, window.postMessage() is only supported starting with IE8 which may or may not be of concern.

However could we do something like the following.

const iframe = jQuery('<iframe />')
  .appendTo('#wrapper') // The tray.
  .contents();
  
iframe.find('head')
  .append($('<style>body { background: black; color: red; }</style>')); // Inject a link to the actual stylesheet. 
iframe.find('body')
  .append(jQuery('<p>sample text</p>')); // This would be the ajax'd html of the form.

I think this allows us to keep the form encapsulated in a frame, but we can also just load (via ajax) the form html, preventing the duplicate loading of scripts.

loading the 'Main Navigation' edit form in the tray executes another 276 requests with aggregation turned off

Reproduced. But you forgot to mention they're all served from the browser's cache!

At some point in the future we'd like to have optimistic feedback that can escape the confines of the iframe.

How would an iframe prevent that?

we would still want to provide a consistent interface that other developers could take advantage of

What would that consistent interface look like? I think it's fair to guess that it'd be an event. And for that even to be consistent, it'd have to tell the Settings Tray/Outside In to trigger an event, so that all Outside In events are handled the same. At which point… Outside In might as well be using window.postMessage() inside the iframe, that message would be received inside the main frame and would trigger an event there.
So, I really don't see what the problem is with that.

only supported starting with IE8 which may or may not be of concern.

That's not a concern.

So: I'm not an expert in this, nor am I fan of iframes. But I've only seen pretty thin arguments against iframes so far.

P.S.: in testing that, I noticed that \Drupal\outside_in\Block\BlockEntityOffCanvasForm::form() is called three times when opening a menu block in the Settings Tray! That's a major bug right there, I'm afraid…

@cosmicdreams suggested the alternative of using webcomponents.js to polyfill shadow dom—apart from drawbacks of yet another javascript library others already voiced—In looking through the documentation for webcomponent.js I discovered that it cannot effectively polyfill all of the CSS properties of web components without resorting to, you guessed it, an iFrame!

See https://github.com/webcomponents/webcomponentsjs/blob/master/src/ShadowC...

Hi gang: thanks for bringing this issue to my attention here @tkleary.

I just wanted to update everyone on the progress that has gone into web components in case you were not aware. About a year or two ago, the major browser vendors starting meeting regular to discuss how to properly implement web components in a way that all browsers can be comfortable with. What was produced from those discussions is V1 of the four main web standards that comprise this Web Components concept (Templates, Custom Elements, Shadow Dom, and HTML Imports).

Natively, most browsers support templates (I'm looking at you IE 11). Support for Custom Elements and Shadow Dom is either underway for most browsers to on the list of things to do / considering (yes even for IE Edge). I think it's a good bet to expect that native support will come eventually. (I'm being optimistic).

Until then a polyfill does exist. You may have seen it before : https://github.com/WebComponents/webcomponentsjs/tree/v1

The link above points to the matured version of this set of polyfills. Whearas before, the polyfill was a pretty large file that was loaded for all the browsers, they've now created a tiny js file to detect what level of support for Web Components your browser has and then load the appropriate polyfill. As a result: Complete support of the standards can be enabled through the download of a payload varying between < 7 kb -> ~ 30kb (referencing minified / compressed file sizes). That get the library size into the ballpark of jQuery. For a library, that may not be needed for anonymous users.

I'll report back soon. But I'm also working with the folks who make the ui_patterns module to introduce automatic discovery of these 3rd party components so that your Drupal site can have smart ways to populating them with data.

Fundamentally though, I really think the Shadom Dom support that Web Components provide is specifically designed to solve the problem of allowing these Admin elements to stand alone without having outside influence bleed in.

@cosmicdreams

I personally am very excited about these advances, but as others have said better than me, it seems like core experimental is not the place for this just yet.

I am going to really dig in on this and start testing it out in other more bleeding edge experiments I'm working on though, and I'd really like to talk to you in more depth about it if you're going to be in Baltimore.