Nice to see but it's too contrast-y for me compared to the stylus theme I've already been using which honestly looks better https://github.com/StylishThemes/GitHub-Dark
Edit: Found the link. https://twitter.com/natfriedman/status/1330924323952091137
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) ?
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.
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.
And it still works perfectly fine. You've purposefully modified your browser to not respect web standards. Any error is your responsibility, not theirs.
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.
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.
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
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?
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.
> Try to improve yourself.
Trying all the time, thanks for the reminder.
I think you've somewhat misunderstood the purpose of a public forum.
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 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.
It feels move like "invert colors" than a dark theme. Toning the white down would be a huge improvement.
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).
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
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.