Consider putting the editor content into an iframe

[jasmussen]

This is more of a discussion point than a ticket to fix.

Currently, the editor content area is a div. It's a freeform element wherein the editing experience takes place. Above it there's an editor bar, to the right an optional sidebar, and surrounding it is the WordPress admin chrome.

Would it be good for us to change this content area from residing in a div, to residing in an iframe?

Pros:

• The responsive CSS to position the content area would be drastically simplified
• Especially for the wide, full-wide and floated items we'd be able to simplify the markup
• We'd level the playing field between the editor and the front-end, making it easier to have the block styles be 1:1 in sync — no need to add margin edgecases to left-floated images based on whether the admin sidebar was present or not.
• If we were to want to load the themes style.css directly into the editor in the future, not only would this prevent CSS bleed, but it'd be extra important for responsiveness that the content was sandboxed
• We'd improve the responsive styles of the content, effectively letting you be able to preview the mobile breakpoint by sizing your browser correctly — currently you'd have to move all the way down to the actual mobile breakpoint.

Cons:

• Probably very very difficult to pull off

I'm sure there are more cons. Let's discuss.

CC: @melchoyce @westonruter @mtias @karmatosed

[sirbrillig]

I'll just say that iframes in a page can add a very large amount of complexity. I know WP does it already, but it can result in many subtle bugs that are hard to find and hard to fix. UX guarantees become much harder when the outer frame and the inner frame need to communicate about their state. A better way to separate styles is to rely on CSS namespacing (ie: BEM) or (if possible) Shadow DOM. Using iframes to separate styles is, in my opinion, a massive hammer for a tiny nail.

[jasmussen]

Solid addition to the cons list, @sirbrillig, I think it should weigh very high in evaluating this stuff.

A better way to separate styles is to rely on CSS namespacing (ie: BEM) or (if possible) Shadow DOM

Wanted to just clarify that it's less about scoping CSS, and more about ensuring that responsive breakpoints behave as they should. Until we have element queries, the viewport will define when media queries kick in, and the iframe being a separate veiwport means those'll work.

[BE-Webdesign]

To throw in my two cents:

We could consider trying react-element-query instead of an iframe. It is far from perfect, but would probably be a simpler solution than using an iframe. I don't really know though.

[jasmussen]

Another to the "pros" list — with the main content area being an iframe, we'd effectively solve both #656 (scroll bleed) and #1899 (sidebar double scrollbar) issues in one fell swoop.

[melchoyce]

Another to the "pros" list — with the main content area being an iframe, we'd effectively solve both #656 (scroll bleed) and #1899 (sidebar double scrollbar) issues in one fell swoop.

I think this would only be on Mac — I've seen up to three scrollbars in the Customizer on Windows before.

[jasmussen]

I think this would only be on Mac — I've seen up to three scrollbars in the Customizer on Windows before.

Just to clarify, an iframe would not remove scrollbars — you'd have one for the iframe, one for the sidebar, and one for the inserter. What it would do (which is why I feel it would address #1899), is make it so the scrollbars are all contextual to the field that scrolls, whereas right now you have two scrollbars all the way on the right.

[BE-Webdesign]

Note to self for reference:

This could potentially be useful for meta boxes, but the more I think about it probably not, any sort of page refresh could potentially tank Gutenberg's state.

[mtias]

What if we iframed the whole editor (not just the content area)? That would simplify how themes could style the editor page, and it might also simplify the "wide" implementation.

Thoughts @aduth @youknowriad ?

[youknowriad]

Can't tell exactly, I guess we should try. Some issues we might face:

• Changing the document title won't work as is
• Popovers and modals: Sometimes we need popovers to show on top of the WP sidebar/header, it won't be possible.

[mtias]

Sometimes we need popovers to show on top of the WP sidebar/header, it won't be possible.

When?

[youknowriad]

When?

I don't know exactly, just saying that it won't be possible. As an example: we talked about showing the popovers as modal taking the whole screen on mobile. It can't show on top of the WP's header.

[jasmussen]

It would be good to audit those popovers, because it's a good point. But in case of full screen modals on mobile, that would probably be okay.

[youknowriad]

Another related issue. Our current tooltips showing in the header will be cropped

[afercia]

Adding the accessibility label.
Please, I'd recommend to try to avoid iframes as much as possible. While iframes are not a barrier for keyboard navigation, they're really annoying for screen reader users when normally navigating content with the arrows.

[aduth]

My general feeling is that we'd encounter more frustrations with trying to get this to work with iframes than accepting compromises that come along with a shared CSS scope.

Shadow DOM might be a more interesting exploration.

[mtias]

Shadow DOM might be a more interesting exploration.

Willing to try this.

At the very least we need to make sure the editor page can be easily customized.

[mtias]

Going to close this and let's try a Shadow DOM implementation.

[MakiBM]

I would also vote for iframe. If Gutenberg is about 'truly wysiwyg' experience then it would help to match the front end without additional tweaks for editor styles. Plus important thing that you can't get otherwise - The @media queries inside the Shadow DOM look at the viewport of the browser, not at the dimensions of the host element, while iframe's @media look on the host element, so similar concept to element queries. That's no effort solution for keeping design within editor mobile friendly. If we'd want to developers to apply that manually then what - special case for editor 'viewport', then editor with settings closed, then editor within fullscreen mode? Seems a maintaince hell for me. Existing solution doesn't scale well for layout blocks where media queries are needed.

Also I think amount of duplication between editor and actual front end code is painful. This is something that plugin should take care of as much as possible in the background so the final authoring experience would be less overwhelming. Developers might end up doing things the old and faster way because time is money for them. Gutenberg itself doesn't solve any business issue for a site owner, it's just editing sugar (leave on side migration strategies as that's not something that customer likes to pay extra if he already tries to cut costs). Sorry if the last part sounds too philosophical - I think these are valid considerations for technology adoption

[jasmussen]

Worth noting that outside of the technical challenges of implementing an iframe, it's also not the panacea to all of our challenges. For example the edit view for a block is likely to always have additional/different markup from the front-end, in some cases. A complex menu block might output a ul on the frontend, but require additional wrapping divs in order to be editable in the backend.

Long term, I personally believe our best bet is a combination of Shadow DOM, display: contents;, and element queries.