Clear block-level inline styles on theme switch and other actions that affect global styling

[nickcernis]

Is your feature request related to a problem? Please describe.
When someone applies a font or color override to a specific block via the block's properties, they pick their color and font in the context of the currently active theme.

They can comfortably set a specific block’s text color to slightly-off-white if their current theme has a black background, for example.

If they then switch to a theme with a white background, they will find their site has off-white-on-white text, because the block’s user-modified text color settings override any general theme styling if it was applied with inline styles.

Impact

1. The potential for scenarios like this expands if more blocks add user-changeable properties that generate inline styles.

2. Themes that use global styles will not be able to make guarantees that those global styles will take effect on theme activation, because block-level inline styles will override them.

3. Inline styles could also prove confusing for users who switch themes, tweak the new theme's global styles, and do not understand why text or background colors are not changing for blocks with inline styles.

4. With full-site editing, inline styles the user applies to blocks outside the main content area will also be affected – those sections may now also be rendered inaccessible or ugly after a theme switch.

Pre-Gutenberg, theme switches were generally safe. Switching theme would not leave any part of your site in an inaccessible or ugly state. Blocks are great and I'm looking forward to using global styles, but the current situation feels like a regression for user experience.

Current workarounds
Users currently have to adjust any block settings that add inline styles if they clash with their new theme. They have to do this manually for every affected block, which may be spread across their site on separate pages and posts.

Theme developers can apply styling that attempts to override any inline styles so that their theme appears as expected, but users can then no longer adjust styling at the block level.

Describe the solution you'd like
Some options we could explore:

1. Consider resetting any block properties that affect inline styles following a theme switch. (I recognise that this may require rearchitecting how inline styles are applied, perhaps hooking into the new global styles system to apply block-level classes and accompanying global styles that could then be cleared after a theme switch.)

2. Additionally, provide developers with a programmatic way to reset inline styles in response to a user action.

3. Optionally, give users a way to bulk-reset style overrides if they wish to do so. This could be at the site level, page level, block template level, or all of the above.

Describe alternatives you've considered

• Continue to patiently field support requests asking why themes do not look like their demos on activation.
• Keep teaching users to manually remove inline styles they have applied to their content if they clash with the new theme design.
• Accept that themes can no longer make any promises about the site appearance when they are activated, which potentially diminishes the value of themes.
• Accept the risk that theme activation can result in inaccessible content that the site owner may not discover until they are sued for breaking WCAG standards. (Not likely for most site owners, of course, but should this even be a possibility?)

Previously
I found some closed related issues, but they don't appear to address the concerns above with inline styles:

• Proposal of removing inline styles #2862
• Blocks and Theme Styling Overview #5360

[youknowriad]

Global styles edits as far as I know are theme specific and don't carry as you switch themes. So I'm closing this issue for now. Please let me know if I'm not understanding properly.

[cbirdsong]

This issue predates global styles and full-site editing. It's about users manually setting colors on blocks that work with one theme but would not work with another. A systemic approach to color like the ones discussed in #39372, #48581 and #29568 could help mitigate this issue.

[youknowriad]

Oh I guess the "global styles" label applied to the issue tricked me. Do you think the linked issues capture the scope of this issue properly or should we reopen it again?