Hacker News new | ask | show | jobs
by dang 695 days ago
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

10 comments

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.
Custom CSS also means users can fix the designed-for-480p font sizes and paragraph widths, which the HN crew seem to have no interest in doing.
It won't fix the multiple "critical" accessibility issues[1] though, some of which require HTML changes for screen reader users.

[1] https://www.accessibilitychecker.org/audit/?website=https%3A...

Oh I agree. I'm sure if I was significantly blind I would never have joined this community.
<https://pastebin.com/gLXiqKyd> (from my HN profile).

That's more or less what I'm using as I write this.

https://jessicaotis.com/academia/never-use-white-text-on-a-b...

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.

We get a lot of requests for UI modifications beyond dark mode.
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)

- 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.

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.

"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...>

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.

1: https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...

2: https://www.notcheckmark.com

Isn't this just what userscripts/greasemonkey (and its forks) already does for any website?
You can manipulate CSS/DOM with Javascript though.
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.

> extra fields

That leads to settings hell and I don't want that complexity curve.

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
> does there exist a well-defined secure subset of CSS such that we don't have to worry about weird vulnerabilities?

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?

The intention is to avoid adding user settings, while still giving people a way to make the UI how they like it.
Just let people host their own CSS file, and link it the user's prefs?
Guess not :D