I mentioned that CSS Grid Layout and #rrggbbaa/#rgba hex notation need this version bump. Both are very useful.

Usually better to use our own stats.

I clarified that TLS 1.3 supports Safari macOS 12.1+ (on macOS Mojave and later) and Safari iOS 12.2+.

Let's give a update to market share:

• Chrome 49: 0.02%
• Chrome 50: 0.01%
• Chrome 53: 0.01%
• Chrome 56: 0.02%
• Chrome 66: 0.02%
• Chrome 69: 0.08%
• Firefox 52: 0.04%
• Firefox 56: 0.01%
• Safari 12.1: 0.01%
• Safari 13.1: 0.06%
• Safari iOS 10.2: 0.01%
• Safari iOS 10.3: 0.04%
• Safari iOS 11.2: 0.16%
• Safari iOS 11.4: 0.01%
• Safari iOS 12.1: 0.01%

TLS 1.3 is also available in Safari 12.1 and later. Full support in macOS Mojave and later, and iOS.

I agree it would be ideal to move to a rolling window like Grade A for simplicity, but in practice Grade C is meant to capture a much wider net of readers which doesn't always correspond to a specific timeframe. Like I suggested in T380344#10349484, if there's no specific product/feature that needs this version bump we should probably wait to see how T367821 develops because it might make 7 years not even applicable.

Additionally, MediaWiki would feature new CSS features as time progresses.

Timeframe is useful as market share for older versions of browsers drop as time progress.

Why 7 years and not 6 or 8? Why introduce a timeframe?

#rrggbbaa hex color notation is very useful as it is easier to create translucent colors which having to resort to rgba(). Let's say if you want to create green color with 60% opacity, you only need to type #00800099 instead of rgba(0, 128, 0, 0.6). It uses nine bytes instead of 20, so it can use less data. Additionally #RGBA is even smaller, at only 5 bytes.

Here are the new HTML/CSS properties when going from Chrome 49/Safari 10/Firefox 49 to last 7 years' versions.

Thanks for the report!

In T189901#9475400, @Bhsd wrote:

This will automatically be fixed with CodeMirror 6 upgrade.

Indeed it doesn’t. (Despite major refactorings, this piece hasn’t changed in the past almost twelve years.) But why should it? And to what? Unfortunately you failed to tell what you expect, without which it’s impossible to make the software do what you expect.

The Ctrl+B and Ctrl+I behaviors in the 2010 Wikitext editor will be changed for T62928.

Tried Narrator on Microsoft Edge (Chromium) 109 on Windows 7. Somehow, it doesn't read Edge's web content, apparently. Nonetheless, at least Chromium Edge has its own Immersive Reader, which reads content aloud.

Almost forgot: I read some thread about Microsoft Narrator being incompatible with Google Chrome but works well with Chromium(?) Edge. And the thread is early this year, NOT years ago. As I can assume, this is concerning Windows 10 or 11.

Here's a screenshot of huwiki with the dev tools setting enabled:

In T375181#10171059, @Bean49 wrote:

There's the point. Most of the sites are not providing dark mode. As I said, if I set both dark modes, the icons are visible but many features are not readable. At least on huwiki.

There's the point. Most of the sites are not providing dark mode. As I said, if I set both dark modes, the icons are visible but many features are not readable. At least on huwiki.

In T375181#10169527, @Bean49 wrote:

Thank you. Is there any CSS trick I can apply until then?

Thank you. Is there any CSS trick I can apply until then?

Hi @Bean49 – this is a Chrome bug; I've filed an upstream bug report here: https://issues.chromium.org/issues/369085363

We think it was caused by T363920 but we'll have to investigate more next week. That change was intentional, so we're not sure yet if there's a good solution that'll work for both MediaWiki dark mode and Chrome's Auto Dark Mode.

Could you tell please what is the reason for the change? Is it intentional? Can it be changed back?

Isn't auto dark mode an experimental feature? Or did it get moved out of chrome://flags ?

I don't think we can guarantee experimental browser features will always work, but we will look into this to get a better understanding of what changed to cause this to break and see if we can offer up a fix.

It's not about preference. If I set both dark mode options, Wikimedia Vector 2022 and Chrome, the result is even worse. The inversion worked until Sep 6.

First a question out of curiosity: Do you prefer Chrome's Auto Dark Mode over Wikimedia Vector 2022's own optimized?
From what I understand about that proprietary feature, there is a possibility to fine-tune how it's applied in the settings. For example 'Enabled with selective inversion of non-image elements'