[deadmik3]

Nice to see but it's too contrast-y for me compared to the stylus theme I've already been using which honestly looks better https://github.com/StylishThemes/GitHub-Dark

[da_big_ghey]

I believe the CEO stated an intention to add more themes for, say, colorblind people, so there might be additional options coming.

Edit: Found the link. https://twitter.com/natfriedman/status/1330924323952091137

[bluefox]

GitHub have the gall talking about accessibility while flinging their octotentacles, dragging users screaming down to the firey pits of JavaScript hell.

[viraptor]

What are the actual issues? JS does not necessarily mean lack of accessibility on its own.

[j-james]

I would suppose the above user is referring, rather snidely, to GitHub not loading commit information without JavaScript. GitHub's JavaScript use is really quite minimal, and certainly nothing like GitLab.

[FrozenVoid]

Github uses web-components which are not supported by old browsers. All dynamic menus don't work without polyfill extension(which takes 100% CPU due some bug after awhile), basic functionality like creating/modifying files works right now but there is no guarantee github wouldn't break it.

[Cthulhu_]

I don't understand that to be honest, commit information is fairly static, and we've been building semi-dynamic pages server-side for decades now. At their size they could probably - and probably do - have an in-memory cache for commits + basic information for super fast access.

[userbinator]

The fact that it used to work perfectly fine without JS is proof enough that it don't need it. But I guess the average web deviloper is more concerned with stuffing one's resume with the latest fads than real accessibility and efficiency.

[pkage]

There's a lot of hostility on HN towards web developers. "Real accessibility" doesn't really have much to do with Javascript or not, it has everything to do with ensuring the site is screen reader accessible, ensuring the site is available for low-vision users, and ensuring that the site is available at slow bandwidths. Given that the site caters to those already (good kb navigation, stated future support for color-blindness, and the site is ~300kb/page) I think that they're in pretty good shape.

Ultimately, choosing not to run JS is your decision—but a vanishingly small percentage of users choose to do that, and as a company your focus is on providing features for the product, and not supporting every single user and their unique configurations. Should Github explicitly support terminal-based browsers like Lynx as well?

Plus, you can avoid 99% of the github website just by using git from the command line (or your favorite client) and using their CLI tool for repo creation/etc.

[viraptor]

Please take a step back for a moment and imagine that you're one of the blind users of HN running into this comment. Reading that GitHub devs who took the time to actually support some assistive technology on their website (not sure how well, but see the existing aria attributes in the source) and track their support (https://government.github.com/accessibility/) don't care about "real accessibility" by not catering to what technology choices you prefer.

[fooey]

The idea that the web should work without JS has been dead for a couple decades now.

It's a barely less laughable demand than expecting everyone to use a CLI over a GUI.

[p1necone]

You seem to be using a different definition of accessibility than the commonly accepted one. What disability precludes the use of javascript?

[sellyme]

"real accessibility" predominantly involves making it possible for people with disabilities to use a website, it's not about accommodating people who put a blindfold on and complain that it's difficult to see.

[bluefox]

https://news.ycombinator.com/item?id=25076987

[viraptor]

Accessibility doesn't really mean catering to people who choose to disable JS in their browser. There's whole set of standards for providing accessibility with dynamic web https://www.w3.org/WAI/standards-guidelines/aria/

[bluefox]

Says you.

[userbinator]

"Standards" written by the same groups who want to control every aspect of your online life by shoving JS down everyone's throat?

Of course they'll redefine "accessibility" to further their goals...

[mr_custard]

Agree - This GitHub theme is unfortunately too dark. Which is a shame, because I was genuinely excited to read that GH has released a dark mode.

I use many dark mode themes and have even created them. The important thing to constantly keep in mind whilst authoring a dark them is: resist the urge to go "too dark" and contrasty, and to keep checking against a known "good" reference.

If any GitHub execs are reading this, and would like to see an example of what we're talking about here, then the JetBrains "Darkula" theme in IntelliJ is a well done dark theme.

[Alex3917]

Yup. For me the Sublime default theme is perfect, whereas I find this new GitHub redesign to be basically unreadable.

[prathiks]

for me its not contrasty enough. I agree dark != pure black. but its not contrasty enough.

[SkyPuncher]

Yea, I just tried it too. WOW that is hard on my eyes.

It feels move like "invert colors" than a dark theme. Toning the white down would be a huge improvement.

[mssundaram]

Same! I use Dark Reader and I much prefer it's take on Github than this - way too much contrast. "Dark" doesn't need to mean BLACK. A nice example is overreacted.io - a navy/blue dark theme.

[prathiks]

I completely agree. the current one is tough to read

[GordonS]

I've been using a Firefox plugin that let's you style sites with alternative CSS for years to achieve something similar on GitHub (I forget the name, but it is pretty popular) - every now and then something on the site looks a bit weird until the styles are updated to keep in sync with GitHub tho.

I personally think GitHub have got this just right, I love it! (I'm red/green colour blind tho, and do tend towards preferring a bit more contrast).

[rurp]

I use the Dark Reader plugin on Firefox and it is incredible. It works perfectly on almost all sites, which is quite an accomplishment given how many site-specific dark modes are either poorly done or non-existent.

[bnt]

This feels more inline with Windows Dark Mode (since Github is a Microsoft company).

[abdusco]

In case anyone's interested, it's possible to schedule light and dark themes on Windows via this app:

https://github.com/adrianmteo/Luna

I usually prefer the dark theme but some websites detect that Windows is in dark mode (using `prefers-color-scheme: dark` in CSS) and fail to provide a way to toggle the dark theme off. This makes it difficult to read the text during daytime.

Scheduling dark theme on & off and combining it with Dark Reader's automation, it's nice being able to have all websites switch to dark mode at night.

[desmap]

I found https://github.com/Armin2208/Windows-Auto-Night-Mode to be better for auto-scheduling.

[Zarel]

How do you combine it with Dark Reader's automation? I don't see any automation option in Dark Reader. :(

[abdusco]

Dark Reader settings > Dev Tools > Switch to new Design

then

Dark Reader settings > automation > use system color theme

[ksec]

Well since the Settings has both System Default and Dark Mode, I wish System Default would be matching closer to macOS Dark Mode which is Dark Greyish colour when user is on macOS.

[SquareWheel]

System Default likely just infers dark mode preference via prefers-color-scheme. It doesn't seem to be a unique theme.

[WhoCaresLies]

I agree, on top of that you can change the syntax coloring with the stylus theme

They had years to build a dark theme, and they managed to under deliver..

They should have just forked the stylus theme..

[suyash]

yes, I would like few different options for dark theme

[HeavyStorm]

For amoled users the real black background is a blessing. On my phone it looks great.

But I use gh on my desktop, a not my phone. A LCD friendly mode is a must.

[prathiks]

I actually think they have less contrast. I am having trouble reading the text