External stylesheets can't override inline core styles

[markhowellsmead]

Description

I'm trying to override inline rules, e.g. .wp-container-1 > *, using rules in a stylesheet referenced through an enqueued stylesheet. The specificity of this selector is 0,1,0.

Using the selector .wp-block-group in the theme CSS is also 0,1,0 and so it should be able to override the inline rule.

However, it cannot because inline styles take precedence over any linked stylesheets.

See also #36135 in particular, as well as #35840, #34047, #29705, #17511 and #39971.

Step-by-step reproduction instructions

Enqueue a stylesheet containing the following CSS. The max-width doesn't override the inline core CSS unless !important is used.

(In practice, the rule is being applied to a custom block with a custom class name, which must always be full-width and whose max-width - or alignment - may not be adjusted in the editor. The example class name .wp-block-group is only being used here for example purposes.)

(The use of !important introduces a large number of subsequent priority rule problems and a large number of experts have been advising against it for a very long time. e.g. MDN Web Docs.)

Screenshots, screen recording, code snippet

.wp-block-group {
    max-width: 1000px;
}

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

[markhowellsmead]

See also #41230.

[ramonjd]

Speaking to .wp-container-1 > *, I've encountered other areas where style rendered by layout override other styles that should take precedence.

I'm referring specifically to blockGap, whereby an attempt to apply a block gap to all group blocks (for example) using theme.json is futile since the layout styles are too specific.

There are a couple of PRs trying to address this bug, namely #40875 and #39870.

As you've noted it highlights a broader challenge regarding the specificity of all CSS properties defined by layout.

In the spirit of the issue about standardizing CSS classnames/tokens, an exploratory PR is out there that generates

class names based on values used in constructing the styles instead of using a random class name. E.g. wp-container-1 becomes wp-layout-default wp-layout-default-content-size-650px wp-layout-default-wide-size-1000px wp-layout-default-global-gap

What are your thoughts about an approach like that?

The layout implementation affects a number of block and site layouts so it's all a bit like tip-toeing on thin ice above a sea of radioactive sharks, but I'm of the view it needs to be refactored, and it will have to before we add further layout options to Gutenberg.

[markhowellsmead]

Thanks for looking into it, @ramonjd, I appreciate it. Some colleagues and I discussed the problematic descendant selector in #36135 last year and we came to a similar solution: using semantic class names makes a lot more sense.

I would suggest:

• that the class names be aligned to BEM logic; e.g. wp-layout-inherit wp-layout-inherit--narrow / wp-layout-inherit wp-layout-inherit--wide; wp-gap wp-gap--default and so on.
• that the class names don't include the pixel size, so that theme and plugin CSS continues to work if the pixel value changes.
• that the width classes (e.g. narrow and wide) use CSS custom properties like --wp--style--width--narrow, --wp--style--width--wide and --wp--style--width--full. (I'm including full because some projects require that alignfull isn't 100% but e.g. 1600px.)

[markhowellsmead]

I would also note that !important is still being referenced in code examples in that PR, which are themselves contributing to specificity problems. There are several issues open on this subject: https://github.com/WordPress/gutenberg/search?q=%21important&type=issues

[markhowellsmead]

…and your comment about justification class names also hits home: see #41230 and #38719.

[cbirdsong]

I generally like the idea of abstracting layout out into predictable classes like .wp-layout-<whatever>, but I think it would be best if the layouts were conceptualized more cleanly and holistically instead of merely retrofitting what exists into the style engine.

.wp-layout-default and .wp-layout-flex do not describe what the layout is intended to manage, especially since apparently the flex one might be wrap or nowrap, which leads to very different results. Every .wp-layout- should have a clear and defined responsibility in the way that the different layouts on Every Layout do, and options and variations on these layouts should do nothing but supply what is needed to make those adjustments, ideally via custom properties.

I'd also agree with the use of !important – it should not be there.