Open eric-michel opened 4 months ago
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:
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.
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.
Description
WP 6.5 introduced the a new
aspect-ratio
tool to the Cover block. It breaks existing child theme CSS that setsaspect-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 ofaspect-ratio: unset;
is output into the Cover block. This will override any custom CSS applied to the block that controlsaspect-ratio
within the theme.This breaks all of our block theme sites. We apply a custom
min-height
in the block controls and anaspect-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
min-height
set in the block controlsaspect-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