uds-se
Support dark mode
Allow the pages to be read in dark mode. See also
https://web.dev/prefers-color-scheme
I am interested in helping with this. I'm not a front end developer but I know a bit of CSS.
I am having trouble getting make to complete against any target -- missing imports, perhaps because I'm not using Anaconda -- but I did start a branch where I've hoisted all the colors from custom.css into variables so that it's easier to see them all in one place: 120c8424b8fe8535377c8024d8d4ce1b6cf23c5d
From that I've collected each unique color:
-
#000000 -
#00008bdarkblue -
#0000ffblue -
#6495edcornflowerblue -
#3f3f3f -
#808080gray -
#a0a0a0 -
#A93226 -
#B03A2E -
#bb0000 -
#ff0000red -
#F1948A -
#F0F0F0 -
#F8F8F8 -
#fff8dccornsilk -
#ffff50 -
#ffffe0LightYellow -
#FFFFFF - rbga(0, 0, 0.4)
- rgba(0, 0, 0, 0, 5)
Do you have guidance or requirements for a dark mode? Are there any restrictions on the color palette?
I'd suggest starting with reducing the overall number of unique colors. Then as a first pass I'd convert the colors into HSL and invert the lightness and go from there.
Dear lonnen,
I have no particular requirements for dark mode. If you can come up with a nice palette that follows the system mode and send me a pull request for the CSS file, I'll be happy to integrate it.
Looking forward to hear from you,
Andreas
@andreas-zeller - The CSS necessary to implement Dark Mode is scattered across several files and <style> tags. I am looking for implementation advice about what is largely a matter of style:
- Is there a preference for how this patch should treat vendored 3rd party CSS?
- How should I organize the new CSS I must add?
To elaborate: Mastadon embeds have their own light and dark mode CSS rules, so I'm ignoring them for now. Other than that, CSS comes from one external stylesheet called custom.css and 5 style tags in the html template that put CSS inline into the document. 3 of these blocks have rules related to color, and all 3 appear to be vendored 3rd party CSS libraries:
- Twitter bootstrap 3.3.7 and normalize.css 3.0.3
- css for syntax in
.highlightblocks - "Temporary definitions which will become obsolete with Notebook release 5.0"
I'm implementing dark mode by replacing all color declarations with custom properties, sometimes called CSS variables. These properties are defined for the light mode in one place, then immediately a media query checks for prefers-color-scheme: dark and overwrites the properties with the dark mode colors if necessary. Then they are referenced wherever needed using var(--some-property-name). Properties are first class CSS entities so they can be defined in one file (e.g. custom.css) and referenced from another file or the inline <style> blocks.
To implement a useful dark mode, we need to be able to use properties to replace all the colors wherever they are defined, including in vendored code. I see a few options:
- Modify the vendored code to use variables like first party code
- Modify the vendored code to remove color declarations by commenting out the lines and re-declaring them in
custom.cssas needed - Use CSS specificity and load ordering to indirectly override the color variables with variable shadowing
Option (3) really only makes sense for bootstrap/normalize. The other blocks are almost entirely color declarations, making this option a less explicit and more error prone Option (2). For the same reasons (2) would effectively inline the non-bootstrap/normalize blocks by necessitating commenting out nearly the whole block.
If we want to proceed with Option (1), then where variables are declared and where they are referenced becomes a second question. I see a few options:
- Define all CSS properties in one place,
custom.css, and reference them wherever colors are currently declared - Define light and dark mode properties in each CSS block next to the CSS they modify
- Consolidate all the CSS blocks into a single file and manage it with internal structure and organization
Moving declarations closer to each other makes it easier to see and understand a color theme, so I generally favor consolidation, but it also makes for more work when updating the vendored code and keeping the one giant CSS file organized. As the long term maintainer do you have a preference or thoughts about any of these trade-offs? Maybe you see a better option that I'm missing?
Hi @lonnen – I plan to convert the Fuzzing Book to Jupyter Book in the second half of this year, and then dark mode will come as part of the package (plus search, plus several other features). So if it's not urgent, you may as well wait until then...