Gutenberg: Consider iframing the editor canvas/content

[ellatrix]

I wanted to raise some concerns I have with the implementation of #13203/#19082 and editor styling in general.

The current implementation partially addresses responsiveness issues by simulating media queries. It seems using an iframe element was briefly on the table, but considered technically too difficult. I’m not sure if those concerns are valid.

Specifically, to maintain interactions in the iframe (modifying blocks), I would imagine there would need to be some communication layer to maintain state between the top-level editor and the iframe'd content.

(https://github.com/WordPress/gutenberg/issues/13203#issuecomment-550389126)

I don’t think any special communication layer is needed. We can just render the blocks though a portal. I briefly tested this, and moving the blocks, for example, works perfectly fine. See https://github.com/WordPress/gutenberg/issues/20797#issuecomment-597727947.

I’m not sure if anyone had any other concerns with iframes. I know iframes are controversial, but they _do_ effectively sandbox all CSS within the editor canvas.

• There would be no admin CSS bleed at all. This is something we’ve been struggling with since the beginning.
• There would be no need to simulate media queries, which is arguably technically more difficult than using an iframe.
• Relative units like (r)em and vw/vh just work.
• For a full site, a theme stylesheet can be just dropped in the editor without any adjustment. I think this is important as it makes the life of theme authors much easier.
• It's possible to have one selection per window, so one in the admin and one in the content. This is useful for e.g. the link UI where the selection in the content can be kept while the selection is also in an input element (for the URL). Maybe be useful in other cases.

I only see a small amount of technical challenges to overcome:

• Loading the correct styles in the iframe should be easy enough.
• We’ll need to adjust positioning of popovers, but I think this is not a big issue.
• We need to make sure can can seamlessly navigate from the edit UI to the editor canvas, but I think this is also not a big deal.

I would love your opinions @jasmussen, @youknowriad, @aduth, @mcsf, @mapk, @ItsJonQ, @kjellr, @tellthemachines, @jorgefilipecosta, and @MichaelArestad.

[ellatrix]

As you can see in this experiment, special iframe communication is not needed if the block are rendered through a portal. I've not added any stylesheets here yet, so please just ignore the fact that the content is not styled.

[ItsJonQ]

@ellatrix Haii!! I think using iFrames is a creative solution!

It definitely addresses all the issues you pointed out. For example, there's a reason why a lot of the embeddable live chat/help apps (e.g. Intercom, Help Scout, etc...) use iFrames 💪

It's a challenge, but I don't think it's impossible.
Off the top of my head, I can't think of any real blockers (other than technical challenges).

Very interested to hear what others think :)

[ellatrix]

It's a challenge, but I don't think it's impossible.

Thanks for reading. :) I don't think it's as challenging as we might assume. Trying to solve all the issues we have seems more challenging to me without the use of an iframe. With an iframe all these things will work by itself.

[youknowriad]

What happens when you open a modal from a block (Media Library or something else).

[ellatrix]

@youknowriad It would open in the main window (thanks to the React portal). Here's a demo. Please ignore the unstyled content. :)

[ItsJonQ]

I approve the gif inserted in the demo 🐻 ❤️

[youknowriad]

We can just render the blocks though a portal.

I'm not sure what that means exactly? How would that work?

[ellatrix]

@youknowriad Something like this:

const Iframe = ( { children, ...props } ) => {
    const [ contentRef, setContentRef ] = useState();
    const mountNode = contentRef && contentRef.contentWindow.document.body;

    return (
        <iframe { ...props } ref={ setContentRef }>
            { mountNode && createPortal( children, mountNode ) }
        </iframe>
    );
};

// ... and then:

<Iframe>
    <EditorContent />
</Iframe>

[youknowriad]

mmm! interesting. I believe we should definitely explore this in a PR and figure out the shortcomings.

[ellatrix]

@youknowriad Yes, I think so too! I just wanted to quickly sanity check this with you all so I'm not overlooking some major thing.

[youknowriad]

For me, the popovers/modals had always been the main issue here... especially as we don't know how third-party blocks could be creating these.

[MichaelArestad]

This seems too good to be true. I absolutely would love to go this route as it resolves a handful of CSS issues that have been a blocker for progress (or very difficult to work around) on various issues. It also seems less fragile than implementing some of the creative (and brilliant) media query parsing that has been done to simulate media queries for device previews.

[mtias]

If we can make this transparent while retaining all the UX details we have crafted so far, I'm all for it.

[chrisvanpatten]

This seems too good to be true.

Echoing this!

Assuming this works, and works reliably, this seems like it could be a great path to aligning the edit UI and the front-end styling even further.

[ellatrix]

@mtias yes you wouldn’t notice the iframe at all if the editor styles are loaded etc. I’ll work on a proof of concept tomorrow.

[ItsJonQ]

@ellatrix I'm so excited for this 😍 !! Good luck!

[jasmussen]

:keanu-whoah:

[tomtev]

Did it work out? :)

[ellatrix]

I had unfortunately fallen ill the night after my last comment, so I haven't make any progress. Might have a look today or tomorrow since I'm doing better now.

[tomtev]

@ellatrix ok. Take care!

[ZebulanStanphill]

If this works, perhaps this could also lead to #9129 being fixed?

[NewJenk]

What's the progress on this? And am I right in thinking that if the editor is essentially an iframe then the front-end stylesheet can be loaded as-is with there being minimal overhead in getting the editor canvas to look just like the front-end?

[NewJenk]

Any update on this?

[ellatrix]

After some discussion with a few other people, it seems like a good idea to do it first for the full site editing experiment, which could probably also benefit most from it and is new (so no need to be backward compatible).

[simison]

@ellatrix With the concerns you all had, would it make sense to have the iframe solution as something that can be turned on and off via code?

[NewJenk]

@ellatrix With the concerns you all had, would it make sense to have the iframe solution as something that can be turned on and off via code?

I suppose for backwards compatibility it would be good if it could be turned on/off but if it works as expected then I think adoption would be fairly rapid.

Using the front-end stylesheet for both the front-end and the editor, and not having to spend hours bending and twisting styles to get the editor looking like the front-end really could be transformative. @m could you give @ellatrix and the rest of the team all the resources they need to realise this please?

[ellatrix]

@simison Do you mean as an option for block editor implementations, or as an option to a specific block editor implementation like the post editor? In the PR, it's an option already because the iframe is added by the block editor implementor, so you can still make block editors without it. It's an implementation detail of the post/site editor.

[ellatrix]

The PR for iframing the site editor can be found here: #25775.