fix: load core block styles unscoped so responsive embeds size correctly

[dcalhoun]

What?

Fix collapsed YouTube embeds.

Why?

YouTube embeds rendered with a height of zero, and the video could not be seen.

How?

Hoist core block styles to the body rather than scoping them to the visual editor element. Previously, the styles were not applied to the embed due to the incorrect nested selector.

Testing Instructions

1. Insert a YouTube Embed block 
2. Set a valid YouTube video URL for the block
3. Verify the YouTube embed is visible and playable

Accessibility Testing Instructions

N/A, no changes to navigation.

Screenshots or screencast

Before	After

---

AI-generated details

Problem: Aspect-ratio embeds (e.g., YouTube) render at zero height. Since #247, block-library/style.css and block-editor/content.css are passed to the non-iframed BlockCanvas, which scopes them under :where(.editor-styles-wrapper). The responsive embed rules (.wp-embed-responsive .wp-has-aspect-ratio iframe) then require wp-embed-responsive inside the wrapper, but GutenbergKit sets it on <body>, so they never match. WordPress never scopes these stylesheets, whether the canvas is iframed or not.

Change: Load those stylesheets (and RTL variants) unscoped in the injectEditorStyles base layer, ordered like WordPress's wp-edit-blocks dependencies. Drop the canvas copies, including the duplicate components/style.css and block-library/editor.css. The canvas now only receives theme styles and GutenbergKit's default/common styles, so theme styles again come after the core block styles, as in WordPress.

Related regressions: #332 (Cover popover broken by scoping) and #363 (Featured Image button lost a source-order tie to the duplicate canvas components/style.css) both trace back to #247. With one copy of each stylesheet in the base layer, editor.css follows components/style.css, so the Featured Image button stays 48px.

Font-size side effect: Block library's legacy :root presets (huge: 42px, normal: 16px) no longer override other preset values. Without theme styles, GutenbergKit's default theme styles now apply (huge: 96px, normal: 20px), matching behavior before #247. With theme styles, a theme's own huge/normal presets now win, as in WordPress. This affects only content using the legacy has-huge-font-size/has-normal-font-size classes.

Verified: iOS simulator: YouTube embed renders at 16:9 (342 × 192), Featured Image placeholder button is 48 × 48, and Cover was checked manually. A new E2E test asserts the embed preview keeps its 16:9 height; it fails with a height of 0 without this fix.

🤖 Generated with Claude Code

[wpmobilebot]

XCFramework Build

This PR's XCFramework is available for testing. Add the following to your Package.swift:

.package(url: "https://github.com/wordpress-mobile/GutenbergKit", branch: "pr-build/786")

_{Built from 668d681}

[nbradbury]

@dcalhoun The changes look good to me and I'll approve. Claude reported a couple issues than may or may not need to be addressed.

Severity	Location	Issue	Impact
Medium	visual-editor/index.jsx:78	Dropping ...canvasStyles moves block-library, content.css and components styles from last place in the cascade, inside BlockCanvas, to the first stylesheet in <head>.	The non-iframed :where(.editor-styles-wrapper) scope adds no specificity, so these rules used to win every tie. Now theme editor styles, commonStyles, defaultThemeStyles and GutenbergKit SCSS such as .gutenberg-kit-visual-editor .wp-block-image > div:first-child win those ties, which can change how blocks and placeholders render (the new test only checks the YouTube embed height).
Medium	editor-styles.js:7	Loading block-library style.css and block-editor content.css globally reverses 097df6a's deliberate canvas scoping, when adding wp-embed-responsive to blockListClasses inside the wrapper might fix the embed on its own.	Rules such as :where(figure){margin:0 0 1em}, .screen-reader-text and html :where(img[class*=wp-image-]) now reach editor chrome like the inserter, popovers, modals and toolbar, not just the canvas.

[dcalhoun]

@nbradbury thanks. I believe both are benign.

For the first, the reorder is correct in that it aligns with WP Admin's ordering. I did manually test the Featured Image and Cover block placeholders when making this change, and those render as expected.

For the second, this was an intentional reversal of the canvas scoping to align with WP Admin's usage of body classes. There is risk of style leakage to the editor chrome, but it is necessary and tolerated by WP Admin as well.