GitHub have the gall talking about accessibility while flinging their octotentacles, dragging users screaming down to the firey pits of JavaScript hell.
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.
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.
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.
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.
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.
I really don't understand the glorification of no-js websites on HN. Like, I'd get it if it was Flash or something ('cause that definitely has some real accessibility issues, and required a plugin to be installed), but the web platform is HTML, CSS and JS. Why artificially limit yourself to just two? It seems to have become a matter of pride to say "works without JS", for absolutely no practical reason (it's not like removing JS is some silver bullet for accessibility, no-js sites can and do still absolutely have problems with accessibility)
JS is usually what kills performance on lower end devices. If websites were only html and css, my smartphone from 2015 would still be a functional device. I have yet to have a page crash due to too poorly written html and css.
It depends what you're doing with the JavaScript. This is like saying "C kills performance" because you found one slow C program. JavaScript can actually improve performance in quite a few conditions (even on lower end devices) by preventing full page reloads and such, which adds more overhead in the network, HTML parsing, etc.
If we're talking about saving bandwidth, JS can be useful, although JS bundles are usually heavier than their HTML and CSS counterparts.
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)
A common example is when you have a page with information and you want to load some additional data or details to display (possibly just a single line). Often times, a a simple AJAX request is faster, and it's also often better UX, IMHO. There are loads of examples of this, but people don't tend to notice when it works well and only remember the examples where it doesn't (like, say, the new Reddit UI).
The application I work on initially used to work completely without JS, but I let that go and now you need JS. It made everything faster, more performant (even on my shitty phone), and the code easier to work with. And it's just 770 lines of JS (+ jQuery, because I think it's just more convenient than dealing with the DOM API).
I have nothing against Javascript when it improves the overall result. However, when I come across a site which consists of text articles interspersed with some static images, and the images do not show with JS disabled, or in extreme cases, the entire page remains empty because it needs JS to even display text, that just screams wrong.
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) ?
> There's a lot of hostility on HN towards web developers.
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.
There's a lot of hostility on HN towards web developers.
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.
> they're the ones breaking things that used to work perfectly fine
And it still works perfectly fine. You've purposefully modified your browser to not respect web standards. Any error is your responsibility, not theirs.
To some extent I agree with this sentiment. Not so much the Javascript aspect, although I've always viewed JS with the "less is more" mentality myself. I understand that it's become a critical part of the web, so that's not really where I agree with you.
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.
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.
That's not true. The idea that the web should gracefully degrade and continue to display content in browsers of all types has been live for... the entire existence of the web.
There is a new trend to expect all clients to run js, yes, but that is a bad assumption.
I understand that is an ideal, but "browsers of all types" is utterly unrealistic, and hasn't been the case in the wild since the 90's.
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.
We got conned into this shitty world where HTML shovels ajax and giant JS payloads.
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.
You're arguing semantics. The web development community (and the engineering industry as a whole) uses the term "accessibility" to refer to making things usable by people with disabilities (and has done so for decades).
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.
The quality of being accessible, or of admitting approach; receptiveness
As another link posted elsewhere in here shows, it seems accessibility has turned from striving to make sites more accessible to everyone, to doing the bare minimum legally required by disability laws.
"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.
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/
And every common description of web accessibility. From WAI to Wikipedia to common courses. I'm not saying it's good design or the right direction for GitHub. Just that accessibility is important and disabling-js is not really it.
Specifically: disabling JS - your choice; having a disability - not your choice.
In my case, yes, it is by choice. But do you think everyone has a choice? JavaScript is a power-hungry, memory-hungry, bloated, security nightmare. Requiring JavaScript for basic functionality (that was available not that long ago!) is simply hostile.
Yes most consumer devices run the same 3 browsers all of which run Javascript just fine. I get you don't like it, but that doesn't mean its an accessibility problem.
> Yes most consumer devices run the same 3 browsers all of which run Javascript just fine. I get you don't like it, but that doesn't mean its an accessibility problem.
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.
That doesn't make sense except for a few heavy applications of JS like a resource-intensive web game which is obviously a niche outside of general statements about the internet.
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.
The issue here is that nowadays "heavy applications of JS" are quite common on blogs, news websites and other "definitely not web applications"-type of websites.
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).
No, accessibility is already defined as a legal concept that has been around since before the advent of the Internet, because it also applies to our physical infrastructure.
There's a really big gap between claiming that modern web development goes too far and runs far too much code and is much too bloated and claiming all sites that require javascript are "not accessible." You may as well go into shouty rants about the use of color because you refuse to stop using a monochrome terminal.
It wasn't always like this. Look at WCAG version 1.0 [0] section 6.3. It's very sensible advice. Then through the magic of "Web 2.0" and bigco work on "Accessible Rich Internet Applications" the advice was made to disappear [1].
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.
I wonder what makes people so eager to push back on such a simple request, to make basic functionality available without JavaScript. In GitHub's case, they only recently screwed it up in a major way, so surely it shouldn't be a big deal to add back the functionality?
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?
> I wonder what makes people so eager to push back on such a simple request, to make basic functionality available without JavaScript.
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.
Are you working for GitHub? If not, nobody asked you anything. That you are taking such offense at my simple request that you have to create a "non-JS kook" personality type to satisfy your vindictive feelings is mystifying. Try to improve yourself.
To answer your question, I don't work at GitHub. And I really don't take offense to your simple request, but I do find it interesting how vehemently you are making your "simple request." I also don't think it's unreasonable to turn off JS. What I do think is unreasonable is turning off JS and then getting angry over the fact that few other people care about this scenario.
> In GitHub's case, they only recently screwed it up in a major way, so surely it shouldn't be a big deal to add back the functionality?
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.
I don't know how much programming experience you have, but let me tell you that bringing back an HTML dropdown menu is not a big deal. I don't know about "spite", but I would say it's either an oversight, or incompetence, or some grander goal to force JavaScript on their users for what could be termed "business-related reasons".
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?
You are seeing the true nature of corporate greed and control show its ugly face. The end-game is clear: one browser controlled by one company, of great complexity and continuously changed to discourage others from attempting to compete, shaping websites to that one company's desires. Of course everything will be "standard" and "open", but that hardly matters.
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.
Don't forget the endless stream of security updates, bundled up with whatever new UI/tracking/arbitrariness they want to force upon you. After all, the world wide web is a dangerous place, and your data is at risk. Don't you trust us to keep you safe? As if you had a choice.
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.
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.
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).
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.
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.
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.
I think the settings link is useful too; it allowed me to click on it and immediately flip the setting in question, which was exactly what I wanted. The blog post doesn't really contain anything more than, "We have dark mode now," anyway.
For some reason Microsoft keeps doing dark themes like this. Same in Windows 10. Pitch black against text. Do they even let designers do this job or is it just devs checking in code? A designer should know about these things by heart.
Yeah I truly don't understand who (if anyone) is leading design at Microsoft. There's so many good examples of how to do things right in UI these days and they somehow keep making the wrong choices.
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.
'feel' and 'like' are pretty much in the same boat here, I think. I mean is the person you're responding to really going to claim to like something which doesn't feel good (esp. since it's about themes, and the OLED mention)?
The same thing does not feel best on everyone's eyes. I like black dark themes and they feel better because they are higher-contrast and thus are easier to read. For me (and probably for others), they reduce eye strain.
As a POC I only care about the act of having to pick one. It's a chore. I really don't care if the default is the Simpson-y yellow color. Honestly, this kind of thing is such a non issue.
On the other hand, the dark theme could be kinda cool.
I feel exactly the same. Major bike shedding in my opinion. I prefer the yellow anyway. In a way, It allows others to focus on who I am, not what I am.
This is one of those things where you can’t make everyone happy. Similar to “disabled person” vs. “person with disability”
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.
On the other hand, quite a lot dev time is spent in total on the whole emoji skin tone modifiers. How much dev time is it worth it to make that one person feel more welcome, and wouldn't there be other areas where this time would be better spent to make people feel more welcome?
The engineering efforts required to standardize emoji skin tone modifiers are certainly applicable to other use cases. Do you really think it's a complete waste of time?
To be honest ... I kind of do. It's not that I don't think the goals are a waste of time, those are great, but it always seemed to me that the much simpler approach of a yellow skin tone solved the same problem in a much simpler way. Similarly with the gender modifiers, a gender-neutral depiction always seemed like the better option to me.
I'm not a PoC and suddenly having a mandatory skin tone choice presented to me before I can use my emoji is making me uncomfortable, to say the least.
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.
I also really appreciate the skin tone being a setting rather than having to pick the skin tone every time I select an emoji. This seems like an obvious thing, but some popular apps (cough hangouts cough) still haven't figured it out.
Now reactions will be harder to count: instead of X neutrally yellow emojis there would be a bunch of every skin tone. I'm also kinda worried about accidently displaying statistics like "only people of certain race like this issue".
Overall, I feel that it's better to use only the neutral variant in reactions.
I have about 40degree astigmatism, but also myopia. I blow hot & cold with dark mode. It’s definitely NOT the “one true way” that it seems to be for other devs. It hadn’t occurred to me that my astigmatism might affect perception in dark mode differently. I’ll look out for that. Thanks!
Paper is black on white for a reason... I never understood dark modes and my eyesight is surprisingly good (as in, no glasses needed) after staring at computer screens for a good part of past 20 years. Am I just old?
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.
Dark mode is bad for your eyes in a light environment as it causes them to work harder. Its good in the dark though, hence the name. Its a mode that should be used in the dark.
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.
You say you can't fathom it, but then you seem to subsequently fathom it. Dark themes are nice in dark rooms. If you assume most people spend most of their screen time in well lit environments, then puzzlement might seem warranted. But why assume something which leads to perplexing conclusions? The obvious answer is that people who prefer dark themes also tend to work in dark rooms.
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 mostly see people at work using dark mode during the day time and cheering anytime anything gets dark mode.
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.
Indoors 'during the daytime' is still pretty dark in a great many rooms, often due to the preference of the rooms occupants. So it really has little to do with the time of day. Right now it's early in the afternoon for me; the sun is still up but it's overcast, my window blinds closed, and my lights aren't turned on because there is no reason for them to be on. Dark mode works great in these sort of dim conditions. It's really a matter of comfort, not fashion.
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.
My terminal is solarized light, and I had to battle with Windows to let me use a very light-grey as an accent color (not the off-white I wanted, but good enough)
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!
Interesting. I have astigmatism too, but never had any idea it would have any bearing with something like a colour scheme. I'm not sure I like the new dark theme and now I'm wondering if it's just because it's new or because of astigmatism
Doesn’t have to be white though, I’ve used anoff white for as long as I remember. Say #f8f8f8, or a warmer tone. i think there is a big difference in terms of luminosity by just lowering the rgb a few notches.
It's definitely a personal thing—some people love dark mode (myself included) but some people either don't prefer it or can't stand it.
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.
It's kind of interesting that we started computing with dark mode and when we jumped to windowing systems, for some reason that coincided with move to white on black. Maybe it was more familiar for office workers used to paper.
There's no absolute reason why the evolution happened that way that I can say. It was all more or less arbitrary design decisions.
This old Sparcstation I managed to get for free years ago would display everything in "light mode" by default. If you would boot Linux or NetBSD to the console it would be a white background with black text.
I mean, is HN really an unbiased sample source? Ask my mom or grandma if she prefers dark mode over light mode and she’ll say whatever she has right now on her phone.
Is that because your grandmother doesn't understand the question/choice, or did she evaluate the two options and decide which she prefers?
I think if I asked my grandmother a question like that she'd probably get concerned that I was about to change something she was already accustomed to, without necessarily understanding what change was being proposed, and would default to invoking the 'don't fix it if it ain't broke' principle.
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.
It's not surprising that power users are more acquainted with the options available with a developed preference from trial and error.
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.
Whilst a majority in your case (and that of Discord) may prefer dark, I wonder if it’s more complicated that that. I use light mode everywhere. I like some others have mentioned have astigmatism and I find dark mode only tools much harder to use - to the point that if a code editor only supported dark I would probably not use that editor. I wonder if any that prefer dark have the same issue with light mode only applications, and if so for which is your application usable by a greater number of people, even if it’s not their first preference.
If you tested "option to have a dark mode" vs "that other feature which was already requested 150 times", you might have come to an entirely different conclusion.
If you use the computer in a well lit area, then yes. Dark themes work well for dim lighting. That said, IME a light theme in a well lit area is much easier on the eyes, especially over the course of a work day.
When you switch to a dark theme in dim lighting, is it because you can't turn your screen/monitor brightness down (e.g. on a desktop)?
(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.)
When you turn down the brightness on a light theme, you're also turning down all contrast just because the background is emitting too much light.
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 usually use redshift to decrease the brightness even further than what my laptop allows me, as well as adjust the colour temperature. It's kind of annoying that the lowest brightness is still too high in the dark on almost all laptops, but perhaps there's a technical reason for that.
I've read that, while the science/usability research is largely non-committal about which is better, it seems that black on white or similar makes your pupils dilate much less and therefore is easier for working for longer periods (less eyestrain). Though, as you say, I think you also really do need a well lit area to take advantage; super bright in a dark room isn't very good.
Just recently, I have been ditching all of my dark-theme apps on my desktop. For one, switching back and forth between the light colored windows (most websites, word processor, all my scientific PDFs) and the dark ones (previously, terminal, some websites, etc) is so bothersome. But lately I've been finding dark theme too hard on my eyes as well, just in general.
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.
Owners of repositories that "assumed white background" (for example, https://github.com/jenkinsci/jenkins), consider updating your graphics to something that is readable in both styles.
It appears the default is light mode, rather than system preference. For those of us who use websites logged out most of the time, this is a bit annoying. Hopefully the default is changed to system preference in future.
Yes, this is very unfortunate decision. Same that Stackoverflow chose to do. I am liable to call this dark pattern... There’s no technical reason for this that I can think of. Guess our usage data locked in is that much more profitable.
If that were the case there could be an option to set this on browser basis, using the usual cookies and local storage. Dark mode is not (just) a theme. It's about accessibility. Its benefits vary by time of day and screen in use.
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.
Not to disregard dark theme users, but dark sites always look the same to me. Light color schemes still feel distinct in subtleties like fonts, border colors and other things that scream “you’re looking at github” or “you’re looking at msdn” or “it’s your iphone”. It doesn’t happen with dark mode, it’s just all the same dark bg with some text. Idk what can be done to fix it.
The default Github repo view looks amazingly good. It has changed some during the years but the base design is still there. I think many people choose Github over other web based repo views just because of the design. I don't think the dark mode can live up to it though, it still looks good, but not amazing.
It's interesting to see how they did it and pros/cons of their approach. In general the page look like it's built server-side. Some parts use lit-html but they are just a few and I believe they are not using webcomponents or shadowRoot.
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.
I'm not understanding how to apply the dark mode using this extension. I see that it has it in the "Custom CSS" field, but what then needs to be done to apply the CSS? This is probably really obvious to most of the userbase, but I'm pretty inept when it comes to anything pertaining to web design.
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?
I have that same problem. I think hitting the "dark mode" CSS preset (which pastes the CSS, unreadable of course, into the edit box) and then pressing Enter actually let the style stick. I also had to refresh my HN pages for that particular change to take effect.
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 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.
If you're using any chrome-based browser, you might want to enable the "force dark mode for web content" flag under chrome://flags. Some few websites look weird, but the vast majority becomes pleasantly darker. HN looks good. I cannot live without this option anymore.
Whenever I see something like this I always wonder how we came to allow website authors to dictate how their content is displayed on other people's computers. I know I can use greasemonkey or whatever to hack something together (or stick to lynx), but why don't websites generally just deliver text and leave the decision of how to render it up to me?
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.
> 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?
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.
I came here to post the same observation as OP. Used to be, you’d set default colors in your browser, and those would be used to render all web sites. No need to use a plug-in, override CSS per-site. If you wanted to, you could have the web site render into your own “brick wall” background.
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.
Basically, yes. Not unique css mind you, but a single nicely readable (for me) set of styles for everything. This stoves a bunch of accessibility problems too. Why is this weird?
No, just one global stylesheet that all websites obey without breaking. The (dead) dream of the ideal user agent is a program that lets you browse with your preferred color scheme, fonts, font size, etc; websites look just like any other program. Or not, if you prefer. Content is dictated by the authors but appearance is dictated by the user-agent.
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.
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.
Not sure if the questions are rhetorical, but in case if not, the history of allowing that is reflected in www-talk archives [0], and in articles such as [1]. Basically (and AIUI), some publishers wanted that, users didn't object too much, and it happened -- same as with a bunch of related technologies.
I get where you are coming from in an ideal sense, I’ll entertain the idea instead of for fun.
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.
All browsers used to have the concept of a user stylesheet. That was before corporate greed and control took over.
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.
Anyone know a "Material design spec" for dark mode? I mean I'm no designer and I just want to copy paste some hex codes to make the apps I built support dark mode.
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.
Not material, but Apple has good coverage. I imagine you could copy their hex values, or come up with a very similar scheme.
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.
Completely irrelevant and more of an "off my chest". I got lasik earlier this year from one of the most accomplished surgeons using the latest lasers. Anyway, I have a bit of "haloing" which is more apparent on black screens w/ white text, so now I barely use dark mode. I guess you never know the side affects you'll get with elective stuff.
I have mild afterimage illusion when viewing text or high contrast images.
Interestingly, the symptom is worse when background is dark than the other way around.
So dark mode themes are mostly no go for me mostly unless some transparency is enabled.
Of course, I can not use this github dark mode sadly at this state.
Nice! Looks like an improvement over what Dark Reader gave me.
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.
Related question: why do most websites give you a light/dark/system toggle instead of always going with system? I’m having trouble thinking of any time I’d want the system dark but GitHub light, or vice versa. Is it just for systems lacking support?
I'm not sure if they is why, but even though I use dark mode at the system level, I've found that not every site has a good implementation of dark mode, and for that reason I appreciate the option to revert to light mode.
It's fine on my screen. But yes, my experience with dark mode is that it requires a finer tuning by the user, done right it's superior to light mode, but the threshold of success is tighter
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
I think the mix of font colours is also a problem on the diffs alongside the dark green, which makes it really hard to see what's going on. I've switched back to light mode for reviewing PRs
Sticking to light mode in everything is more optimal:
- 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".
Finally. Really happy with it, except that the explorer/trending and trending page hasn't been updated yet. I hope that will follow to protect my eyes from that brightness contrast at night and in the morning.
I think the only thing that remains blindingly white is now JIRA. Slack, github, and code editors support dark themes. Anyone know of a good mySQL editor that supports dark themes?
Finally. There have been Stylus user styles forever, if GitHub was open source (like Gitea, which has dark mode enabled by default on some instances) they could have been merged in years ago.
Next they should release "HTML mode", where the site is just HTML for people who get headaches trying to use sites that think they're applications instead of documents.
It's a large failure that individual websites and applications have to even bother creating "dark mode" skins, rather than using the user's system color scheme.
Maybe it's just me, but I'd rather all these tech companies that implemented dark mode over the last year or so had worked on new features or bugs instead...
Now if only HackerNews would relent in its zealous vendetta against eyes.
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.)
Why do sites need to "release" dark mode? Everybody can change their user css easily, and put whatever text/background colors they want. The problem is that the css of most sites is an humongous monstrosity and does not cope well with a couple of simple changes (which was precisely the purpose behind the design of CSS!)
Why do sites need to "release" front-ends? Everybody can write javascript clients to send GETs and POSTs to any company's back-end server!
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 love using dark themes, however all of the ones I found online have their own deficits and broke whenever GitHub pushed an update.
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.
