Additional CSS cleared in multisite setup when user is admin on single site

[launchinteractive]

I have a multisite setup. The global admin can add Additional CSS to a block but when a user edits the page that isn't a global admin the Additional CSS disappears.

[iamchitti]

After digging in, I think what's happening here is largely intentional, and I want to lay it out so we can confirm the expected behavior together.

1. A non-super-admin not seeing the "Additional CSS" field is by design.

Block-level custom CSS is gated behind the edit_css capability, which is an alias of unfiltered_html. In multisite, unfiltered_html/edit_css is granted only to super admins (and it's denied to everyone when DISALLOW_UNFILTERED_HTML is set). The block editor only exposes the Additional CSS control when the current user has that capability (canEditCSS). So a regular site Administrator not being able to author or edit custom CSS is consistent with how unfiltered_html has always worked in multisite.

2. The Gutenberg editor already warns before the CSS is removed — this is also by design.

When such a user opens a post that already contains block custom CSS, the editor surfaces this notice:

This post contains blocks with custom CSS. You do not have permission to edit CSS. If you save this post, the custom CSS will be removed.

So the removal isn't silent data loss — the user is told up front that saving will strip CSS they aren't permitted to edit. On save, the edit_css-gated filter added in #64771 removes the style.css block attributes accordingly. Both the capability gate and the pre-save warning are working as intended.

3. To confirm from team

Given the above, the remaining question is whether this is the desired end state or whether we want to soften it. As I see it:

• Accept as designed — custom CSS is unfiltered_html-level privileged; a non-super-admin editing the post can't retain CSS they can't see or edit, and the warning makes the consequence explicit. If this is the intended posture, this can likely be closed as wontfix/documented, and we should make sure the behavior is already covered in the docs.
• Preserve unchanged CSS — only strip custom CSS the current user is actually adding or modifying, and preserve values that are unchanged from the already-stored post. This avoids the "someone else's untouched CSS vanished because I fixed a typo" outcome, at the cost of a lesser-privileged user preserving CSS whose contents they can't inspect. This would need the previous content at save time (e.g. comparing against the stored post via wp_insert_post_data), and would have to compare CSS values rather than block position to handle reordering and duplicated blocks.

My take is that the current behavior (gate + warning + strip) is internally consistent, so my inclination is toward "accept as designed" unless there's scope for the preserve-unchanged approach. Could any maintainer clarify the direction?

[launchinteractive]

That all makes sense and I see why it has been built this way.

My preference would be for WordPress to preserve unchanged CSS. My client didn't read the notice and was wondering why it all changed. I didn't actually notice it myself when I was debugging the issue.

For now I have created a simple plugin that grants them the right capability.