Hello, this is a client-side theme focused on high readability and removing extraneous visual widgets and icons. It is based on the way I liked to read content on that “other site.”
For better or worse, the current kbin layout is very “mobile” in design and not the best for reading longform text on a desktop. This theme focuses on easing the layout and hopefully making threads look more forumlike.
It does take a “scorched earth” approach in removing stuff I don’t like, but everything that starts disabled can be enabled again via the radio buttons provided, allowing you to toggle on/off various widgets on the fly.
This includes:
- sidebar
- footer
- activity
- thumbnails
- previews
- short description
- avatars
- upvotes, downvotes, or both
- icons
- elements of the text submission form
- numerous other elements
In addition, you can change the base color scheme via the color picker in order to globally control things like:
- body color
- link colors
- upvote/downvote colors
- blockquotes, code blocks, input fields
- hover/focus color
- text color
- etc.
Disclaimer: I have tested this at 1440P on a desktop environment at various scaling levels and dimensions and it seems to mostly be OK. I have not extensively checked for glitches on mobile aside from some rudimentary mocking. If you find something wrong, feel free to make a PR or inbox me.
Frontend is not my main focus area, so there may be some anti-patterns or things that are objectively stupid, particularly around the way I manipulated elements on the grid. Again, if something is being implemented wrongly here, please advise.
My opinion on it is that adding non-critical frontend suggestions to a project already in its infancy creates needless noise for the developers working on structural/backend changes. Moreover, such suggestions may clash with the designers’ own vision. Client-side changes are seamless in that they can be continuously modified in a non-invasive manner after the fact if the end-user does not like the designs being made upstream, which (quite likely) may be the case even after the project is stable. So there is good reason for them to coexist. Moreover, insofar as such changes are in JavaScript, they serve as a proof of concept that the upstream developers can deploy into their existing codebase if they later decide they like those third-party fixes.