The CSS class `is-dark-theme` is not set in the post editor

[afercia]

Description

Splitting this out from https://github.com/WordPress/gutenberg/issues/60275

To be more accurate, in the Post editor the CSS class is-dark-theme is initially applied but than removed. In the Site editor, it works as expected.

It seems to be something missed with the refactorings of the editor irame, editor styles scoping and such.

When a theme has a dark background color, useDarkThemeBodyClassName is responsible for adding the is-dark-theme CSS class to the editor iframe body element.

It does that, but then the body gets updated and gets new CSS classes when the iframe is fully loaed, see the Iframe component internal handling of the classes in the onload callback and then the classes are set to the body.

I'm not sure whether that means the body gets entirely replaced. Regardless the new CSS classes replace the initial ones thus removing is-dark-theme it it was set.

The is-dark-theme CSS class is necessaty to make some editor features and styles work correctly.

Step-by-step reproduction instructions

• Set Twenty Twenty-Four as active theme.
• Go to the Site editor > Styles, set a theme style variation that has a dark background e.g. 'Onyx' and save. Update: the Site editor UI has changed and now 'Onyx' is shown as a palette variation in the Styles panel > Browse styles
• In your browser dev tools, inspect the editor iframe body ie. the body with CSS classes block-editor-iframe__body editor-styles-wrapper.
• Observe the body does have a CSS class is-dark-theme.
• Go to the Post editor.
• Observe the editor shows the theme variant with dark background.
• In your browser dev tools, inspect the editor iframe body ie. the body with CSS classes block-editor-iframe__body editor-styles-wrapper.
• If you inspect it very quickly, you will notice that initially the body element has these CSS classes: block-editor-iframe__body editor-styles-wrapper is-dark-theme.
• When the iframe is fully loaded, observe the element body element does not have the is-dark-theme class.
• Observe the body element CSS classes have been replaced with block-editor-iframe__body editor-styles-wrapper post-type-post admin-color-fresh wp-embed-responsive.

Screenshots, screen recording, code snippet

No response

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

[afercia]

The commit to fix this issue was reverted to fix a problem with Safari, see https://github.com/WordPress/gutenberg/pull/60616.

I'm reopening this issue as it needs to be solved, but with a different approach.

[ellatrix]

Not sure if that would break anything, but maybe the best wait to fix the issue is to move is-dark-theme to the html element, which is not managed in React?

[afercia]

Based on this comment, looks like the problem with Safari is broader because also the CSS classes admin-color-{$color_scheme} and wp-embed-responsive seems to not be set correctly in Safari. However, I can't reproduce that issue on trunk.

Regarding the bug reported at https://github.com/WordPress/gutenberg/pull/60550 I'm not sure the root cause was the change in https://github.com/WordPress/gutenberg/pull/60300 as that change followed an already existing pattern used for the admin-color-{$color_scheme} and wp-embed-responsive classes.

Anyways, to illustrate a couple of the issues triggered by the missing is-dark-theme CSS classe, please see the screenshot below. It's just two examples. there are probably more issues.

A block in 'select mode' now shows a blue outline (left) but it is supposed to show a white outline (dark):

In addition to the outline, the Spacer block, when selected, shows a full dark background (left) but it is supposed to show a lighter background (right):

[ellatrix]

My suggestion would be to move the class to the html element so that it's not overridden later on

[afercia]

My suggestion would be to move the class to the html element so that it's not overridden later on

I've been testing pretty exensively. While moving the class to the thml element seems trivial, it doesn't work well anyways with themes that may handle the body background dynamically. For example, Twenty Twenty-One does have its won 'dark mode toggle' feature that changes the body background after the editor useDarkThemeBodyClassName checks the background color luminance.

That's a pre-existing issue and I suspect it never worked well. However, it seems there's a need to a better mechanism to get the actual body background color even when it gets changed by themes or plugins features.

[afercia]

A first attempt to fix this issue was reverted in https://github.com/WordPress/gutenberg/pull/60616. I can still reproduce the incorrect behavior in the Post editor. @glendaviesnz @ellatrix any change to explore an alternative approach to fix this issue> RIght now, the implementation of the is-dark-theme class in the Post editor is just broken.