Dark colorblind theme changes

[legobeat]

Select Topic Area

Product Feedback

Body

I am a user of the Dark colorblind theme.

Today, under "Notifications" as well as under Issues and PR views, the color for all open PRs and open issues has changed from blue to red. This is quite disruptive and IME an accessibility issue.

Is there any way to do one of the following?

• Allow changing back the color as a user preference
• Revert this change globally
• Introduce a "Dark colorblind variety 2" or similar with the new colorscheme

[designerfuzzi]

Not only that, It changed the entire Github experience without any active interaction. In other words we can safely assume that unchecked/untested changes are rolled out to all users.
Looks like...

and users can not reach the submenus to turn those changes off or to even properly give feedback.. I can't even reach my own profile settings..

[lukasoppermann]

Hey, we are investigating the change of the color from blue to orange.

@designerfuzzi Is it still like this for you? I assume you did all the typical things e.g. clear cache, try in private mode, etc?

Are you also using Dark Protanopia & Deuteranopia? Could you let me know what system / browser combination you are using?

[legobeat]

@lukasoppermann Any update on the color changes?

Separately but seemingly coinciding with this is that more elements are now gray-on-gray than before with not very high contrast.

[lukasoppermann]

Hey @legobeat do you have examples of the gray-on-gray elements? Maybe you can share some screenshots so we can take a look?

[designerfuzzi]

I am on Safari in your town by the way. And it is still like this.

When i investigate, i find that the backgrounds are never set in css but solely reliant on "--css" rules. Which means this issue is impossible to be just in my browser to appear but must affect many more users on a couple of systems.
It starts already here..

and goes on like ..

The last screenshot tells us that css is spread over multiple sources and some are "still" working, most new not. See the different folder colours? The missing backgrounds?

And dark modes, all of them are even worse. Cause black + dark == black. Notice the open User-Drop-Down

And here the bad boy.. (despite there are multiple) Inspector screenshot.

here the color_mode cookie "%7B%22color_mode%22%3A%22light%22%2C%22light_theme%22%3A%7B%22name%22%3A%22light%22%2C%22color_mode%22%3A%22light%22%7D%2C%22dark_theme%22%3A%7B%22name%22%3A%22dark_dimmed%22%2C%22color_mode%22%3A%22dark%22%7D%7D"

[dipree]

Thanks for providing this. Do you mind letting us know which macOS and Safari version you are using? Do you have any extensions installed and could you please turn them off to see if that changes anything?

[Zaitonn]

@dipree
I have the same situation as him with Safari or Edge 111.0.1661.62 without any extensions on iOS 14.4

🤔

What's worse, most pop-ups, including the search bar and the menu after i click my avatar, fail to display

Switch dashboard context popup displays with rendering errors

i have tried clear caches and use InPrivate mode but it doesn't work

it has been like this since 3.22 or a bit earlier😭😭😭which makes me feel so difficult to use github

sincerely hoping it would be solved soon😢

[designerfuzzi]

I am 100% sure the version will not help but here it is macOS10.15 Safari
It was still working just round about 3 months ago (the missing background issue came up), and since yesterday the "colorblind" theme took everything over.

those huge impacts of a change are likely impossible to stem from a browser version..
see 5 days ago it looked like...

now it looks like..

here proof extensions are turned off, browser reloaded..

Here .AppHeader 3 days ago..

and now..

We can see that var() statements are not valid. Meaning the inspector shows no = symbol in front of those css rules. The properties got lost, are not set or ended up in another hierarchy unresponsible.
I can even see a potential typo.. "var(--AppHeader-bg)" vs "var(--appheader-bg)" and a paradigm problem by "--color-border-default" vs "--borderColor-default".

Just for the sake of proof. There is a more serious css rule naming issue because i can fix all of the entire css with a simple injection via dev-extension that simply overrides all those fancy rules with local one on :root and takes care of name doublets. Which results in such visual where the backgrounds are fixed but the menu drop downs are not fixed.

breaks it down to at least those messed up rules either missing or wrongly assumed to exist.

:root {
--bgColor-inset: #f6f8fa;
--fgColor-default: #1f2328;
--borderWidth-thin: 1px;
--borderWidth-thin-modernoterror: max(1px, 0.062rem);
--borderColor-default: #d0d7de;
--borderColor-accent-muted: rgba(84,174,255,0.4);
}
.Overlay {
    z-index: 1000; //fixes the menu trash
}

In other words, i can even turn it on or off.

You can hire me. Lol! Not lol.. who knows..

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[designerfuzzi]

as 'un-' expected, it became much much worse.

Multiple scss maps can't be loaded, they respond with 404 which means likely some module export of the framework in the backend is profoundly broken.

private #variable names in some classes are still being abused as function names without check if those javascript variables exist after creation.

in css most former --cssVariables in CamelCase are implemented as fallback via var(--oldName, var(--color-new-name));, which tells us the design team doest work with one set of names but with two. In other words a dependency issue is deeply embedded in the github codebase which persists and the fallback is not the solution but a workaround the issue. It also fails to really fallback on something reliable.

the <body> tag now misses entirely font-family, margin, padding as css is not fully loaded anymore. Therefor the gitbhub web page appears in times new roman as browser default rather then in example -apple-system.

apart from that as most "modern" webpages github decided to support only and only most modern browsers.. which is expressed in example by the use of javascript .at(-1) to reach a last array entry. Which breaks all, really all formerly compatible browsers for the sake of one, really one single use case in the entire code base, a polyfill for it is not provided.. that is sad and for sure wastes actually only planet resources.

Yes we can use chrome, where it works. Yes we can blame apple where some safari versions do not enjoy updates anymore.. But why would someone store really old mac resources in github repositories when it is impossible to access them via a older browser (not that extreme old). Sure we can use git as commandline tool. Well but if i'd develop my very own verson of a working github forum, what do i do here at all?

If i can fix css manually, so can you at github. Its no that hard, costs less even, the bugs are literally just a hand full.. i count 4 general issues, that to be fixed would never even break the most modern browser, nor slow something down.

Github provides multiple colour schemes, even colour blind scheme, so i'd rather expect it should really also provide a basic version as fallback, in example one that used to perfectly work 3 years ago.

[designerfuzzi]

ok did some more investigation.. by overriding js files locally to test behaviour.

The use of #privatepropertyname is indeed abused by making use of those where private properties are not allowed by js standard. Despite a lot modern browsers handle such namescheme as utf16 or utf8 character prefixed property name and therefor do not throw an error.. which means they are in fact not private, just a different namescheme which breaks the whole code for older browsers for cosmetic reasons of 'modern js'. If you replace all those # with _ voilá it works..

that means the polyfill already abused the naming scheme and breaks so can't polyfill anything.. in example can't polyfill .at(-1) functionality.

if i explicit get rid of the two code snippets using .at(-1) and correct them to old school array access syntax this.obj[this.obj.length-1] even that works.. and again voilá most of github then works as expected..

so you have TWO main errors that could fix all.

• use of #prop can be replaced by _prop without causing any problem.
• use of .at(-1) can be replaced by [length-1] without any problem as well.

[designerfuzzi]

https://github.githubassets.com/assets/vendors-node_modules_github_arianotify-polyfill_ariaNotify-polyfill_js-node_modules_github_mi-.js

...
get #e(){return"all"===this.interrupt||"pending"===this.interrupt}constructor({element:e,message:t,priority:o="none",interrupt:n="none"}){this.element=e,this.message=t,this.priority=o,this.interrupt=n}matches(e){return this.element===e.element&&this.priority===e.priority&&this.interrupt===e.interrupt}#t(){return this.element.isConnected&&!this.element.closest("[inert]")&&
...

that is polyfill abusing private propertyname scheme.. MUST be corrected cause how to polyfill a feature when polyfill already throws a breaking error and stops the script execution!
This code would work perfectly without the fancy #