It's a different style (CSS). Color is obviously different, different people prefer type of different theme. That's why it's host on userstyles.org. Should i call it GitHub Night instead?
GitLab used to have themes that made it dark but we found that this was hard to maintain. New features would look bad in themes that were less popular. Right now you can only change the color and syntax highlighting theme in GitLab: http://i.imgur.com/6v3b0g7.png
You're welcome, screenshots are awesome and I love the dropbox function that puts them in a special folder for quick retrieval. Since SS are also my initials (Sid Sijbrandij) I was confused for a second about your comment until I understood you meant ScreenShot.
Color theme is more than adequate. For business applications there's very little reason to change the design style, but strong reasons to be able to change the colors.
I've been using a different GitHub Dark[0] for quite some time now. One of the best things about it is that it's very well maintained as keeping up with GitHub's own changes in markup and CSS makes things a bit of a moving target.
Deluminate[0] for Chrome does a pretty good job of this. For some sites I find it does better than whatever themes happen to be available on userstyles.org. In other cases, it performs pretty poorly but it's still far better than having to hack together something myself for sites I care about.
Interesting. I haven't experienced any noticeable performance issues at all. My biggest annoyance with it is that it sometimes make horizontal scrollbars appear when they wouldn't otherwise.
I've also been using this "different GitHub Dark";
I'm not sure which one i prefer - the grey background instead of black is also pleasant for the eye... i'll have to try them both for a while.
Same, Github has way too much white on the page and it absolutely kills my eyes. I've been using this for a few months and there's no way I am going back.
I love this. Any website where I am expected to spend any decent amount of time needs to have a dark mode. Very surprised so few websites support this.
I understand that and I'm definitely not expecting it from every website but if you have a website that basically depends on me spending a lot of time reading or doing something on that web page then you should try to not make it a horrible experience for me.
I stopped using these types of tools a while ago because I always disliked the bright flash that was created when the page was initially loading but before the plugin was executed. I would always try to take a long blink when I clicked a link lol.
Has this problem been solved shy from using lynx/emacs/ect?
I had a nice dark background and light foreground colour going for a few months but had to end up disabling it. Sadly, a ton of websites assume that text is dark and background is light, and don't specify one or the other in their CSS, so their sites look terrible unless one turns off site stylesheets entirely (in which case their sites look really terrible, but in a completely different way).
I really, really hate what the web has become. Twenty years ago I could set my foreground and background colours and everything Just Worked™. Now … forget about it!
Not sure how healthy the prevalence of dark themes is. Darkness leads to dilated pupils which leads to a shallow depth of field which leads to constantly adjusting focus – think SLR with a wide aperture.
Not sure about the effects, possibly none. Not sure if I want to be part of the experiment.
Isn't that more of an effect of ambient darkness? Focusing on something dark doesn't affect one's pupils, as far as I know.
Regardless, I've been using a dark GitHub theme¹ and a dark Firefox theme², as well as a variety of other dark themes (e.g. Emacs tao-theme, dark terminal themes, dark Thunderbird) with no ill effects (so far)—on the other hand, my vision is not the best anyway.
It is strange that we are all still living an apple marketing decision. Back in the days of green-on-black CRTs, apple decided to make their screens look like the paper it emulated. (A more extreme part of this was the tilting CRT screens to also mimic the aspect ration of paper). The human eye sees light. So reading illuminated text on a dark background is generally easier. But Apple did it first, MS followed, and white backgrounds seem here to stay.
It took some googling because I didn't know the terminology, but this is what I am talking about: A "Pivot" screen for the Mac by Radius.
Another example of this is street signs. The oldest sign standards (speed limits, street names) are black text on white backgrounds. But the newer ones (highway information signs) are normally white on a dark green background, which is much easier to read at night.
And protects your eyesight too. I couldn't live without the 'Negative' Compiz plugin which I use as a workaround for the many applications that don't have a "Night mode".
And is easier on people with limited vision. And is better for mobile devices at night as it maintains night vision. And saves on electricity (a tiny tiny bit). There is no downside, which is why I laugh at why we still expect everything to be white.
This is an unfortunately common misconception. Sometimes yes, sometimes not. It is highly dependent on condition, in particular with what part of the field is obscured/impaired. I lack around 90% of my FOV - no central vision - resulting in ~20/200 acuity and while I find black on white to be incredibly discomforting I also don't get on with many 'high contrast' dark schemes. At the same time many of my friends with similar acuity but different conditions would be driven screaming from the room by some of my color scheme choices.
The contrast/color sweet spot varies (anecdotally, at least) greatly across both conditions and individuals.
That's why called it a marketing decision. Apple didn't invent the tablet computer either, but they were the ones to push the idea and spend millions on marketing it to the public. They didn't legally invent it, but they did "own" it.
> The human eye sees light. So reading illuminated text on a dark background is generally easier.
The scientific literature on readability does not back this up. Results show large individual variability with a small overall preference for dark-on-light.
Well, that isn't actually "white" on black. Assuming you have an LCD screen illuminated by leds, or florescent tubes, you are seeing some amalgamation of colours that, together, you recognize as white. This isn't blackbody colour.
Furthermore, white-on-black isn't really the best. It's just the inverse of what we see on most sites/devices. Try green, or red on black. It has a very different effect as it is better tuned to the biology of the human eye, which is why it works better in low-light conditions such as driving.
the biggest problem with that last link is the spacing and weight of the text - not the color scheme. I had a hard time with both the light and dark versions
My biggest annoyance when it comes to dark themes is with Chrome. Whenever I open a new tab even though my new tab page is black I still get a bright flash of full white for a couple seconds before the new tab page renders.
Only do that if you don't mind that it is completely insecure. The password you sign in is used to encrypt the master key for your account (which means that if you can remember your password, Mozilla can decrypt your synced data). Worse, the login code is JavaScript served from Mozilla's servers, so they can at any time target one a send one's password anywhere they wish.
Then host your own Firefox-Auth-Server and Firefox-Sync-Server. At least Mozilla has open-sourced those repos, and made their browsers capable of connecting to custom servers with a simple configuration change.
But hey, you'd still be running Mozilla's code in and as your browser. As you say, they can "decrypt your synced data" and "at any time target one a send one's password anywhere they wish" even if you self-host the sync and auth servers.
But at least Mozilla has a history of standing for the consumer and protecting user rights. And Firefox is perhaps the only browser that allows hosting your own sync and auth servers without having build your own copies of the browser.
> Then host your own Firefox-Auth-Server and Firefox-Sync-Server.
Only a server which you physically control — if it's in the cloud, it could be tampered with without your knowledge. And you must still use a high-entropy, unmemorable password.
> But hey, you'd still be running Mozilla's code in and as your browser.
There's a difference between trusting code at a point in time and trusting every single response ever. Sneaking a trojan into code which is visible to the world is hard; sneaking a trojan into a single targeted response is easy.
> But at least Mozilla has a history of standing for the consumer and protecting user rights.
Sure, but that doesn't protect you against a single bad employee or against any government which Mozilla is subject to.
> And Firefox is perhaps the only browser that allows hosting your own sync and auth servers without having build your own copies of the browser.
Yes, and I appreciate that. What really hurts is that Firefox used to have great sync security. I ran my own sync server for years, and was very happy with it. But when they revised the protocol they destroyed its security. Firefox Sync is unacceptable for password storage (as is every other sync system of which I'm aware).
> Firefox used to have great sync security. I ran my own sync server for years, and was very happy with it. But when they revised the protocol they destroyed its security. Firefox Sync is unacceptable for password storage
Oh, I'm unknowledgeable about this. Could you expand a bit on why it is insecure or what they did to it to make it insecure etc. Even just links would be enough.
Your synced data is encrypted with a 256-bit key kB. So far, so good. The problem is that kB is encrypted using a function of your Firefox Account password: if someone can guess or intercept your password, then he can decrypt kB and then decrypt any synced data.
So, how hard is it to guess or intercept your password? Well, if you can remember your Firefox Account password, it's almost certainly guessable given enough machines. Human-memorable passwords almost never have high enough entropy to survive sustained attack.
But maybe you store a truly high-entropy password (e.g. i2FH9E0G6PoCZm41C0pIJdLg1uOcGaA0GfhxKUtSQ) elsewhere, and enter it into the Firefox Account sign-in screen. Now no-one can guess your password, and that means that you're secure, right?
Wrong: the Firefox Account sign-in screen (https://accounts.firefox.com/signin) is served from Mozilla's servers, which means that any time you visit it they may choose to serve JavaScript which transmits your password to them (normally they would perform all operations on your password locally).
'But I trust Mozilla to write Firefox!' you might argue. Sure, but it's (theoretically) possible to verify the Firefox source and binaries once; it's (theoretically) possible to verify that the source or binary they serve you is the same as that they serve to the rest of the world. With code delivered online, an attack can be targeted just once, at a single person: if you're not logging each and every login form's source code then you're exposed. A malicious (or compelled) Mozilla employee (or employees) could target a user; moreover, any government Mozilla is subject to could compel it to target a user.
Their old system performed all operations locally, always; it never downloaded and then executed source. It was secure. Their new system is not much better than, 'trust us.'
This was completely unusable for me. I do commit reviews using side-by-side view and the dark theme here didn't have styles for the changed line highlights causing them to appear in original white.
All sites should support a dark low-blue-light theme. Maybe this should be some ergonomic standard. I've been using f.lux since its release, but it's still awkward to have those bright white sites when working at night.
Is there a reason why this isn't an add-on to something like grease monkey? Just simply inject a little script into the page if the URL is GitHub and change the styles there? I don't normally personally do anything web wise but I've heard grease money is good?
I haven't added this to my browser, but how well does it display code too?
When designing an inversion its important to increase contrast to maintain a perceived equivalence in overall dynamic range with the original.
Typography is affected, as well, in that the darker color is dominant over the brighter which results in small negative spaces seeming smaller and large ones larger. A slight increase in tracking and a reduction in word spacing is the typical approach for setting inverted type to maintain both legibility and readability.
81 comments
[ 2.7 ms ] story [ 161 ms ] threadFor late-night, in the dark work I often use the darkroom mode of F.lux instead.
[0] https://github.com/StylishThemes/GitHub-Dark
[0] https://github.com/abstiles/deluminate
Dark Background and Light Text by Mikhail Khvoinitsky https://addons.mozilla.org/en-GB/android/addon/dark-backgrou...
It just works™ about everywhere. It is also available on the desktop version, although I've never tried it myself.
Has this problem been solved shy from using lynx/emacs/ect?
I really, really hate what the web has become. Twenty years ago I could set my foreground and background colours and everything Just Worked™. Now … forget about it!
JS-based styles are still subject to a bit of delay because of script parsing/executing in case you're using those.
[0] https://github.com/alexanderby/darkreader
Not sure about the effects, possibly none. Not sure if I want to be part of the experiment.
Regardless, I've been using a dark GitHub theme¹ and a dark Firefox theme², as well as a variety of other dark themes (e.g. Emacs tao-theme, dark terminal themes, dark Thunderbird) with no ill effects (so far)—on the other hand, my vision is not the best anyway.
--
¹ https://github.com/StylishThemes/GitHub-Dark
² https://addons.mozilla.org/en-US/firefox/addon/ft-deepdark/
It took some googling because I didn't know the terminology, but this is what I am talking about: A "Pivot" screen for the Mac by Radius.
http://lowendmac.com/wp-content/uploads/radius-pivot-display...
Another example of this is street signs. The oldest sign standards (speed limits, street names) are black text on white backgrounds. But the newer ones (highway information signs) are normally white on a dark green background, which is much easier to read at night.
This is an unfortunately common misconception. Sometimes yes, sometimes not. It is highly dependent on condition, in particular with what part of the field is obscured/impaired. I lack around 90% of my FOV - no central vision - resulting in ~20/200 acuity and while I find black on white to be incredibly discomforting I also don't get on with many 'high contrast' dark schemes. At the same time many of my friends with similar acuity but different conditions would be driven screaming from the room by some of my color scheme choices.
The contrast/color sweet spot varies (anecdotally, at least) greatly across both conditions and individuals.
The scientific literature on readability does not back this up. Results show large individual variability with a small overall preference for dark-on-light.
Some old papers cited here: https://www.joedolson.com/2006/08/on-the-readability-of-inve...
EDIT: Also here is a good example of how reading white on black is hard: http://www.ironicsans.com/owmyeyes/
After coming back to HN from that site, I've been seeing text superimposed everywhere.
Furthermore, white-on-black isn't really the best. It's just the inverse of what we see on most sites/devices. Try green, or red on black. It has a very different effect as it is better tuned to the biology of the human eye, which is why it works better in low-light conditions such as driving.
https://bugs.chromium.org/p/chromium/issues/detail?id=21798
https://bugs.chromium.org/p/chromium/issues/detail?id=470669
Only do that if you don't mind that it is completely insecure. The password you sign in is used to encrypt the master key for your account (which means that if you can remember your password, Mozilla can decrypt your synced data). Worse, the login code is JavaScript served from Mozilla's servers, so they can at any time target one a send one's password anywhere they wish.
But hey, you'd still be running Mozilla's code in and as your browser. As you say, they can "decrypt your synced data" and "at any time target one a send one's password anywhere they wish" even if you self-host the sync and auth servers.
But at least Mozilla has a history of standing for the consumer and protecting user rights. And Firefox is perhaps the only browser that allows hosting your own sync and auth servers without having build your own copies of the browser.
Only a server which you physically control — if it's in the cloud, it could be tampered with without your knowledge. And you must still use a high-entropy, unmemorable password.
> But hey, you'd still be running Mozilla's code in and as your browser.
There's a difference between trusting code at a point in time and trusting every single response ever. Sneaking a trojan into code which is visible to the world is hard; sneaking a trojan into a single targeted response is easy.
> But at least Mozilla has a history of standing for the consumer and protecting user rights.
Sure, but that doesn't protect you against a single bad employee or against any government which Mozilla is subject to.
> And Firefox is perhaps the only browser that allows hosting your own sync and auth servers without having build your own copies of the browser.
Yes, and I appreciate that. What really hurts is that Firefox used to have great sync security. I ran my own sync server for years, and was very happy with it. But when they revised the protocol they destroyed its security. Firefox Sync is unacceptable for password storage (as is every other sync system of which I'm aware).
It's a distressing situation.
Oh, I'm unknowledgeable about this. Could you expand a bit on why it is insecure or what they did to it to make it insecure etc. Even just links would be enough.
Sure thing. I'm referring to https://blog.mozilla.org/warner/2014/05/23/the-new-sync-prot... for details of the new protocol.
Your synced data is encrypted with a 256-bit key kB. So far, so good. The problem is that kB is encrypted using a function of your Firefox Account password: if someone can guess or intercept your password, then he can decrypt kB and then decrypt any synced data.
So, how hard is it to guess or intercept your password? Well, if you can remember your Firefox Account password, it's almost certainly guessable given enough machines. Human-memorable passwords almost never have high enough entropy to survive sustained attack.
But maybe you store a truly high-entropy password (e.g. i2FH9E0G6PoCZm41C0pIJdLg1uOcGaA0GfhxKUtSQ) elsewhere, and enter it into the Firefox Account sign-in screen. Now no-one can guess your password, and that means that you're secure, right?
Wrong: the Firefox Account sign-in screen (https://accounts.firefox.com/signin) is served from Mozilla's servers, which means that any time you visit it they may choose to serve JavaScript which transmits your password to them (normally they would perform all operations on your password locally).
'But I trust Mozilla to write Firefox!' you might argue. Sure, but it's (theoretically) possible to verify the Firefox source and binaries once; it's (theoretically) possible to verify that the source or binary they serve you is the same as that they serve to the rest of the world. With code delivered online, an attack can be targeted just once, at a single person: if you're not logging each and every login form's source code then you're exposed. A malicious (or compelled) Mozilla employee (or employees) could target a user; moreover, any government Mozilla is subject to could compel it to target a user.
Their old system performed all operations locally, always; it never downloaded and then executed source. It was secure. Their new system is not much better than, 'trust us.'
This dark theme, however, did work: https://userstyles.org/styles/37035/github-dark
I haven't added this to my browser, but how well does it display code too?
In Stylish, install this theme https://userstyles.org/styles/128271 or this one http://userstyles.org/styles/37035
When designing an inversion its important to increase contrast to maintain a perceived equivalence in overall dynamic range with the original.
Typography is affected, as well, in that the darker color is dominant over the brighter which results in small negative spaces seeming smaller and large ones larger. A slight increase in tracking and a reduction in word spacing is the typical approach for setting inverted type to maintain both legibility and readability.
If you find any bugs/problems, please tell me. I'll release a fix within 24 hours. Appreciate all positive and negative feedback.