HTML template CSS: add dark mode with --highlight-style-dark

[mb21]

closes #7125

these values take precedence over values set by custom variables

[jgm]

How does this interact with syntax highlighting?

[mb21]

@jgm good point! some of the darker colors of the default syntax highlighting theme are a bit hard to read:

but in my opinion not really harder than the output of --highlight-style=breezeDark...

we could of course lighten up the background-color of div .sourceCode in dark mode...

[mb21]

I see three solutions to this:

1. lighten up .sourceCode background in dark mode (the question is to what? something that's almost white or something that's almost black)
2. inject the CSS supporting dark-mode only if there are no code blocks with syntax highlighting in the document (could be overriden by a variable set by the user)
3. Figure out a way to load a completely different skylighting theme in dark mode

[mb21]

Okay, I've lightened up the background and overwrite the two darkest colors we have in the default pygments theme:

[mb21]

ah, but overwriting those two values would also overwrite them when the user specifies another theme... so reverted that part while keeping the slightly lighter background.

if we're unhappy with this, we could add a highlighting-css-dark variable around here and populate it with, say, styleToCss "breezeDark".

[jgm]

We can't assume anything about the highlighting theme they're using -- it could even be a custom theme.

[mb21]

True. But what about the reverse? Should the theme assume a light background and dark font? e.g. pandoc --print-highlight-style pygments gives:

    "text-color": null,
    "background-color": null,

[mb21]

Anyway, I've added a highlight-style-dark option, which seems like the best solution anyway.

I haven't really evaluated the different dark themes we have, is breezeDark the most neutral one? I mean to set as the default?

[jgm]

I have mixed feelings about this. In general, I'm resistant to proliferating command-line options. If we do add -highlighting-theme-dark, though, it would also need to be supported via defaults files (I didn't see that above but maybe I missed it).

I'm still wondering whether there might be an alternative approach which derives the "dark" highlighting colors from the regular ones (inverting or something -- not sure whether there's a transformation that would give good results). If so, we could just have a function that maps a highlighting theme on to a "dark-mode" version. And then everything would work transparently without the need for a new option, and without the user needing to think of that.

[mb21]

it would also need to be supported via defaults files

ah yes, I assumed this would somehow get auto-generated from the command-line args... but I could add it...

---

Some more screenshots...

Using breezeDark (i.e. what's currently on this branch):

---

Doing a simple invert:

div.sourceCode {
  filter: invert(1);
}
pre.sourceCode {
  /* since pygments theme doesn't set a font color, we need to set it so that we can invert it */
  color: black;
}

---

I'm resistant to proliferating command-line options.

yes, I understand that. And at first I was hesitant as well, but in the end it seems like the "proper" solution? If the user can set the --highlight-theme, there should also be a way to set the theme for dark mode? But I don't feel strongly either way...

[jgm]

I actually don't mind the "inverted" version in your screen shot. Is it objectionable?

(It would be worth seeing what the inverted versions of all the highlight styles look like; I assume this is just the inverted default style.)

[mb21]

Is it objectionable?

I don't know.. the aggressive pink on black background certainly has a different feel to it than the default pygments theme in light mode... but I don't mind :)

But to make the inverting really a full solution, we'd have to change the output of pandoc --print-highlight-style pygments to contain "text-color": "black", instead of the current "text-color": null. Otherwise, the text inherits the CSS from darkmode on the html body (white), which is then invered to black, and you don't see it.

[jgm]

As a color-blind person, I'm probably not the best one to judge such things...

[jgm]

It might not be desirable to set the text-color to black. As things are, text-color for code in the default style will just follow your document's text-color. If you set that to something else, then the black code might look bad.

Is there a way to do this in the CSS itself -- set the text-color in the Div to whatever the document's text-color is?

[jgm]

I wonder if invert(0.7) or something like that might lead to more aesthetically pleasing results?

What I like better about the inverted version is that it does not change the fact that the code block's background color is not different from the document's.

[mb21]

Is there a way to do this in the CSS itself -- set the text-color in the Div to whatever the document's text-color is?

probably... but we'd only want that when the pygments theme is active... (or any theme that doesn't set the color)... so we'd still need a template variable for that, which is a hack as well...

What I like better about the inverted version is that it does not change the fact that the code block's background color is not different from the document's.

yeah, although arguably if we want that, a theme should set background-color: null (like the pygments does, just likes it sets text-color: null)

[jgm]

yeah, although arguably if we want that, a theme should set background-color: null (like the pygments does, just likes it sets text-color: null)

Yes, exactly. I guess what I mean is this: I like the fact that the dark-mode and light-mode versions agree with each other in this respect.

[mb21]

Ah, by not setting background-color on pre, and code at all, I actually got the invert approach working: #7226

[mb21]

Update: that color-inverting approach (in the other PR) works okay with light themes (like the default pygments), but looks quite horrible in dark mode when applying a dark theme e.g. --highlight-style=breezeDark. So it's either

• we set a variable in the writer

  let isLightTheme = not (selectedTheme `elem` ["breezeDark", "espresso", "zenburn"])
  

  and only apply the inverting-CSS when that variable is true, or:

• add the --highlight-style-dark option (set to an appropriate default, so the user doesn't have to worry about it)

[jgm]

I think checking for particular theme names is not the thing to do, since they might be using a custom theme.
To do this right we'd have to inspect the theme itself and determine from the colors used whether it would look better inverted or non-inverted.

The --highlight-style-dark option is now looking simpler.

EDIT: However, one advantage of the automatic (inverting) approach is that it will "just work." With the --highlight-style-dark approach, users who use dark mode will have bad results until they figure out that they need to specify this option. And given that I'd be hesitant to put the dark mode code in the CSS at all...

[mb21]

With the --highlight-style-dark approach, users who use dark mode will have bad results until they figure out that they need to specify this option.

Not sure I understand this part... if the the option is not specified, it would default to a dark theme (breezeDark in this PR), to give good results when the output document is viewed in dark mode.

[jgm]

Could we set isLightTheme automatically by checking backgroundColor on the style? If it's > 0x8000 we count it as a light theme?

[mb21]

Could we set isLightTheme automatically by checking backgroundColor on the style?

To determine whether we should inject the inverting CSS? Yeah, probably... we'd have to read out the style file though (also if it's a user-supplied style file, which I don't think we have in writerHighlightStyle) It seems like a little bit too much magic for my tastes ;-)

[jgm]

All you have to do is backgroundColor <$> writerHighlightStyle opts and it gives you a Maybe Color (where Color = RGB Word8 Word8 Word8.
So we'd just need to write a function isLight :: Color -> Bool.
(I noticed you closed the inverting PR -- that's the one this suggestion relates to, and I think it's still a good option.)

[mb21]

Okay, I've add a commit with that... seems to work. Even if it means that people have to use a custom template to set a different theme for dark mode. But I guess it's and edge case anyway and we'll get feedback one way or another...