Allow inserting un-namespaced editor styles into the iframe

[andreiglingeanu]

What problem does this address?

This will allow styling the html element in the iframe element in some special situations like when the html tag inherits the body background: https://stackoverflow.com/a/35388084/3220977

What is your proposed solution?

We can already add custom editor styles by using the block_editor_settings_all filter:

add_filter(
  'block_editor_settings_all',
  function($settings) {
    $settings['styles'][] = array(
      'css' => ':root {--test: red;}',
      '__unstableType' => 'theme',
      'source' => 'blocksy'
    );

    return $settings;
  }
);

But they will always be namespaced, that is :root|body|html will be replaced with .editor-styles-wrapper.

The proposed solution is to skip bypassing of transforms for some of the styles here:

We could introduce a skippedTransforms flag to the style which will allow us to skip some of the transforms here:

Related issues

• Dynamic editor styles and inline CSS without targetting .editor-styles-wrapper #18571
• Allow styles to be changed dynamically through editor settings #52767

---

I'm happy to work on a PR with the proposed or an alternative solution.

[ellatrix]

You mean this? #46752 :)

[andreiglingeanu]

@ellatrix yes, but with this new approach everyone will be responsible for scoping their on editor styles into .editor-styles-wrapper?

[ellatrix]

@andreiglingeanu No, there's no need to scope with the iframe, but we will keep scoping outside the iframe.

[andreiglingeanu]

@ellatrix I understand but it seems to me it doesn't cover the use case when someone wants to style .editor-styles-wrapper both in iframed and non-iframed states.

Will it be possible with this new system? If yes, how exactly the selector would have to look like?

[ellatrix]

When the editor is not iframed, .editor-styles-wrapper is the root, which can't be changed. If we don't scope styles they'll leak into the rest of the admin. But from now on the editor should be iframed.

[andreiglingeanu]

@ellatrix even if editor is always iframed, styles are scoped to .editor-styles-wrapper (which is the body tag in the iframe). We want to apply some styles to the html tag of the iframe — that's not possible now.

That's why I'm looking for a way to maybe enable such a thing:

add_action(
	'block_editor_settings_all',
	function($settings) {
		$settings['styles'][] = array(
			'css' => 'html { --test: red; }',
			'__unstableType' => 'theme',
			'skipTransform' => true
		);

		return $settings;
	}
);

---

The editor is still not iframed on the desktop in lots of situations, for example when WooCommerce is active (they still seem to have some non-v3 blocks declared).

[ellatrix]

@ellatrix even if editor is always iframed, styles are scoped to .editor-styles-wrapper (which is the body tag in the iframe). We want to apply some styles to the html tag of the iframe — that's not possible now.

No, that will go away with the PR I linked above.

Regarding non iframed, I'd push block devs to update their blocks to v3 asap.

[andreiglingeanu]

No, that will go away with the PR I linked above.

I can confirm that — just tested your branch. This is amazing!
Will this land in 6.4? From the comments in the PR, it seems like so.

If the above PR will land and the styles won't ever be scoped in the iframe, then this issue can be closed.

---

Regarding non iframed, I'd push block devs to update their blocks to v3 asap

That would be very helpful.

[ellatrix]

Yes, that PR should be in 6.4. Trying to get it reviewed.

[skorasaurus]

#46752 has been merged; so we can close the issue. thanks for reporting @andreiglingeanu