Does :where() selector have sufficient browser support?

[mrwweb]

I've noticed that the block styles have started to use the :where() selector which is useful because it can drastically reduce the specificity of CSS selectors. I'm curious how it was decided that browser support is good enough for this to be shipping to 40% of the internet? What is the official browser support policy for front-end styles and does :where() meet it?

Relevant resources:

"The Optional Chaining Operator, “Modern” Browsers, and My Mom"

Turns out, you can’t. From what I could gather, the version of Chrome was tied to ChromeOS which couldn’t be updated because of the hardware. No new ChromeOS meant no new Chrome which meant stuck at version 76.

But what about the iPad? I discovered that my Mom’s iPad was a 1st generation iPad Air. Apple stopped supporting that device in iOS 12, which means it was stuck with whatever version of Safari last shipped with iOS 12.

So I had two older browsers that couldn’t be updated. It was device obsolescence because you couldn’t install the latest browser.

"Evergreen” Does Not Mean Immediately Available"

Support from all evergreen browsers on caniuse.com does not necessarily mean support exists on the device a person is using—updates that have been pushed out don’t automatically get instantly applied.

Because of these two factors, I advocate for tempering your excitement with some restraint. It can be very tempting to rush and use the new and the shiny.

[cbirdsong]

Flexbox gap is in a similar place and is also used heavily as of 5.9: https://caniuse.com/flexbox-gap

There is also a general lack of progressive enhancement in how core's styles are written/output, which exacerbates problems with using bleeding-edge CSS like this.

[chthonic-ds]

What is the official browser support policy for front-end styles

This policy has been referred to in at least one comment, though it's not clear whether it was originally intended to cover front-end as well. This comment suggests only the WordPress back-end/admin was the intended target, would be interesting to understand if this is correct.

[talldan]

Is this just about IE11? If so here's the announcement about dropping support - https://make.wordpress.org/core/2021/04/22/ie-11-support-phase-out-plan/.

That does mention this:

Note: This change will only affect WordPress and it’s built-in features. For your site visitors, any plugin or theme you may be using, which was made with support for IE11 in mind, should still look and feel as if nothing changed.

But it's clear from the rest of that post that this is only referring to the scope of the 5.8 release, it's not a mandate to indefinitely avoid features that IE11 won't support on the frontend.

So my interpretation is that using :where is fine in relation to IE11. A consideration is that there should maybe be dev notes for the newer features.

I'm less knowledgable about the other browsers. Opera Mini seems to have higher usage than I thought it did.

[cbirdsong]

I think it's less about IE11, which is rapidly becoming truly irrelevant (down to ~0.4% by most metrics) , and more about the long tail of evergreen browsers that have gone without updates for whatever reason. The links in the OP talk about some of the reasons for why this happens, and there are no imminent structural changes to how browsers get updated that will appreciably change this dynamic.

In the case of where() and gap, ~12% is a fairly small percentage of global browser usage, but 12% of global browser usage is also a lot of actual people. They both fall into a sort of in-between space where they are quite well supported overall, but not universally supported enough to ship without considering fallbacks.

It's probably worth thinking about this and coming up with a firm policy due to the number of truly transformative CSS features that will be landing in browsers in short term, all of which will spend years in this in-between space and will be much more difficult to use as progressive enhancement compared to cosmetic features like repeating gradients, backdrop-filter or even clamp().

[talldan]

12% is quite high, agreed 😬 .

It seems like there could be policy, but it'd also be impossible to apply a single rule. I think there would maybe have to be some criteria to weigh up individual css features, e.g.:

• What percentage of users are unsupported?
• How breaking is this issue? Is it just a minor visual issue, or will it make the website unusable?
• How much technical debt is introduced by adding a fallback?

Anyway, I think a good option would be to add it to the agenda as a discussion point during one of the meetings (either core-editor or core or both).

[markhowellsmead]

The use of :where as a plaster to fix unnecessarily complex CSS is being applied at a rapid rate in core. Each update breaks layouts and styling on sites, which creates hours or even days of work across an agency's projects. We're close to having to abandon core CSS in the frontend of all of our projects, because it is becoming more and more dangerous to apply core updates.

For example, 5.9.3 - a purported patch update - broke a couple of dozen of our sites by changing the logic of how alignment and x-axis margins work. This isn't because we applied an alternative logic to that which is in core, but because the rules from core are so specific that we have to resort to the use of !important to work around issues highlighted in #36135 and #40159.

I'd be more than happy to contribute to the discussion if I can.

[ramonjd]

Thanks for creating this issue!

I've been testing the following PR

• [WIP] Styles: Remove the ! important tag from user predefined style selections  #40121

and am trying to gauge concerns over the use of :where as it relates to browser compatibility. cc @glendaviesnz

To describe global browser usage I see we've cited 12% as the percentage of global users whose browsers do not support :where. The caniuse page for :where for reference.

As noted above, :where is used liberally in Gutenberg. So is :not, which has similar support.

It would be interesting to know where to draw lines here. For example, 12% is larger than 6%, which is the percentage that doesn't support :first-child. I think it's fair to claim that no one is talking about rolling back :first-child.

At which point between those two numbers, if at all, do we pull the pin?

Or is :where getting special attention perhaps due to its notoriety for having upset the .org website menu.

Are there any further demonstrations of :where() causing problems? Perhaps that would help to guide discussions here as well.

For the record, I'm not arguing one way or the other. I'd only like to see us square the recommended browser support published on Core's best practices page with what folks are experiencing.

To save folks a click the supported browser versions are:

Last 1 Android versions.
Last 1 ChromeAndroid versions.
Last 2 Chrome versions.
Last 2 Firefox versions.
Last 2 Safari versions.
Last 2 iOS versions.
Last 2 Edge versions.
Last 2 Opera versions.
Browsers with > 1% usage based on can I use browser usage table

The above configuration is also available in the @wordpress/browserslist-config module for Browserslist compatible tooling.

If these were strict rules, then I think we'd have our answer. The browsers in red all stand at < 1% usage. Their total adds to 12%... still a sizeable cohort.

Okay, we might still have to support Safari and Chrome for IOS 3.2 - 13.7 whose usage stands at 1.32% (for how long? 😄 )

Contrast this with the statement from 2017 in The New Editor and Browser Support:

Older browsers must continue to be functional, even if the experience does not match that of newer browsers.

Specifically in relation to :where, what do we mean by "functional"?

Does :where carry the potential to break all the things at once? I don't think so. It's been in the codebase for a while.

Or would targeted backwards compatibility fixes after the fact suffice, as they did with WordPress/wporg-mu-plugins#159?

Ultimately, for what it's worth, I agree with @talldan above that the number itself is only helpful in the context of this discussion if we have answers to questions pertaining to consequence, such as impact on UX, the nature of that impact and the implications for developing and maintaining future versions of Core.

[chthonic-ds]

As noted above, :where is used liberally in Gutenberg. So is :not, which has similar support.

:not() at ~94% has much higher support than :where(): CSS selector: Negation pseudo-class selector.

[talldan]

Selectors are tricky, because the level of brokenness depends purely on the styles being applied by the selector.

Here's an issue in the navigation block that I discovered today seems like a situation where :where is the wrong choice - #39230. Site navigation not being functional is a pretty bad outcome.

But I see other usages in the codebase where only things like border are affected, which seems absolutely fine.

[cbirdsong]

The caniuse percentages for :not and :first-child are a bit deceptive as they're so old and well supported that no one has bothered confirming "yes, Opera Mini/UC Browser/etc supports this", leading to those browsers being counted as unsupported.

[cbirdsong]

For the record, I'm not arguing one way or the other. I'd only like to see us square the recommended browser support published on Core's best practices page with what folks are experiencing.

Contrast this with the statement from 2017 in The New Editor and Browser Support:

Older browsers must continue to be functional, even if the experience does not match that of newer browsers.

These are clearly intended to apply to the editor and the Wordpress admin area, not the front-end output of the site. I think these are fine standards for the back-end, but front-end compatibility should be done with more nuance.

Specifically in relation to :where, what do we mean by "functional"?

Does :where carry the potential to break all the things at once? I don't think so. It's been in the codebase for a while.

It will come close if it gets applied here, for one: https://github.com/WordPress/gutenberg/pull/40121/files

Here's an issue in the navigation block that I discovered today seems like a situation where :where is the wrong choice - #39230. Site navigation not being functional is a pretty bad outcome.

But I see other usages in the codebase where only things like border are affected, which seems absolutely fine.

This is the kind of thinking I apply when using bleeding-edge CSS properties, and I'd hope for the same in CSS intended to be used on 43% of the web.

[peterwilsoncc]

I think extrapolating the numbers a little bit will help.

Currently, WordPress is used on 43% of the most popular sites on the internet. 12% of 43% is a little over 5%, so one in twenty visits to the most popular sites on the internet will experience problems if the :where() selector is used in front end code.

The maths isn't perfect, I know, but it's decent enough to be indicative.

Given these numbers, I'd avoid :where on the front end code but continue to use it in the back end in accordance with the browser support policy. I think part of the problem is that when a browser support policy was introduced, WordPress only output styles in the dashboard and only the comment-reply script on the front end.

Things have changed since then.

[markhowellsmead]

100% this.

[tellyworth]

Just noting that this issue directly affects the header navigation on the WordPress.org web site: #39230. It will potentially also affect the layout of the front page when the new version launches soon.

[jasmussen]

I've explored a fix for that in #42964, plus followups to revisit the original problem that was meant to be solved. Let me know your thoughts.

[aristath]

My 2 cents:
WP is not unique in its use of :where, CSS variables and other things like that...
If I'm using IE, an old version of Firefox/Chrome/whatever, then the whole web is "broken". If I haven't updated my browser in 3 years for some reason (even though it's an evergreen browser), then WP is the least of my concerns. At some point we have to draw the line and look towards the future instead of the past... In this case, the benefits are huge and the drawback is slightly mis-styled elements.

[cbirdsong]

I think talking about this as a binary "use/don't use" misses the best route forward: using newer features as progressive enhancement while providing reasonable fallback CSS for older browsers when possible. It's totally fine to use cutting-edge CSS if there's still a functional basic experience for older browsers.

Unfortunately, the CSS shipped with the editor is rarely written with this mindset. Ideally, it would look a lot more like the solution to the :where() navigation problem proposed in #42964, which considers how the CSS might fail and arrives at a way to make things work far better for older browsers at the cost of a slight visual difference, and a lot less like the issue I raised in #41358, which uses (relatively) cutting-edge CSS instead of something well-supported for... no reason at all.