"Additional CSS" (Custom CSS) fails to display in Site Editor preview

[gungfujoe]

Description

The Site/Theme Editor allows you include "Additional CSS" with a style (often the only way to get around current editor limitations), and blocks allow you to add custom CSS classes.. I've done this for my site's navigation bar, and it works well on the page, but not in the site editor. The custom CSS doesn't reflect in the otherwise-fully-rendered display.

Step-by-step reproduction instructions

1. In the theme editor right-side pane, navigate to the "Styles" pane
2. Click the three vertical dots and select "Additional CSS"
3. Define some CSS for a class you want to use
4. Add that class to the "Additional CSS Class(es)" field for a block in a template
5. See the difference between your website and the Theme Editor's rendering of your website.

Screenshots, screen recording, code snippet

The Editor UI has very limited options for styling a navigation menu, so I copied some of the code from my old theme's Navbar class. It could probably benefit from some tweaking, but aside from replacing the colors with variables, it's 20-ish year old code: ul.navbar li a { color: var(--wp--preset--color--base); height: auto; background: var(--wp--preset--color--custom-darker-red); font-weight: bold; border: 1px solid var(--wp--preset--color--contrast); padding: 0.1em 0.6em; white-space: nowrap; } ul.navbar li a:visited { color: var(--wp--preset--color--tertiary); background: var(--wp--preset--color--custom-darker-red); } ul.navbar li a:hover { color: var(--wp--preset--color--primary); background: var(--wp--preset--color--contrast); text-decoration: none; } ul.navbar li.current_page_item a, ul.navbar li.current_page_item a:visited , ul.navbar li.current_page_item a:hover { color: var(--wp--preset--color--base); height: auto; background: var(--wp--preset--color--primary); } ul.navbar li.current_page_item a:before { content: "\00BB \0020"; } ul.navbar li.current_page_item a:after { content: "\0020 \00AB"; } With that CSS defined, and the "navbar" class applied, here's how my navbar looks in the editor:

But here's how the same navbar looks on the site itself:

There's nothing particularly fancy in this code. Since CSS support is built into the editor's UI, it stands to reason that the editor should be parsing that CSS when rendering elements.

Environment info

I'm using WordPress 6.3.1 on my live site and 6.4-alpha-56509 on the dev/test site that the screenshots above were taken from, hosted on a DreamHost VPS account. I'm accessing the site via Firefox 117.0 on Windows 10 Pro

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

Yes

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

No

[jordesign]

Hi @gungfujoe - as this so far is limited to your site specifically - it seems there could be a number of factors at play.

As a start - could you please attempt to disable all plugins, and use one of the default (Twenty*) themes. If the problem goes away, enable them one by one to identify the source of your troubles.

If you can install plugins, install and activate "Health Check": https://wordpress.org/plugins/health-check/
It will add some additional features under the menu item under Tools > Site Health. On its troubleshooting tab, you can Enable Troubleshooting Mode. This will disable all plugins, switch to a standard WordPress theme (if available), allow you to turn your plugins on and off and switch between themes, <strong>without affecting normal visitors to your site</strong>. This allows you to test for various compatibility issues.

There’s a more detailed description about how to use the Health Check plugin and its Troubleshooting Mode at https://make.wordpress.org/support/handbook/appendix/troubleshooting-using-the-health-check/

That will narrow down if this is an issue specifically with Gutenberg, or may be coming from your theme, or a plugin on the site.

[gungfujoe]

Thanks @jordesign , I've done exactly that, and in doing so, I think I've confirmed that this is an issue with the editor, and not with a conflict with any plugin I've got running. Here's a snapshot of my test site (WordPress 6.4-alpha-56510) using the base Twenty Twenty-Three theme in both editor mode and normal display mode, using the same "additional CSS" that I pasted above.

Editor (with the window shrunken down to the point where you can see the "Additional CSS Class(es)" that I've applied:

Resultant page:

As you can see, the custom CSS is ignored in the editor view.

[glendaviesnz]

@gungfujoe I have done some testing, and for me the .navbar class is not added to the ul but to the block nav wrapper several layers up. If I updated your custom CSS to reflect this as .navbar ul li then the styles are applied in the editor as expected:

This is the updated CSS that I used:

.navbar ul li a { color: var(--wp--preset--color--base); height: auto; background: var(--wp--preset--color--custom-darker-red); font-weight: bold; border: 1px solid var(--wp--preset--color--contrast); padding: 0.1em 0.6em; white-space: nowrap; } .navbar ul li a:visited { color: var(--wp--preset--color--tertiary); background: var(--wp--preset--color--custom-darker-red); } .navbar ul li a:hover { color: var(--wp--preset--color--primary); background: var(--wp--preset--color--contrast); text-decoration: none; } .navbar ul li.current_page_item a, .navbar 
 ul li.current_page_item a:visited , .navbar ul li.current_page_item a:hover { color: var(--wp--preset--color--base); height: auto; background: var(--wp--preset--color--primary); } .navbar ul li.current_page_item a:before { content: "\00BB \0020"; } .navbar ul li.current_page_item a:after { content: "\0020 \00AB"; }

[gungfujoe]

@glendaviesnz - Thanks Glen. That's strange, I don't see the same behavior as you, even though what you're saying absolutely makes sense. On my WP installations, when I add the navbar class to those "navigation" blocks in WordPress, the class is added to both the UL and to the NAV:

Regardless, I tried making the Additional CSS more generic, to just work on ".navbar" instead of "ul.navbar," and it made no difference. I still don't see the effects in the editor's display, but it still displays correctly on the site itself, which is to be expected given that the class was added to both elements, such that "nav.navbar," "ul.navbar," and ".navbar" should all behave identically in this structure.

[glendaviesnz]

Sorry about the delay in replying @gungfujoe I will try and take another look at this sometime this week.

[glendaviesnz]

I have tested again @gungfujoe and can't replicate the issue - the custom CSS always displays as expected in the site editor for me, so I have asked some others to see if they are able to replicate the problem.

[andrewserong]

I could reproduce the issue in the site editor with the Navigation block and the provided CSS in this issue. I think what's going is related to the way that the Navigation block differs in the markup that's used while editing the block in the editor versus how it's rendered on the site frontend. With a Navigation block, when you click Edit on the page list, within the editor, it'll switch to editing the navigation children as individual blocks, which uses different markup.

For me, in testing a Navigation block where I'm editing its children as blocks, the markup in the site editor uses nested div elements, whereas on the site frontend it's rendered using ul, li, etc. I believe this is likely due to how the editor works, as the editor is an interactive UI where blocks can be re-arranged, so it likely wasn't possible for the Navigation block to have consistent markup between the editor and site frontend.

What this means for custom CSS, is that I think it's probably more reliable to use the blocks' CSS classnames rather than particular DOM elements. I'd also recommend trying to target individual blocks rather than nested ones. For example, rules that target wp-block-navigation-item or wp-block-navigation-link. If providing a custom classname on a block, then the rules might become .my-custom-classname .wp-block-navigation-item, etc. The key here is to avoid using particular DOM elements or child combinators (>) as the particular elements and hierarchy of those elements will differ between the editor and site frontend.

[github-actions[bot]]

Help us move this issue forward. This issue is being marked stale since it has no activity after 15 days of requesting more information. Please add info requested so we can help move the issue forward. Note: The triage policy is to close stale issues that need more info and no response after 2 weeks.

[gungfujoe]

I don't think labeling this stale is the appropriate action. This appears to be a discrepancy in the visual editor, i.e. a bug.

As @andrewserong said, it appears that the editor replaces UL and LI elements with DIV elements, breaking the CSS used. I can work around this WordPress bug by changing how I define the CSS, but if the visual editor only works as a visual editor if site owners "avoid using particular DOM elements or child combinators," that's a deficiency to resolve in Gutenberg/Wordpress (whether by dynamically changing CSS selectors when the editor dynamically changes element types, or some through some other method).

Thank you, Andrew, for helping me find a workaround. I've been swamped for a few weeks (two trips and and lots of stuff when not traveling), so I haven't had a chance to implement this yet, but the explanation and workaround I need to implement both make sense. I really appreciate you for digging into this to find a solution for me!

[github-actions[bot]]

Help us move this issue forward. This issue is being marked stale since it has no activity after 15 days of requesting more information. Please add info requested so we can help move the issue forward. Note: The triage policy is to close stale issues that need more info and no response after 2 weeks.

[gungfujoe]

@jordesign - Given the additional details above (Andrew's detailed explanation), can you (or someone else with the appropriate permissions) remove the "[Status] Needs More Info" tag from this? It appears to be why the bot keeps trying to send this bug into the dustpan every two weeks. I would assume the devs would want an issue with details of a reported bug to remain active until either they fix it or decide that it should not be fixed, and close it as a known and accepted limitation of the UI.

(I'm tagging you because you added the "Needs More Info" tag. If that's not appropriate, I apologize, and don't intend to hassle or inconvenience you! I appreciate you initiating the discussion with an effort to get more information about this issue)

[glendaviesnz]

@andrewserong what are your thoughts on whether there is anything that can be done to automatically account for this?

I am thinking this might be a case of documenting this quirk so people are aware of the need to target specific selectors when styling the likes of the navigation block due to differences between the site editor and front end.

It seems like this is can be worked around by using the correct selectors, but would be very difficult to automatically account for the difference between the editor and frontend given the large range of different ways that people might structure their custom CSS.