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

Unprefixed

• CSS writing-mode property
• CSS :any-link selector (-moz- no longer needed, -webkit- still needed)
• CSS Filter Effects
• Intrinsic & Extrinsic Sizing (partial, only -webkit- unprefixed only, -moz- still needed)
• CSS3 Multiple column layout (partial)

Full support

• :placeholder-shown CSS pseudo-class (unprefixed)
• CSS text-orientation (-webkit- prefix for Safari)
• ::placeholder CSS pseudo-element (unprefixed)
• CSS background-blend-mode
• Pattern attribute for input fields
• Form validation
• HTTP/2 protocol
• :indeterminate CSS pseudo-class
• CSS3 Border images
• CSS.supports() API
• :default CSS pseudo-class
• :in-range and :out-of-range CSS pseudo-classes
• focusin & focusout events
• CSS font-stretch
• Download attribute
• Subresource Integrity
• Fetch
• Upgrade Insecure Requests
• CSS font-variant-numeric
• #rrggbbaa hex color notation
• Animated PNG (APNG)
• Minimum length attribute for input fields
• rel=noopener
• SPDY protocol
• "once" event listener option
• KeyboardEvent.key
• CSS justify-content: space-evenly
• CSS Grid Layout (level 1)
• :focus-within CSS pseudo-class

Partial support

• Resource Timing (basic support)
• Opus audio format
• relList (DOMTokenList)
• Scroll methods on elements (scroll, scrollTo, scrollBy)
• system-ui value for font-family
• FLAC audio format

#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.

CSS Grid Layout (level 1) is very useful as it is easier for designers to layout the user interface and make it responsive for mobile devices.

CSS font-variant-numeric could be useful as it is easier to read numeric tables with tabular numerics.

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

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

7 years is a magic timeframe for companies, such that Google supports "7 years of software updates" for Pixel 8 series phones.

Last year, Grade A support for browsers except Safari and Android have restated to last 3 years' versions.

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

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.

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

https://caniuse.com/tls1-3

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

I have updated browser versions to be within 7 years.

I have added affected operating systems

I have previously discussed something similar to this task with Krinkle at https://www.mediawiki.org/wiki/Topic:Tvju6hdstykonsbj (section title "Process to change compatibility" on Talk:Compatibility for if/when Flow dies on MW wiki). I don't know if Krinkle ever followed up on that discussion as they suggested they would.

As said by @Bugreporter at T380344#10339262, Safari doesn't use the "three years' prior revisions" rule for Modern (Grade A) support because the "Safari [on] iOS [cannot] be upgraded individually."

Safari (macOS, iOS): 11 [previous 7 years' versions]

Don't know why changing Safari's Basic (Grade C) support is still proposed in this task.

I think that, as a matter of mission and principle, we should try to support browsers longer than commercial sites do. For example, if the industry standard is 7 years, then we should aim for 10.

But if a browser is extremely unpopular, then we shouldn't invest time in supporting it. For example, while I give 10 years as a possible support length, if almost nobody is using a 9-year-old version of Firefox, and supporting that would require investing a significant amount of dev time, then I don't think it makes sense for us to make that extra effort.