Iframed Content Roadmap

[ellatrix]

Goal: to iframe all editor instances with front-end content.

It seems best to continue to gradually iframe the remaining content. For 5.9, I propose that we iframe the device previews and the block and pattern previews, and iframe the post editor at a later point. This is to give people time to test their blocks, address issues, contact us in case of problems, yet to slightly push them to do so. The previews (block, patterns and full content for device preview) are a good way to do that because they are non-essential while more visible.

Done ✅

• FSE.
• Template editor.
• Block, pattern and template previews.
• Device previews.

WP 5.9-6.0

• Prepare for the post editor.
  • Move the meta boxes (since the scroll container will move inside the iframe, while the meta boxes cannot). Would also allow us to remove the Safari flickering hack.
  • Backward compatibility layer (opt-in) to render blocks in an overlay outside the iframe if absolutely necessary.
    • This is necessary for the classic block, which currently doesn't work in the iframe.
• Refine the iframe component.
  • Remove event bubbling by rewriting:
    • All global shortcuts. Most of these how already been rewritten.
    • The dag chip Block editor: iframe: remove event bubbling and improve draggable chip #34819
  • Allow scripts and styles to be passed to editor settings in WP Dependency handle format, so themes and plugins can add to it. These handles should then be resolved on the server side into a list of assets, which could contain inline scripts and styles as well. See Warning when enqueuing styles for a plugin in iframed Full Site Editor #33212 and Dynamic editor styles and inline CSS without targetting .editor-styles-wrapper #18571.
  • The assets that are loaded into the iframe need to much reduced. Currently we are loading way too many styles in the iframe that are meant for the UI. In some packages like block-editor, we'll need to create a separate stylesheet for editor content (that will be loaded in the iframe). We shouldn't load the whole package stylesheet which mostly consists of UI selectors.
• Move placeholders (editor UI) into shadow DOM. Block editor: placeholders: try admin shadow #33494
• Move appenders (and any other editor UI) out of the content and either into popovers or shadow DOM.
• Ideally the new widget and navigation screens should also be iframed. Who could best do that?

WP 6.2

• Post editor Post editor. Maybe this could be done earlier while it remains off by default. In some future release we could simply flip the switch. Another plugin could potentially flip the switch too. There was some interest for that.

Dev notes

• Blocks in an iframed (template) editor.

[fabiankaegy]

Hi @ellatrix 👋

Do you have any updates on this currently ? :) Would love to better understand what would be needed to make this happen in 6.0 or one of the later releases :)

[fabiankaegy]

Cross-referencing a bug with the rendering in the iframe inside the template editor here: #38110

[TimothyBJacobs]

Cross-referencing a 5.9 regression: #38667.

[cr0ybot]

Not sure where else to leave this comment, but there is one particular issue that I'm dealing with now that will probably get a lot worse as iframes proliferate: SVG linking. I am currently working on a site that uses a single SVG loaded in the header with clip paths that are referenced by id throughout the site. I'm seeing an issue currently with block preview iframes, as there doesn't seem to be a way to hook into them to add things, and enqueueing interfaces really only exist for scripts and styles. I'd love to see an asset API similar to script & style enqueuing that is more generic and able to handle different tags so that I could only "enqueue" the clip paths I need for the specific blocks rendered on the page like we can do now for scripts and styles. But any way to hook into these iframes as suggested in #33803 would help mitigate this.

[ellatrix]

enqueueing interfaces really only exist for scripts and styles

@cr0ybot I believe the duotone filter and layout filter add svg and style elements to the block canvas. Maybe have a look there for how it can be done?

[davidwebca]

Hi @ellatrix! I remember following this issue a while ago - I think it was on another thread or issue? - and I was hoping the block editor would be iframed by 6.0. Do you have knowledge of a timeframe/version number goal for this? Is there another issue that I can follow or is this the best place to be up-to-date?

[annezazu]

@davidwebca thanks for following up here. I see you found #20797 and commented there. There's also this draft PR with recent comments after a meeting: #21102 (comment) That's the latest on these efforts and you're following in all of the right places. Other work has just taken precedence as you can see from the latest roadmaps: https://make.wordpress.org/core/2022/06/04/roadmap-to-6-1/
https://make.wordpress.org/core/2022/09/24/roadmap-to-6-1-core-companion/

[davidwebca]

Thanks so much!

[rmorse]

enqueueing interfaces really only exist for scripts and styles

@cr0ybot I believe the duotone filter and layout filter add svg and style elements to the block canvas. Maybe have a look there for how it can be done?

I've just run into the same issue with SVGs. Deconstructing the duotone filter has led me to a bit of a deadend.

The way it works is to use createPortal for inserting the SVG on BlockList.__unstableElementContext - but BlockList is not available in the @wordpress/components package, and if it was I'm not sure we should be using __unstableElementContext yet.

I think this suggestion might solve the requirement more easily.