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.

(#13203 (comment))

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 #20797 (comment).

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?

[joelyoder]

Since FSE now ships with this change, how close are we to implementing this in the post editor? This could be a huge win for theme editors.

[mtias]

We still need to do a proper evaluation of the stability of the iframe in the site editor and any remaining issues. One difficulty is that — by its nature — the site editor receives a lot less sustained testing in the way the post editor does, particularly with third-party blocks. But hopefully we can enable it soon as an option to cover more ground.

[oandregal]

I may have run into an issue with the iframe in the site editor that was reported by Anne #29457 (comment)

[ellatrix]

I'm exploring a fix in #29573. This PR would be great for the iframe in general as we're avoiding the need to access the right document by replacing it with React refs.

After that, I'll resume work on iframing the post editor, but it's tough to continually fix the e2e tests on the PR, figure out backward compatibility etc. It will needs some collaboration and communication with plugin authors.

[johnstonphilip]

@ellatrix I work with the Atomic Blocks and Genesis Blocks team. Is there anything we can do to help with this?

[joshm33333]

Editing to be more to the point as davidwebca points out i was complaining and not being constructive:

i think taking a system that is already in production on many thousands of sites, and then totally overhauling it to use a completely different backbone is a bad idea. i think taking the entire editor and putting it inside an iframe will break a ton of plugins.

i think my feelings represent that of many people, and we just wish updates were not forced, or better yet were optional, especially for anything that changes the framework of a page that was literally designed to be built on top of by developers.

[davidwebca]

First if you would read about the actual content of the issue and discussion that's been going on, it won't break anything since it's just an iframe wrapper, mostly to guarantee that media queries will be respected correctly.

Second, there are plenty of ways to provide feedback and I can guarantee you that the WP core team listens to all, but they also have to make decisions about what's best for most of the people. Not saying they're always right, but this is clearly not the place for that kind of complaint unless you really have something constructive to add to the iframe conversation. Move on.

[joshm33333]

@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?

this

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).

and this

either of these 2 ideas would solve my concerns

[simison]

@ellatrix I realized I didn't reply your question, better late than never! 😁 Thanks for patience.

Do you mean as an option for block editor implementations, or as an option to a specific block editor implementation like the post editor?

I meant having a filter to turn the content iframe on for good ol' post/page editor, without enabling it for everyone by default.

I believe that would allow more controlled testing (think agencies, personal sites, opinionated site-builders on top of WordPress) and ease a bit @mtias' worries:

One difficulty is that — by its nature — the site editor receives a lot less sustained testing in the way the post editor does, particularly with third-party blocks. But hopefully we can enable it soon as an option to cover more ground.

[simison]

I just learned that iframed content was enabled in mobile & tablet previews already: #33342 —that's fantastic idea that hopefully exposed the iframe to more testing. :-)

[davidwebca]

Curious to know if there's an ETA on this? I remember following this issue to get notifications about this conversation and there's still lots of specificity issues with CSS added to the admin, especially with FSE, that makes it very frustrating for theme devs.

[ellatrix]

New PR: #46212.

[strarsis]

New editor styles transformation approach using PostCSS is now merged (many thanks @zaguiini)!