Container blocks use unsupported :where() and :not() selectors

[iandunn]

Description

The Group, Columns and Buttons blocks use :where() and :not() selectors, which aren't supported by many browsers that we still need to support. It may affect more blocks, those are just the ones that I ran into.

The same issue happened with the Navigation block in #39230 and was fixed in #42967. There's a discussion about the broader problem in #39621.

Step-by-step reproduction instructions

1. Activate TwentyTwenty Two
2. Paste the snippet below into a new page
3. View the page in Chrome 87, with the viewport width above 1300px

You can also see it happening on https://testing.wordcamp.org/2019/wherenot-test/.

Screenshots, screen recording, code snippet

<!-- wp:group {"align":"wide","style":{"spacing":{"padding":{"top":"120px","right":"0px","bottom":"120px","left":"0px"},"blockGap":"30px"}},"layout":{"inherit":false}} -->
<div class="wp-block-group alignwide" id="intro" style="padding-top:120px;padding-right:0px;padding-bottom:120px;padding-left:0px"><!-- wp:columns {"style":{"spacing":{"blockGap":"0px"}}} -->
<div class="wp-block-columns"><!-- wp:column {"width":"85%"} -->
<div class="wp-block-column" style="flex-basis:85%"><!-- wp:heading {"level":1,"textColor":"charcoal-1","fontSize":"heading-cta"} -->
<h1 class="has-charcoal-1-color has-text-color has-heading-cta-font-size">WordPress: Publish your <em>passion</em></h1>
<!-- /wp:heading --></div>
<!-- /wp:column -->

<!-- wp:column {"width":"15%"} -->
<div class="wp-block-column" style="flex-basis:15%"></div>
<!-- /wp:column --></div>
<!-- /wp:columns -->

<!-- wp:paragraph {"align":"left","className":"is-style-short-text"} -->
<p class="has-text-align-left is-style-short-text">Create a place for your business, your interests, or anything else—with the open source platform that powers the web.</p>
<!-- /wp:paragraph -->

<!-- wp:buttons -->
<div class="wp-block-buttons"><!-- wp:button -->
<div class="wp-block-button"><a class="wp-block-button__link wp-element-button" href="/download/">Get WordPress</a></div>
<!-- /wp:button --></div>
<!-- /wp:buttons --></div>
<!-- /wp:group -->

Environment info

• Chrome 87 (or any browser that doesn't support :where / :not)
• Viewport width above 1300px
• Mac Catalina
• Gutenberg trunk @ 132b86c. Also tested in 14.0.2
• Core trunk @ WordPress/wordpress-develop@21ebdbc

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

[iandunn]

It looks like this also affects the Columns and Buttons blocks.

[cbirdsong]

Related discussion:

• Does :where() selector have sufficient browser support? #39621

[carolinan]

Can you help clarify which browser support requirement are you referring to? This list :
https://make.wordpress.org/core/handbook/best-practices/browser-support/ ?

[iandunn]

AFAIK that list has always been for wp-admin, and we've never had a policy for the front end. Before Gutenberg, it wasn't needed, but it is now because Core is generating so much front-end CSS. So far the wp-admin policy has been unintentionally used for the front end, and that's been causing problems in production block themes.

There's more background and discussion is in #39621.

[cbirdsong]

Based on the discussion linked above¹ (#39621 (comment), #39621 (comment)), it seems like that list was intended for the admin area and editor, not front-end output. The continued appearance of issues like this seem like evidence enough that user-facing code should have a different standard for support.

---

Also, worth noting: :not() is very well supported when used with a single selector, but less well supported with multiple selectors. A multiple selector :not() like :not(a, .b, [c]) can be rewritten as :not(a):not(.b):not([c]), ending up in the same place but with far more browser support. It looks like almost all of the :not()s on the test page in the OP are chained single selectors. The only one that isn't is a very narrowly targeted bit of the buttons block:

.wp-block-buttons:not(.is-content-justification-space-between, .is-content-justification-right, .is-content-justification-left, .is-content-justification-center) .wp-block-button.aligncenter {
        margin-left: auto;
        margin-right: auto;
        width:100%
    }

This would be an easy fix, but it is another (small) case where the editor is shipping less compatible CSS to ~40% of the internet for no real reason. (See also: #41358)

Footnotes

1. First by the OP and then by me, not reading the OP thoroughly enough – sorry! 😅 ↩

[carolinan]

Then can the best practice for the front end be established and documented, including a supported browser list?
Is there one for internal use for WordPress.org already?
It needs to be easy for the developers to know what the expectations are.

[iandunn]

That would be perfect, I agree 💯 . That's probably beyond the scope of this issue, but I can see it maybe being a blocker for this.

w.org doesn't have any formal policy. Practically speaking, if a real user reports having problems, then we look into it, and if it seems reasonable we fix it. Fixing doesn't have to mean pixel-perfect, though, just functional and not bad-looking.