Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dark mode #861

Open
ploeh opened this issue Jan 29, 2023 · 3 comments
Open

Dark mode #861

ploeh opened this issue Jan 29, 2023 · 3 comments

Comments

@ploeh
Copy link
Owner

ploeh commented Jan 29, 2023

A few people have, over the years, requested a dark mode for the blog. I'm quite sympathetic.

To be clear, before I continue, I also think that the current light mode should remain an option. Dark mode should be opt-in for readers.

For the record, I use everything that I can in dark mode. Visual Studio, TeXStudio, Office, Sublime Text, Windows Terminal, Twitter, GitHub, Stack Overflow, etc. It can, indeed, be quite a blast of white if you then transition to a mostly-white web site, such as this blog.

While I'd like a dark mode for the blog for my own use, this is far from trivial. It's hardly difficult to create another theme and enable users to pick that one instead. The trouble is related to the content of the blog. The text can easily be inverted, but apart from text, the site makes use of these types of assets:

  • Illustrations. A few of these are proper pictures (here's an example), but most are figures with arrows, boxes, blobs, and the like (here's an example of that).
  • Code colouring.

Over the years, I've tried to make the figures as background-independent as possible. Most modern figures have transparent backgrounds, and use colours that are neither too light nor too dark. Still, it's not clear whether they'll be readable on a dark background. It's not unlikely that there's still the occasional black text, for example.

Furthermore, older figures were typically created with none of these concerns.

When it comes to code, it's typically coloured with inline styles, e.g.:

<span style="color:blue;">var</span>&nbsp;<span style="font-weight:bold;color:#1f377f;">deleteResp</span>&nbsp;=&nbsp;<span style="color:blue;">new</span>&nbsp;HttpResponseMessage(HttpStatusCode.BadRequest);

(I typically use Copy as HTML for that.)

The reason I do this is that I want the blog to be as decoupled from other services as possible. (This is also the reason I don't use a third-party comment service. TL;DR: This blog has been around since 2009 already, and I intend to keep it around for decades yet. Most third-party services don't last that long.)

In other words, I don't want to rely on a third-party syntax-highlighting service.

I don't have much experience with modern user interface design, but imagine that other people may have faced and addressed at least some of these issues. If anyone wants to help getting dark mode off the ground, please get in touch (just respond here).

@chriskrycho
Copy link
Contributor

Diagrams are just plain hard to deal with – I've done the “generate in both color schemes” thing a couple times for my own site and it’s just a lot of work. Doable, but a lot of work.

Syntax highlighting may be more tractable, though. I would be surprised if Rouge doesn't give you the ability to emit spans with classes instead of inline styles. If it does support that, then you can use a media query to pull in appropriate CSS to get syntax highlighting in an appropriate color scheme.

I do something shaped roughly that way for my own site:

  • the syntax highlighting schemes as CSS files here
  • CSS to pull those in and apply them here, with a tiny SCSS mixin (just to avoid a bunch of manual copy-and-paste) to support it

I use highlightjs to do the syntax highlighting as part of the site build, and it uses the class names approach instead of the inline styles approach natively.

@ploeh
Copy link
Owner Author

ploeh commented Jan 31, 2023

To be clear, I'm not inclined to use CSS for syntax highlighting. Perhaps it's my lack of knowledge about it, so correct me if I'm wrong, but I very explicitly don't want a universal 'solution' to that problem.

As much as possible, I'd like each article to stand on its own. Perhaps I need to emphasise some code in one way in one article, and another way in another article. Can I do that if I have a general syntax highlighting style?

Another concern is that I post code in various different languages on the blog. Currently it's mostly C#, F#, and Haskell, but other languages occasionally make an appearance. Additionally, who knows if I may pick up more languages in the future and start posting about those as well?

I do have preferences, but I also admit that I know woefully little about modern web UI technologies, so perhaps I'm thinking about this in an outdated way.

@ploeh
Copy link
Owner Author

ploeh commented Feb 12, 2023

A thought: One option for rendering code in dark mode would be to simply remove all colour information from it. This could effectively address backwards compatibility of the hundreds of existing articles.

I would as the author, however, like to be able to supply dark mode-coloured code going forward (and selectively backward), so that each code snippet might exist in two copies: A light-mode- and a dark-mode-copy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants