Aspect ratio support breaks child theme CSS when unnecessary

[eric-michel]

Description

WP 6.5 introduced the a new aspect-ratio tool to the Cover block. It breaks existing child theme CSS that sets aspect-ratio on the Cover block even when the control is unused in the editor.

When a custom min-height is selected in the Cover block controls, an inline style of aspect-ratio: unset; is output into the Cover block. This will override any custom CSS applied to the block that controls aspect-ratio within the theme.

This breaks all of our block theme sites. We apply a custom min-height in the block controls and an aspect-ratio property via a custom class to most of our Cover blocks.

Problems with CSS specificity been discussed ad nauseam, so I won't go on for too long, but even if we accept that of course the editor will have CSS changes from time-to-time, adding an inline unset of a property that isn't being set in the editor is incredibly frustrating.

Long term, I'm confident that eventually cascade layers will solve this issue, but as @cbirdsong has rightly pointed out, there is no polyfill or progressive enhancement we can use to incrementally implement them, so we have to wait for widespread browser adoption. In the meantime, there has to be more attention given to how CSS changes are applied.

Step-by-step reproduction instructions

1. Install WP 6.5
2. Add a cover block with a custom min-height set in the block controls
3. Inspect the frontend of the block and notice that the main Cover block container now unset aspect-ratio

Screenshots, screen recording, code snippet

No response

Environment info

WP version 6.5.2, any block theme.

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

[cbirdsong]

We ran into a similar issue when aspect ratio support was added to the image block, which also introduced inline CSS. A theme should easily be able to opt out of all new editor features on existing blocks. I do not have the capacity to go back and add whatever: false to the theme.json file on every theme I’ve worked on every time there’s a major new WP version.

Also, related: Inline CSS continues to be a terrible thing for a CMS that powers 40% of the Internet to build its editor on. There are so many reasons it should be avoided:

• https://github.com/WordPress/gutenberg/issues/54033

Relatedly, on this point:

Long term, I'm confident that eventually cascade layers will solve this issue.

You can’t use cascade layers with inline CSS. I order to adopt them, every bit of inline CSS will need to be reworked to use classes in some capacity, but usage of inline CSS is only increasing.

[eric-michel]

You can’t use cascade layers with inline CSS. I order to adopt them, every bit of inline CSS will need to be reworked to use classes in some capacity, but usage of inline CSS is only increasing.

This is a great point that I kind of glossed over. Inline styles have definitely caused a considerable number of issues. In this case, I think it's particularly egregious, because it's unsetting a property that isn't being set in the editor. It's one thing to set an inline style property that the user is explicitly setting in the editor where there's a reasonable assumption of that property needing high priority, it's another to unset a property that isn't be interacted with at all.

It's getting to the point that I feel like I should just stack all our sites' CSS files with !important flags just in anticipation of this happening every release cycle.