Problem with the header links on Falkon browser

[beafialho]

An issue mentioned by @joyously here:

[ryelle]

@joyously It looks like this browser uses the QtWebEngine v5.12.8, which I think uses Chromium 69. In this project, we're using the core browser support configuration, so we only support the last two versions of Chrome, currently 97 & 98. It seems like this browser doesn't support flexbox, or maybe doesn't support a property we rely on. Maybe there's an update for the browser?

[joyously]

I checked for updates and found that there was one last month, but it isn't listed on my update manager (which the download page says to use for Linux). The last version was released in 2019, which is the one I have.

It doesn't really matter to me that your project is following a certain set of browser support, but my experience using the .org site is that it is unusable this way. Perhaps your project should consider the menu to be a critical area for functionality, and make sure it works, even with older browsers (progressive enhancement). With it this way, it reflects quite badly on the WordPess brand.

[dd32]

I checked for updates and found that there was one last month, but it isn't listed on my update manager (which the download page says to use for Linux). The last version was released in 2019, which is the one I have.

While the last release available in your update manager was in 2019, it's not the latest release.
The QT version you've got installed is a 2020 version, but it's bundling a 2018 version of Chromium.

If you were running a version of Chrome from 2018, and Linux just didn't offer to install an updated version, would you still blame WordPress.org? or Linux for not updating?

Unfortunately we can't support back forever, but there's a possibility that we might be able to add some Javascript to polyfill whatever CSS rules the browser is unable to process. Looks like it's the :where() CSS selector that's Chromium 88+ and a polyfill seems not-possible.

@joyously What's the Linux distribution & version you're running? Can be duplicated with https://commondatastorage.googleapis.com/chromium-browser-snapshots/index.html?prefix=Mac/576753/

[tellyworth]

Is there no way we can convince node-sass to avoid :where()? Chromium 87 was late 2020, which seems like a pretty short cutoff for browser compat.

[joyously]

I'm running Ubuntu Studio 20.04 LTS.
I don't use Chrome because I can't bring myself to agree to their Terms, so I use Firefox and one of the little-known browsers (like Falkon) as a test browser.

[ryelle]

This particular :where rule is actually coming from Gutenberg's navigation block css, so it'll be a problem on any site using that block with dropdown menus. According to Gutenberg's support matrix, that's in line with supported browsers (and by extension, wp.org's supported browsers). I think any progressive enhancement around this would need to come from Gutenberg.

$ npx browserslist "extends @wordpress/browserslist-config"
and_chr 97
android 97
chrome 98
chrome 97
chrome 96
edge 98
edge 97
edge 96
firefox 96
firefox 95
ios_saf 15.2-15.3
ios_saf 15.0-15.1
ios_saf 14.5-14.8
op_mini all
opera 83
opera 82
safari 15.2-15.3
safari 15.1
safari 14.1
samsung 16.0

@joyously Are you able to manage the experimental flags in that browser? Here's how to do it in Chrome, maybe it'll be similar since Falkon is Chromium-based. You can enable "Experimental Web Platform features" to add support for :where. That should help if you were able to update to Falkon.

[joyously]

Are you able to manage the experimental flags in that browser?

No, as I said, it's my secondary browser, so I treat it as most users would: update when there are updates and use mostly defaults. Doing this, I get a poor UX at .org. Apparently, that doesn't matter to the powers-that-be. Argue if you want for your little supported browser list, but there are probably lots of folks that don't meet that criteria. I think that's fine for the WP product, but not for the .org website.

Edit: explaining this in the dev chat, I realized that the supported browser list was always for the admin pages of a site. Now, however, that list is influencing the front end, which used to be the theme's choice of what browsers to support.

[tellyworth]

Nobody here is arguing that this is intended or acceptable for the dotorg web site.

It seems like a decision about browser compat was made in Gutenberg, and that decision had some unintended consequences. We need to communicate that to the Gutenberg folks and help make sure it gets fixed there.

[joyously]

I think it's more than the header. Now that the news site theme is rolled out, I see problems with the menu and the images causing horizontal scrollbars.
Firefox on left, Falkon on right:

[nylen]

I am using a slightly older version of Firefox ESR (v68) and also see this issue.

It seems like the frontend of the official site for such a widely used CMS should be a bit more tolerant of different browser configurations.

[ryelle]

Reported upstream to Gutenberg WordPress/gutenberg#39230

[ryelle]

#180 was another report of this issue, in Safari 13.1. The :where selector is not supported there either.

@StevenDufresne Unfortunately the fix in #178 won't help because @supports selector() was added in Safari 14.1.

[StevenDufresne]

#178 has been deployed. I'll close this for now, but reopen it with specific environment information if the fix didn't work for your browser.