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
These are absolutely basic things, and fixing them should not require individual users to fiddle with CSS – even on a website called "Hacker" News.
[1] https://www.accessibilitychecker.org/audit/?website=https%3A...
That's more or less what I'm using as I write this.
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.
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)
- Embuttoning action links ("reply", "more"). (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.
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.
"security issues with user-supplied CSS?"
<https://stackoverflow.com/questions/23502302/security-issues...>
"How dangerous is it to use CSS styles from an untrusted source?"
<https://security.stackexchange.com/questions/24163/how-dange...>
1: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...
https://addons.mozilla.org/en-US/firefox/addon/stylish/
https://chromewebstore.google.com/detail/stylish-custom-them...
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.
That leads to settings hell and I don't want that complexity curve.
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.
I don’t know the answer, but if it is “no,” would it be feasible to add a few more user settings ala topcolor to achieve a more basic version of this?