What I'd* like to do is let people upload their own CSS and have HN serve it back to them. Then you can make your own darkmode (or anymode), and people can share them so you can reuse someone else's.
One question this is contingent on: does there exist a well-defined secure subset of CSS such that we don't have to worry about weird vulnerabilities?
* actually I think this was originally kogir's idea
This is a thing on private tracker websites, at least Gazelle based ones. You can give a custom URL to load CSS from. Not sure I've used any other websites that allow you to do this, though I wish there were more that did. I think the odds of people being victimized with this are pretty low and people could just skim the CSS beforehand if they didn't write it.
That's a cool idea, but it's not a substitute for meeting basic accessibility and readability needs. HN violates the WCAG accessibility standards for text contrast (your browser dev tools will happily point out which text is affected), it ignores platform fonts in favor of an outdated font stack that doesn't kern properly on many Linux devices, and it displays line lengths of up to 200 characters, even though research suggests that CPL should not exceed 70.
These are absolutely basic things, and fixing them should not require individual users to fiddle with CSS – even on a website called "Hacker" News.
Custom CSS risks being scope creep, IMO. A dark mode with options of a standard dark and a pure black dark would likely account for 99% of use anyways.
Myself and others with astigmatism literally cannot use "dark mode", tastefully done it's fine tho, talking stuff like Nord theme, monkeytype.com etc as long as it's not straight black and white.
Classifying and prioritising those, and perhaps sharing some of the list, would be a good first approach even if you don't go further.
It'd also be helpful to request rationales for why different modes are requested.
My own major gripes about HN:
- Default font is too small. Screen sizes, resolutions, and dot pitches have evolved dramatically since 2007, in multiple ways. One Size Does Not Fit All. (FIMS -- fixed in my style)
- Default colour scheme is just plain hard to read, all the more so on e-ink (which I use for much of my reading). (FIMS)
- Voting controls are too hard to hit, and easy to confuse. (FIMS)
- For those who want that sort of thing: no dark mode. (Fixed in my other style.)
- Text dialogue too small. (FIMS)
- Various navigation / mode elements hard to distinguish. (FIMS)
- Providing additional colour context to additional screen elements. (Fixed in my personal style, not on the shared style.)
Going back to the default HN style always feels exceptionally jarring.
Outside CSS tweaks, I'd prefer at least a proper quoting/blockquote style. HN doesn't need to go full Markdown (though That Would Be Nice), but this is one key lacking feature.
As others have noted, this is possible on some browsers via extensions. I use Stylus with Firefox and have my own customised HN CSS. Mostly it inverts the main body / border colours, and uses sane font-size specifications, though there are some other tweaks. I've also got a "dark mode" variant. Both are linked from my profile page.
I'd prefer HN adopted my styling, obviously. But a dark-mode toggle would be pretty straightforward.
There are sites which have permitted customising CSS for ages, with Old Reddit being among the m better-known cases. The use-case differs there in that a subreddit's moderator(s) specify the style used by other members, which isn't how you're suggesting HN be modified. People footgunning themselves is lower risk, though it might result in more support.
Another option would be to offer a closed set of vetted styles, or to parameterise some of the CSS values (e.g., font properties, colours, etc.)
There are a few S/E / S/O posts addressing your question, with few deep concerns, though both are 10+ years old.
You can introduce a dark theme for HN without feature flags or CSS upload. Support for `prefers-color-scheme` is widely supported in all the browsers[1]. It's how I handle it on my blog[2], I just swap out the colors based on the css selector.
HN already lets you edit the top bar color, just repeat that with extra fields for the rest of the layout, and maybe add font size to boot. The UI of the user panel would be slightly more complicated but it would be no less safe than what you already have. And if you want to get fancy, you can use the HTML5 color tag.
edit I see you just answered another similar comment, but I'm still going to obstinately argue for it because it's the simplest and safest solution. There's nothing wrong with adding UI elements when you're adding new functionality. And that extra complexity is still less complex than something more superficially "elegant" like an internal CSS parser.
If you want people to be able to use custom styles, that's extra complexity regardless. If you let people upload their own stylesheets, you need storage for potentially millions of extra files, validation, size limits, etc. All of the hazards associated with arbitrary file uploads.
Or extra fields. Then all you're dealing with is a few more color values on the backend for a stylesheet that's already being generated by code. It's a lot easier to validate a color (the code for which is already there) than an entire nearly Turing complete language.
You could even split the difference and have themes generated from one or two user supplied colors, instead of fields for each css value.
Make it a github repo anyone can add their username.style.css to, put them to web, and show to each user when they open username's page (maybe with a userscript through githack URLs)
After you have a hundred, you can infer the subset that is "generally enough "
If the CSS maker userbase is small enough you may just manually check they are fine and pick a small subset to make available for everyone
Whenever this topic came up about a decade ago, the argument against dark mode/theming was that it added complexity to Hacker News which has the explicit goal of being super simple.
Now, with dark mode able to being controlled by CSS media queries and also able to be done automatically according to system preferences, the complexity argument doesn't hold. It's less complex than the later-added comment collapsing behavior and navigation.
If browsers innately and sanely supported default / assignable CSS that ... might be workable. I'd also much prefer browser's default styling was far more sane.
As things stand, some browsers (and, good news, those used by the overwhelming majority of desktop visitors) support CSS-management extensions such as Stylus.
But those don't work for all browsers, and aren't available in particular on Google Chrome/Android.
I've tweaked my own browser's default stylesheet in the past, and currently use a customised Reader View style for Firefox. Both are problematic, and changing the browser's default styling is probably best avoided these days. My Reader Mode view breaks somewhat and sometimes, but when it hits right, it's much better than stock.
The HN theme violates WCAG accessibility standards for text contrast[1] (which you can verify with your browser's dev tools), has paragraphs that are almost twice as wide as recommended for readability[2], uses font sizes that are unreadable for people with even slight impairments of visual acuity, and is near-unusable on small mobile devices.
I'm all for improvements to the theme, which have been overdue for a decade, but adding a dark variant is not the most pressing issue, to put it mildly.
Whats the briefest code change which would achieve these outcomes in a browser neutral manner? I hate to think of a massive .js burden to get there, I like sites that are both visually simple and mechanistically simple behind the text.
Replace the outdated font stack with `system-ui` in CSS, remove all `font-size` directives, remove the gray-ish background, make the light-grey text slightly darker. This fixes many accessibility issues with not a single line of JavaScript required. Mobile usability is more difficult, given that HN relies on tables for layout.
I also can't find a single ARIA attribute in the HTML code. Between that and the absence of semantic elements, I wonder whether screen reader users can navigate HN at all.
I'd suggest a two phase approach. 1) come into conformance with the least possible change to current experience, and 2) make the structural change which might change current user experience but provides for assisted access improvement. I'm not a fan of big-change, and I am of a belief most of the current HN mob are pretty OK that it remains much as it is (not that they are unwilling to countenance change but there's a certain curmudgeonly love of this being an un-lovely site. -And I certainly don't think we deliberately don't want to help people who have to rely on semantic element aware readers)
This isn't the first time these issues have been brought up though. Or even the tenth time. I've seen many small open source projects make accessibility a top priority, actively seeking feedback from visually impaired users, going through multiple prototypes etc. With HN, this just continues to not happen. I could produce a 10-line CSS patch that would solve lots of issues, but at this point I have no reason to believe it would be accepted.
If you offer Dan a 10 line patch which changes nothing in the normal case, but improves things for visually impaired users, I would be surprised if he didn't accept it. I agree there is a low level of visible engagement but I've always found him (and his sidekicks) amenable to reasonable exchanges off this page.
I would probably drop HN altogether if it constrained itself to a tiny 3” column down the middle of my browser like other obnoxious sites do. I paid for a nice 27” monitor and I expect to use the whole width. If I wanted to constrain the content to a narrow column I would resize the browser window. The content width should be left to user preference.
Man, I always forget that ublock can do that. Here I am with a self-rolled firefox extension to do a dark theme on this site when this probably works even better...
I think it's important to understand that supporting dark mode by default makes websites work properly also in situations where you are not logged in, or you aren't using your regular web browser with all its customizations and extensions installed.
Solution: use a browser that respect client-side overrides. You should be doing this anyways, if you want a usable adblock browsing experience. People that use Safari or flip-phone browsers don't reserve the right to complain about the web being unusable.
To quote Thom Yorke, "You do it to yourself, you do; and that's why it really hurts"
In many cases, you can probably get by with your browser's default Reader Mode.
I'll use uBlock Origin's element zapper on a whole heck of a lot of sites, and you can write default rules for common annoyances as well.
If you get fancy, you can write generalised styles which address specific annoyances, and toggle those on or off on specific websites.
Otherwise, I'd found I'd written a thousand or so custom styles over a couple of years at one point. Most were quite elementary (usually font tweaks or removing headers / social link-litter). A few ... somewhat less elementary. Taught myself a lot about CSS in the process.
I don't think they meant that it would be needed to make new overrides for every site typically. Dark Reader extension works fine with 99% of sites out of the box and is free.
You seem to be referring to the ios/mac app store thing specifically, which is NOT what 99% of people use. That is a separate whole browser with the extension pre-installed and completely unnecessary.
Just use the links in the middle of the page and it will install it for free like every other normal browser extension people use all the time.
The firefox extension alone has 1 million installs just from this page, we all installed it for free and have been using it for years. I think asserting that there are only paid options is disingenuous to say the least.
I'm not comparing on those terms. I'm comparing about "being supposed" to do something. We may have the ability, but that doesn't mean that we will do everything we have the ability for.
View the most recent 500 Hacker News articles in chronological order with all their first-order comments in view. Do not click to flip the page, do not click to see the comments.
What I’d like is a prioritization of fixing the long neglected UI and UX. Start with fixing accessibility (vision, motor, etc.) first.
Dark mode can come after that (some may want dark mode all the time, some may want it to obey system settings, some may want a simple toggle on every screen).
It would be really appreciated for you guys to consider adding a dark theme for HackerNews.
The reasons, well, could be added as comments here in the thread. Though, as you may imagine, it's mostly because of my eyes when I visit you guys without daylight.
Have people complaining of eyestrain from "light mode" considered checking their display brightness? Displays should match the brightness of their backgrounds, or in general somewhere around 100–150 cd/m² (aka 100–150 nits). Most monitors are capable of going much brighter than this, and really should not be used that way, because it tends to... cause eyestrain.
Effective luminosity isn't just a function of how much light the device can output at a given setting but also how much light is being blocked or is otherwise not emitted by the image being displayed. By making the background dark and the relatively sparse text light, you can lower overall light output while preserving more of the contrast.
One question this is contingent on: does there exist a well-defined secure subset of CSS such that we don't have to worry about weird vulnerabilities?
* actually I think this was originally kogir's idea