Your browser will soon be incompatible with this community. To keep participating here, please upgrade your browser or learn more.
By the way this banner “learn more” link to this topic does not follow the Open all external links in a new tab setting. It loads in current tab.
Wine is at this point getting pretty well developed I believe. It started mostly in gaming circles but has had development help ($$$) in recent past
Disclaimer: no recent experience
What are you going to use relative color syntax for?
More compact stylesheet?
Could you maybe cancel the planned use of relative color syntax?
While those are some features we have identified we wanna use today, dropping those browsers whose maintainers deprecated allow us to also explore other things. For example, Import maps | Can I use... Support tables for HTML5, CSS3, etc is something that will be enabled by this same change and that could speed up Discourse for the 99% of users. Offscreen canvas is already used for image compression on Discourse for many years also becomes available on all target browsers with this update.
Still same here.
Has anyone found a workaround?
I already tried 5 or 6 user agent spoofing extensions. There are many, but the ones I tested were not really good to use. And most of them were not per site.
I still need on Android 9:
And being able to use Discourse (read/write).
I guess I’ll have to test all of the user agent extensions, one by one… 
We are not looking at the user agent, so spoofing it won’t help.
We’re using feature-detection for the three features mentioned in the OP. If the browser doesn’t support them, the warning banner will be triggered.
Have you tried reporting the issue to Kiwi developers? It sounds like their Chromium version should support relative color syntax, so maybe they disabled it? Perhaps accidentally?
Oh, that’s good.
Will it be like this in 1st May version, as well, or will you test versions?
Kiwi is no longer maintained.
Yes, we’ll add these to the existing list of features which Discourse checks for 
You say this change will speed things up for 99% of users — fair enough. But the flip side is that you’re completely cutting off access for the remaining 1%.
So, how many actual people are in that 1%?
If the number feels uncomfortable to post here because it’s not as small as it sounds in percentage terms, then maybe it’s worth reconsidering whether they’re truly insignificant enough to cut-off access to.
Most of my machines are modern, but I just got this message on one which cannot be upgraded.
I guess the baseline will always be moving, but I would request if possible, for a clean fallback so that non-supported browsers have minimal ability to: log on, view and create posts/threads even if they then cannot use all the bells and whistles.
WHY?? This is discrimination against people living in 3rd countries!
Don’t break the internet, it has been around for 35years!
To me this issue seem far larger than Discourse. This is an issue of the Hardware vendors, Operating System vendors, and Web Browser vendors of cutting off support, updates, and upgrades way too soon. The cost for the updates needs to be at a minimal monetary value so all can have them.
Discourse and other software (including apps) developers are really at the mercy of the ecosystem that we live in.
Discourse will be the first site I use to block my (Android) browser, though.
Based on the feedback from the community, and the extra information we’ve collected about the effect on Windows 7/8, we’ve decided to delay this change until after the next Discourse stable release in July 2025. That will give communities and users another 3 months to prepare for the change.
That also give self-hosted administrators the option to switch their communities to the stable branch, which will continue working on older browsers until the following release at the beginning of 2026.
To enable us to keep pushing forward with new technologies, our new “Horizon Theme” is already using some of these modern browser features. For sites running Horizon, users of old browsers are already being shown the basic-html view.
I’ll update the OP here accordingly 
Excellent. Can I encourage you (aka Discourse) to view these kinds of adoptions as an accessibility and an inclusivity issue?
Thank you.
During that time, please consider also continuing to provide a version of Discourse that will continue to be usable on old equipment and that, while it may not include all features, does include the ability to post and to start threads as well as to read.
Thank you! This helps for sure, and reduces the panic.
But:
are both still very valid points.
I think what many of us are arguing isn’t that X feature should or should not be supported by Y version for Z time, but that Discourse should offer graceful degradation, maybe something like a plain HTML + HTTP POST mode like the earliest forums offered. Ideally that would be prioritized over new features, especially over cosmetic changes, but I’d argue also over performance optimizations.
Discourse users shouldn’t have to choose between community and new features — and that part of it DOES seem like a cultural question. It seems the devs want to “move a little fast, not too fast, break a few things but not too many”. That might be a perfectly reasonable position for a software company to take, but it is NOT necessarily the same position that Discourse communities would want. Some communities would want to move faster while others would prefer much slower or no movement at all.
To me, Discourse today is already “good enough” and if there were an option for hosted customers to choose a long-term support branch with no new features added for the next 10 years, only critical security fixes, I’d totally choose that — even if the new version were 10x faster. I’d much, MUCH rather have a slow forum that everyone can use than one that gradually loses users just to provide a faster, shinier experience for the survivors.
But not everyone would agree with that. That pace that would be way too slow for both the devs (I presume) and other Discourse communities… it totally depends on their user and device demographics. A forum for old folks won’t ever chase the same features as an AI forum, for example.
But they shouldn’t NEED to fight each other like that. These aren’t mutually exclusive goals. Graceful degradation has been a basic principle since the earliest days of the web, and Discourse is already headless enough (with various APIs, and also proven by third-party implementations like Discorkie) that it should be possible to provide a “simple HTML” mode with basic reading + posting. It doesn’t need fancy themes, it doesn’t need infinite pagination, it doesn’t even necessarily need editing and notifications and all the other nice-to-have features. It just has to be a basic usable experience that lets people still use the forum for its intended function, reading and posting. It can offer nothing more than a 90s Usenet-style UX and it’d still be better than cutting people off completely. With a little more dev time, it could offer a vBulletin style PHP era UI and that’d still be a huge improvement over the “Sorry, you can’t post anymore” situation (that we’ll still see in July).
IMHO Discourse is (or should be) about community above all. It isn’t a tech demo (anymore), and while my personal preference is that it be thought of as “stable, boring software” that rarely if ever changes… I understand that’s not what the developers, and other Discourse communities, may want. That’s fine. It’s not a bank mainframe 
But conversely, it also doesn’t need to chase constant browser improvements (which will never end). In between the two extremes, a basic HTML mode would let users keep posting long after their browsers are obsolete, while also allowing faster feature development on the main branch because users will have something to fall back to.
As a bonus, it might actually let you actually target the kind of time-window based development you want to do (e.g. “we will support browsers up to 2 years old, or at the 95% caniuse mark”) rather than cherry-picking individual features across every possible permutation of hardware + OS + browser + fork. Anything older than that target can still post via the basic HTML mode, but will not be able to use the latest themes, _____, ______, _____ etc. (which is totally fine because they probably don’t care about all that anyway). It frees you having to cross-check every feature against every browser… if a user can’t use some fancy feature, well, it really would be up to them to upgrade to a new browser. But at least they wouldn’t get kicked out from their communities.
I’m not sure about this (cause i don’t know the script source), but i’ve seen for years places that, doing a simple test at the loading on the browser, uses automatically one version or another, depending if the browser can support it or not, and usually in transparent mode (users don’t even see that process).
I’m sure that, having Discourse already a working version (the one you’re using right now) that don’t exclude old browsers, is easy enough to put a single test at the start of the script loading, and conditioning the part that is loaded to pass or fail of the test, like, “test passed, load the one with all the new features, test failed, load the old version” … lots of other sites already does this from years, why it have to be impossible for Discourse ?
Fun exercise I just did:
Windows XP IE 6 gives a TLS error
Same Windows XP using a browser that still supports it (Supermium)
Same Windows XP, now using r3dfox
Thanks for the update and the delay—it’s appreciated. But I have a follow-up question about the rationale behind this decision.
You mentioned giving communities and users more time to prepare for the change. That implies the main blocker for the 1% is time to update their browser or OS. What data are you using to support that assumption?
Because if the majority of that 1% can’t update due to hardware or OS limitations—not just procrastination—then delaying the cutoff by a few months doesn’t actually help them. It just kicks the can down the road without addressing the core issue.
So unless you have strong data showing that more time will significantly reduce the number of affected users, this change will still cut out a significant group of people who won’t be able to come back.
Would appreciate a clear answer on what your data actually shows about that 1%.
