GitHub Releases Dark Mode
github.com
github.com
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.
then
Dark Reader settings > automation > use system color theme
Edit: Found the link. https://twitter.com/natfriedman/status/1330924323952091137
Specifically: disabling JS - your choice; having a disability - not your choice.
Assuming you have a new enough device. My 300€ android from 2017 is essentially unusable as it can't run JS well enough any longer.
Your 2017 Android isn't unusable because it can't run AJAX and $(dropdown).toggle() fast enough. Maybe it's not as fast as your laptop.
With JS enabled, I sometimes see simple mousewheel scrolling slow down or become choppy, or spiking CPU usage for a second or two. Simple scrolling of content that is already rendered and is not moving. And often, the same site with JS disabled scrolls smoothly (or completely fails to load, it's a crapshoot, really).
Of course they'll redefine "accessibility" to further their goals...
Nowadays when you mention the issue on the web, instead of trying to understand and imagine low-powered devices, limited browsers, restricted environments, or maybe just security-concious people who are effectively disabled by this "Web 2.0" bullshit, people claim that you're using the term "accessibility" wrong.
[0] https://www.w3.org/TR/WCAG10/ [1] https://www.w3.org/TR/WCAG22/
> Ensure that pages are accessible even when newer technologies are not supported or are turned off.
Makes perfect sense to put JS in there in 1999, but it can hardly be considered a "newer technology" now.
Is it "frontend programmers" feeling hurt? Or business types who think it hurts their telemetry channels? Do their salaries depend on it? Or perhaps it's just people who just need to disapprove of someone else's preferences?
It's a simple request. Yes, more than 99% of your users use JavaScript, are not blind or deaf, have reasonably fast links, powerful machines, large enough screens, don't mind updating their browser every week (very important! security matters _so much_ when you regularly run arbitrary code), etc.
So I'm in the 1%... why do so many people feel such a strong need to tell me this issue of mine is a non-issue for everybody else?
Unless you're under the impression that websites are only requiring JavaScript out of spite, it seems like it would be a pretty big deal.
> why do so many people feel such a strong need to tell me this issue of mine is a non-issue for everybody else?
Because it's self-imposed, your justification involved calling JavaScript a "newer technology", and people tend not to react well to the belief that "I don't want to run JavaScript" is comparable to disability.
You picked up on "newer technology" as if it's pertinent to the matter. It is not. This usability checkpoint is still 100% valid today. I gave reference to that document to show that the matter is related to accessibility, and to provide evidential support to userbinator's view that the term has been hijacked by the web giants and munged up to exclude whatever is inconvenient to them.
You, like others in this thread, bring "disability" and "self-imposition" to this discussion. I dare you to imagine a world where not everybody who wishes to make basic use of GitHub is able, even if willing, to run JavaScript in every conceivable context. Can you imagine such a world? In this totally imaginary world this inaccessibility is not self-imposed. Given such a world, would you be willing to accept that my simple request is reasonable?
One company has clearly invested a lot into the "JS only" propaganda and strongly attempts to silence the opposition. Turning all sites into ridiculously overcomplex "web apps" that only work in their very latest browser is their dream. It's obvious that a simple text-only or even text+images browser is not all that complex, so from that perspective, basic HTML and browsers that can handle it is a threat --- and cutting those off by making sites not work in them is the ultimate underhanded tactic. They can cheer all they want about "moving the web forward" --- and unfortunately a lot of the "young and impressionable" gets caught up in that propaganda --- but what they are really doing is helping this company further its control over the Internet.
This company is, of course, Google.
I think it's as simple as the fact that your simple request isn't important to them, but you demand it as though you are owed a javascript-free web experience. "I am not doing that because I don't want to" is a perfectly good answer to your demands. It really doesn't matter how easy it would be for them to provide it. They're also probably not providing RSS, though you may want them to, and that would be easy too. Sorry your pet thing is not prioritized.
Personally, I think a small amount of client-side scripting can vastly improve a user experience, and way too much client-side scripting can vastly deter from it. It's a balance that each site must strike. And the effort they must go through to test and support all functionality while also supporting completely disabling javascript is definitely nonzero. Some sites won't find that effort worth it. That's the breaks. I can tell you that I never, ever intend to put any effort into supporting a no-javascript user experience on anything I build in the future. I could almost see rendering an alternate page that says "you no-JS kooks aren't gonna be happy here" but even that is more effort than I care to expend on a militant userbase that's likely to also take exception to some silly shit like my html not being semantic enough.
I think you've somewhat misunderstood the purpose of a public forum.
> Try to improve yourself.
Trying all the time, thanks for the reminder.
Making a website more accessible is beneficial to everyone, not only those with disabilities.
Pretending that people understand the term to mean a different thing, and then screeching at them for not doing that how you want them to is intellectually dishonest and just makes you look like an asshole.
https://en.wiktionary.org/wiki/accessibility
The quality of being accessible, or of admitting approach; receptiveness
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.
I have yet to see an example where rewriting the DOM would end up being lighter on devices with lower-end CPUs and RAM than doing a full page refresh. Browsers already cache static assets, generally a page refresh only takes a second or two (on reasonable connections)
Web has been able to display well-formatted text and images for decades without Javascript just fine. In fact, that has been its original primary purpose, to display text with hyperlinks and some images. Why bastardize it just because you want your images to load with a cool effect or something equally silly (that won't work well for half of the visitors anyway) ?
Why shouldn't there be, when they're the ones breaking things that used to work perfectly fine, and then reimplementing them half-bakedly while consuming an order of magnitude more resources than before?
Should Github explicitly support terminal-based browsers like Lynx as well?
Why does it have to be "explicitly support"? Whatever happened to using the simplest technology possible for the task? That way you'll end up with a page that will work to the best possible extent for any given user-agent. That is ture accessibility.
I'm not asking for them to go out of their way to try to show images in Lynx or whatever. I'm asking for a sane approach to making sites that does not require running arbitrary code on the client just to show some static text that should've come along directly in the page, something that literally all browsers would be able to, but is being needlessly restricted.
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.
That is true, but beside the point.
I agree with you more on the "breaking things that used to work perfectly fine." To me this has nothing to do with "accessibility." If I recall correctly, a couple years ago the header was white, then they changed it to grey.
While I feel like giving users more theme options and more control over their UI is the right direction to go in and one that adds value, I can't help but think that this is just the design team keeping themselves busy/valid.
I followed their design team on social media for a brief period until I realized that all they do is hold senseless confs with the same people over and over again to discuss the same things over and over again. None of them have real code in their repos, just markdown and HTML and stylesheets. None of them contribute to 3rd party projects. Then they iterate something nobody was complaining about. I just feel like these are resources that would be better spent elsewhere.
And it still works perfectly fine. You've purposefully modified your browser to not respect web standards. Any error is your responsibility, not theirs.
You're conflating different types of web developers here.
There's only hostility towards the sub-set of web developers that focus only on what is expedient while sacrificing user-friendliness. The ones that hop on the latest and greatest buzzword technologies in order to pad their resumes.
It's a barely less laughable demand than expecting everyone to use a CLI over a GUI.
There is a new trend to expect all clients to run js, yes, but that is a bad assumption.
Not only does the modern web expect you to be running JS, you're expected to be running a browser that's at most 1 version off the most recently released version. Supporting only evergreen browsers might just be the best thing that's happened in web development.
Graceful degradation was a thing for a very brief period in the lifetime of the web, and hardly anyone actually had the resources or inclination to even pretend to attempt it.
Old web was information and a theme could be written locally and applied to everything.
New web is almost as trashy as the App Store.
edit: my imagination is vivid, and it doesn't end at React and the iPhone. We can do so much better. Semantic information markup without ads and presentation details. Shared p2p, unsiloed. Completely free.
The only part that doesn't, which saddens me, is that there is no way to do U2F auth without js.
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).
It feels move like "invert colors" than a dark theme. Toning the white down would be a huge improvement.
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.
They had years to build a dark theme, and they managed to under deliver..
They should have just forked the stylus theme..
But I use gh on my desktop, a not my phone. A LCD friendly mode is a must.
[0]: https://github.blog/2020-12-08-new-from-universe-2020-dark-m...
Two clicks from the HN homepage and it's done. Informed and improved in one go!
PS. I've been using this one for years and it looks much "softer" on the eyes: https://poychang.github.io/github-dark-theme/
Hope it's still work in progress
Other examples include their insistence on pixel-thin icons which are barely legible when reduced [1], flat buttons that are just colored boxes devoid of even basic button affordances, hard edges everywhere, and nearly 100% saturated colors that are an assault on the eyes.
They've never been very good at UI, but where they are these days is just bad. Their new Fluent design language [2] on mobile looks like an improvement from Metro, they're actually seeing what others are doing and copying it decently enough, but its not really out there much in their products.
[1] example here https://medium.com/microsoft-design/evolving-the-microsoft-f...
PS. In fact, it's more likely it was the Github's old design team, not MS.
It is about what feels better on the eyes
Dark theme, and at night you want to reduce eyestrain by reducing the blue light
This dark theme is full of blueish tone, wich goes against the need of dark theme
We can discuss the blue light aspect in its own merit.
On the other hand, the dark theme could be kinda cool.
As a disabled POC, I personally don’t mind in either case, but also if at least one person feels more welcomed because of the change then it’s worth it in my book.
It feels like picking a light skin tone will be essentially sending a message that seems borderline crass and verging on culturally tone-deaf in the current circumstances. So I pick a Simpsons-yellow, because that's what I'm used to, what I prefer, and what draws the least attention to my skin colour.
How do you give other people options!
Overall, I feel that it's better to use only the neutral variant in reactions.
I also reverted back to light themes for my text editors - I felt it was easier to focus on dark-on-light text than the other way around.
I find the whole dark mode fashion pretty unfathomable. I use it only in the dark and it's wonderful in that case, but people seem to want it on all the time for all the things.
When I'm on my balcony in the sun, I use a light theme. But that's only a few hours a day during the summer. Most of the time I'm indoors with the lights low and my themes dark.
I get it in dark rooms, but I get the sense there is this trend where people like dark mode because they like dark mode and they don't care what time of day it is. Seems more like fashion than anything practical, though I can certainly understand there is a practical application to it, and giving users control of it is good.
As for 'at work', it's been my experience that offices generally aren't very bright. Not even remotely as bright as daylight, nor even as bright as electric lighting could be. Those overhead florescent bulbs produce a harsh shade of light.. but not all that much of it. That's why people squint or put on sunglasses when they walk out of office buildings during the day.
Everything matches, even notepad.
At night, if I find the glaring brightness hurts my eyes even at the minimum level my LCD will allow, I just invert the screen colors - and everything still matches!
That's a bullshit argument when you're talking about technology thousands of years old made with material constraints. How would parchment be rendered black, smear it with soot, which would then rub off on everything it touched? Would you instead ink the entire page? Would something other than parchment be used, and if so what? And what white pigments would have lent themselves to writing? With dark ink you have numerous options, some of them cheaper than dirt. For white pigments you're looking at chalk or lead oxides, neither of which is nearly as available as a little charcoal.
I'm not disputing that for non-emissive text, dark on light is better. But our culture adopting this scheme had a lot more to do with materials that were available in the past than anything else. The alternative wasn't evaluated because it was simply less practical to implement.
As long as designers understand and support both light and dark, it's good to have the option.
For me, any time I pop open HN or Google Drive, my eyes have to take a second to adjust to the glaring brightness compared to everything else on the screen.
There's no absolute reason why the evolution happened that way that I can say. It was all more or less arbitrary design decisions.
Computing with “light mode” preceded video terminals!
Image: http://www.computinghistory.org.uk/userdata/images/large/21/...
I don't know how common this was, or if it's something that was unique to these sparcstations.
https://getpolarized.io/2019/11/19/Dark-Mode-Should-Be-The-D...
The idea being, if you were FORCED to pick one, would you rather have light or dark mode.
90% preferred dark mode with nearly 1000 votes.
That blew me away honestly.
Before that I thought that dark mode was a 'nice to have' but clearly I was wrong.
The other issue isn't just dark mode but 'true black' mode for mobile devices and OLED. True black just looks better on mobile devices.
Most dark mode skins can usually be converted to true black but you have to make sure the fonts don't become too strong.
My mother on the other hand is younger and still has an adventurous willingness to try new things, and last I saw was using the dark mode in Windows 10.
Polling someone who likes light themes because they know no better is an answer to a completely different question.
Also, while trendy, "bias" isn't a word you should throw around unless you also have established the question being asked and what the bias is. Informed answers to the poll aren't biased, especially compared to someone who doesn't know what a dark mode is.
While I hate that move, I am genuinely interested into the answer ;-)
I wouldn't be able to stare at big white areas for the whole day. White is painful for my eyes.
I got too used to them, and have tried putting dark themes on them but it just looks "wrong" now.
Humans are weird.
(Sorry if this sounds confrontational; just trying to understand the appeal of dark mode from someone who never got into it. IME dark themes are often too contrasty on bright monitors and not contrasty enough on dark ones, and I find a dim light theme works best for me in dim lighting.)
A dark theme has the simple solution of turning off the "lightbulb" of a white background. Now the only light is produced by they actual content, so the contrast can remain high.
Though, I also am annoyed that I can't turn down the brightness on my macbook/iphone even more (e.g. in a pitch black room). That is one thing that has indeed forced me to use a dark theme when I wouldn't necessarily have thought of it.
I also experienced recently where lubuntu was missing several intervals between middle and off that were in default Ubuntu.
So now pretty much everything is light theme, and it's like I'm living in 2004 again.
Just gotta keep the lights on in the room when working, which is what I should have always done anyway.
I still love the dark themes on my phone and tablet. I use those more often in poorly-lit areas, so that makes more sense, I guess.
Also, I don't want to use Github when authorized to do things on company repos when browsing something completely unrelated in my own time and own devices. Thus this option is not available to me without creating a dummy account. I also have to change this manually whenever environment changes. With the accompanying blinding flash of light on unfortunate late night sessions.
I'll admit there might be other considerations than funnelling users to registering and using their accounts. It's just not a good user experience and misunderstanding of the target audience.
Edit: spoke too soon. It's not available in their enterprise edition yet. Re enables Dark Reader for corporate url.
Nothing please, that's exactly how I want my sites to look.
That said, on an operating system level (both mobile and desktop) you will have apps that use the same color schemes because they're dictated by the OS, e.g. https://developer.apple.com/design/human-interface-guideline...
Custom css properties are used to personalize colors, which would also work with shadowDom.
background-color: var(--color-menu-bg-active);
These custom properties are declared in light.scss and applied to the body, using the selector [data-color-mode="light"].
This method is fairly standard and widely used in modern websites. The only downside is that IE11 doesn't support custom properties and, in my expierience, there is no polyfill or postcss plugin that is 100% reliable.
See https://www.mediawiki.org/wiki/Help:Extension:GlobalCssJs
https://news.ycombinator.com/item?id=23197966
Many really good themes you can install with Stylish or whatever extension works with your browser.
I often use all of Safari, FireFox, Chrome, and maybe one or two mobile browsers in a day, and the dissonance from having different styles on the same site in different browsers is worse than having to suffer through not having dark mode for me.
It offers dark mode and many useful quality-of-life UI tweaks.
Also, the text in the extension is nigh unreadable. I have to highlight it all to get enough contrast to make it visible. This is on Firefox, anyone else have this issue?
The Firefox version needs a lot of work in the popup's CSS to make it visible. FF made some internal changes and ever since then it has stopped displaying text properly.
I'll get onto it soon.
1. Most people just want a website to work. (I know I do) 2. Because how are you gonna do support on a website when the website looks different for everyone involved? Are you only going to offer support for the basic text version? In that case, aren't you still kind off deciding how it looks, only now it looks ugly? 3. Branding. You want people to instantly recognize your product/brand. 4. To push features you want to be used, for better (handy new ones) or worse (advertising, generating bullshit metrics).
Probably a lot more than, but these just popped in my mind.
You can do both. Offer CSS, but keep the site usable without it. The same goes for every feature: JS, images (fallback to alt-text), etc. Non-HTML resources should usually be optional enhancements.
Over time, browsers have ceded more and more control over layout and colors to web developers, and got busy burying/deprecating the browser-side defaults... to the point where user preference is an afterthought now, and almost universally ignored by sites. Now you have to use big hammers like disabling CSS and JavaScript in order to have any say as a user. Nobody likes when your native desktop application's UI ignores your system default colors and forces their own color scheme, yet this is acceptable on the web.
Yes, I want to set a style, once, and have it used by every site on the internet that I access.
The idea of the user agent dictating presentation rather than the content author is kind of dead on today's modern web; while it's certainly possible to set a global stylesheet, doing so creates an incredibly frustrating game of trial-and-error as some websites break while others work fine.
The idea does live on outside the mainstream in ideas like Gemini, Gopher, and a small subset of the Web that focuses on textual content with very conservative progressive enhancement.
I wrote about this previously: https://seirdy.one/2020/11/23/website-best-practices.html
Most websites should be able to work just fine with nothing but HTML. That doesn not mean that they should actually be just HTML (my website certainly isn't); it means that enhancements like CSS and JS should be progressive. Exceptions exist, obviously.
I interpreted this as OP being tired of having to rewrite the awful CSS of most websites.
The "modern web" and associated software is designed to take control away from users, so that authors can slowly give back an illusion of it.
I've always been writing my own CSS for sites whose style but not content irritated me. Mostly when they change to some idiotic fad, so I can put it back.
This is obviously for a specific type of user who is very very much the minority. Any idea that this would work for a broad audience should be thrown away, because your friend Steve in sales doesn’t give a shit about writing their own CSS.
I think what you have left after that is serving two different versions of your content. One has its own styling and the other does not. Don’t pretend that the markup isn’t tied to the CSS, and that the unstyled version just doesn’t apply CSS, because there will always be coupling between the two for any moderately complex site. Just have two deliverables and be done with it.
Of course, duplicating the content is suboptimal. You could have a source of truth for the actual content of the site that is used to build deliverables with, employing a clever build process.
I mean, I’ll just stop there because this sounds like way too much work, being put on the content creator to satisfy an insanely small number of their users. If you want to style the content on your own, just do it. Delete all style sheets and inline styles and apply your own. It’ll be hard work, and the markup will be all wrong for that type of work, but it can be done if it’s really really necessary.
Dark mode sounds easy (just make the background black!), but I'm pretty sure there are more science to that, because many dark mode apps I've tried make me uncomfortable and I reverted to normal mode because it's _easier_ for my eyes.
The pattern you’ll see is that accent colors tend to need to be brighter on black backgrounds.
If you’re targeting iOS and your design team doesn’t exist or hasn’t specified a theme, consider using the built-in adaptive colors basically everywhere.
https://developer.apple.com/design/human-interface-guideline...
Material guidelines also cover dark mode, but it seems the hex codes are harder to copy/paste as they seem to all be embedded in images: https://www.material.io/design/color/dark-theme.html
It's odd that they have a skin colour settings for cartoon hands. Why not just stick to yellow and keep race out of it? Having that settings is essentially saying that race matters which I find offensive. I don't care what colour your skin is.
You can check your gamma settings, but that's a bit of an ask if you have everything setup just right. Green line numbers are pretty indicative either way
- light mode is often the default, so you don't have to work around it
- more readable: in the daytime, in text editors, for people with astigmatism
- using screen inverters like https://github.com/mlaily/NegativeScreen/ switches your whole screen to "night mode" - including the pesky details like taskbars, menu, etc, and offering you more fine control (ex: only keep the red channel)
Yes, even my terminal is in light mode (Solarized light) - at night, I just press on a key which immediately invert my screen colors and only preserve the red channels. No tweaking with a zillion apps to get them "dark".
In the day time, I press on the key again and keep going with all the applications now "light".
@-moz-document domain("github.com") {
.dashboard .js-all-activity-header + div {
background-color: inherit !important;
border: 1px solid var(--color-border-secondary) !important;
}
.dashboard-rollup-items .body {
border-top: 1px solid var(--color-border-secondary) !important;
}
}
- IntelliJ (similar notebook style setup as Datagrip for SQL queries)
- Sequel Ace - a fork of Sequel Pro
It's appalling how such major apps and websites literally took YEARS to implement Dark Mode after OSes added support for it, while plenty of minor devs had their shit ready to ship during the betas of iOS and macOS.
If their elite teams can't manage something as simple as an additional color theme, what confidence do they hope to inspire in their product? (then again most popular apps are actually crappy in other areas too; WhatsApp, Instagram, Snapchat etc.)
Making it a single button that enables a different theme that a professional designer somewhere has signed off on is a much better user experience for almost everybody when compared to the "write your own CSS" option. Even if you automate it with a browser extension, you're still giving that extension read+write access to the site, hopefully it's trustworthy!
I have no interest in designing my own as I have a terrible eye for design and am equally terrible at visualizing changes, making the process take forever. If I can click a button and make dark theme work, that's fantastic.