CSS in the editor is sometimes too specific to override

[markhowellsmead]

The CSS for the editor is sometimes so specific, that the only way to override a rule in a custom block's CSS is to use !important. (Or a unique ID selector, which causes problems when re-editing an existing block.)

For example, the following definition forces all figure tags to be 100% wide; irrespective of where in the HTML structure they are.

gutenberg/packages/block-editor/src/components/block-list/style.scss

Line 577 in 87da09e

// This explicitly sets the width of the block, to override

This logic needs to be reviewed and the CSS written (and commented) in a more flexible way.

• Applies when using the Core version of Gutenberg and also when using the plugin at version 6.3.0.

[designsimply]

@markhowellsmead thanks for filing an issue.

The code snippet you linked to sets figure to 100% width when "full-width" alignment is set for an image. The same thing does not happen for images that don't have "full-width" alignment (example). In the 100% width example, I think the logic is sound because the width is only explicitly set to 100% in one case (full-width images) and that seems to be very intentional.

I like that you included a specific example. It also helps a lot to cover why you think a changes is needed and to include reasons and examples showing why it's a problem in your view. We need to be precise because saying "CSS is too specific" by itself is not as actionable because it's so broad and there's already a lot of history as to why each piece of the code was setup as it was.

It may help to note: what is your end goal? Where are you getting stuck specifically? Are you trying to override the width of full-width images so that they are not 100% full-width?

[markhowellsmead]

The difficulty I'm running into is that the figure in question is just one of a number of elements inside the custom block: in my case, being displayed at 100% width underneath a title and text elements in mobile view, but switching to being in part of a CSS Grid layout and sized down to less than 100% from tablet upwards. The only way I've been able to size down the figure to less than 100% in the editor preview is by applying an !important rule, which is a bit of a hack.

The entire site is otherwise hack-free and entirely built using very simple BEM practices; without having to override the editor's own, highly specific CSS, the following is an example of the remainder of the ruleset for the block in question.

.b-courseteaser {
	position: relative;
	&__figure {
		position: absolute;
		top: 0;
		right: 0;
		height: 100%;
		width: var(--courseteaser-image-width);
	}
}

The generated CSS from Gutenberg is as follows; as you can see, excessively specific.

.block-editor-block-list__layout .block-editor-block-list__block[data-align=full]>.block-editor-block-list__block-edit figure {
	width: 100%; 
}

Edit: you mention that the rule “sets figure to 100% width when "full-width" alignment is set for an image” - although this is true, it also affects every single other block which contains a figure element, not just image blocks.

[designsimply]

Edit: you mention that the rule “sets figure to 100% width when "full-width" alignment is set for an image” - although this is true, it also affects every single other block which contains a figure element, not just image blocks.

That's not what I found when I tested. Here are my steps:

1. Create a new post.
2. Add a full-width image.
3. Add a medium-sized left-aligned image.
4. View page source and check to see if figure for the 2nd image is 100% width.

Result: only the full-width image has figure width set to 100%. (54s)
^{Tested with WordPress 5.2.2 (no plugins).}

[markhowellsmead]

@designsimply I do see what you mean. But try it with a full-width block which contains a figure element inside the main element. I would imagine that an image block containing a figure element inside a full-width column block will exhibit the same issue which I’m having. It certainly happens in custom blocks. It comes down to the rule being applied to any child figure element, not just immediate children.

[markhowellsmead]

This no longer appears to be an issue in the cases which I originally tested.