FSE script into iframe insertion needs to be less restrictive on how it determines whether to include a stylesheet

[albanyacademy]

Description

In the Site Editor, Block CSS should be included without needing to use wp-block as a CSS selector in the built stylesheet, it should be included in the iframe by virtue of it being registered through enqueue_block_assets.

My suggestion would be to add to enqueue_block_assets a data-attr/some "block asset" identifier to just scan for instead, because whether or not the right selectors are in the stylesheet shouldn't be the sole criteria for including it in the FSE.

Step-by-step reproduction instructions

1. Build a bunch of blocks with separate editor and generic stylesheets
2. Don't use ".wp-block" as the main classname/selector for your custom blocks.
3. Go into FSE and use your custom blocks
4. Observe that their styles are not included inside the iframe.

Screenshots, screen recording, code snippet

Specifically this section:
https://github.com/WordPress/gutenberg/blob/0a6a23b213c4fe9e3b337c8b71fa87bbf82c4496/packages/block-editor/src/components/iframe/index.js

function matchFromRules( _cssRules ) {
				return Array.from( _cssRules ).find(
					( {
						selectorText,
						conditionText,
						cssRules: __cssRules,
					} ) => {
						// If the rule is conditional then it will not have selector text.
						// Recurse into child CSS ruleset to determine selector eligibility.
						if ( conditionText ) {
							return matchFromRules( __cssRules );
						}

						return (
							selectorText &&
							( selectorText.includes(
								`.${ BODY_CLASS_NAME }`
							) ||
								selectorText.includes( `.${ BLOCK_PREFIX }` ) )
						);
					}
				);
			}

			const isMatch = matchFromRules( cssRules );

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[albanyacademy]

Just want to clarify, the exact problem I was experiencing is also the result of my naming of the stylesheets themselves.
the inline section here https://github.com/WordPress/gutenberg/blob/trunk/packages/block-editor/src/components/iframe/index.js#L107 seems to be doing a simple find-replace for "css" within the stylesheet ID, which breaks when you include "css" somewhere in the enqueue handle yourself. so inline stylesheets i was adding weren't showing up either.

either way you can't progress to that specific bug without including wp-block in your main stylesheet somewhere (i've just slapped it in with a dummy variable) ala:
.wp-block {--nothing: none}

this pretty much circumvents the problem above, and not naming your enqueued assets with "css" somewhere in there also helps.

[albanyacademy]

Update: this is also failing to load custom third party stylesheets, like Google fonts or Typekit. Kinda pressing.

[spacedragn]

Same here. Adobe Fonts/Typekit renders properly on the front-end. But the Block Editor ignores the enqueued CSS file across all browsers (Mac), and Network Inspector confirms no font files are loading.

This plugin loads Typekit via API, which temporarily solved my issue. You can also load Typekit via JS as a potential workaround.

[ellatrix]

Hi!

The wp-block selector detection is a back compatibility script, in case the stylesheets are not added to the iframe correctly.

We've done lots of work in WP 6.3 to make sure that there are always ways to add stylesheets to the iframe without the compatibility script. Since #49655, you can use the enqueue_block_assets to enqueue assets for the iframe, so your problem should be fixed. Also see this dev note for more information: https://make.wordpress.org/core/2023/07/18/miscellaneous-editor-changes-in-wordpress-6-3/#post-editor-iframed

[spacedragn]

Thanks for clarifying here. Switched to enqueue_block_assets and can confirm the desired assets are loading in the Site Editor as expected. This includes Adobe Fonts/Typekit CSS files.

[albanyacademy]

YESSS thank you!