Add dark mode

[djaiss]

Twitter does it well. Zulip also.

Check:

[pqhf5kd]

I imagine this is a low priority, but if it does get implented, can it use the new prefers-color-scheme query? More details here

[mgrhm]

@pqhf5kd: Yeah, it can be implemented with @media (prefers-color-scheme: dark) in the CSS. It’s actually pretty easy to do it – but I’ve only ever done it on very small static sites with small, simple CSS files. It could very easily be much more complicated to implement in Monica.

[vergissberlin]

@mgrhm I have some experiences with it. The idea is to use custom properties in combination withe the mentioned media query. For colours, this pallet could be an inspiration: https://color.adobe.com/de/Dark-UI-color-theme-7388196/

I am interested to help more.

[mgrhm]

Hi @vergissberlin: I’d be interested in working on this with you. I’ve only ever done it for really small sites (like my own site) which have much simpler CSS than Monica appears to.

I like the palette you’ve suggested, but feel there needs to be a higher contrast pale colour for the body text – #A1B4C4 may be too dark against a #202529 background at the size/weight of text Monica uses. (With all that said, it does get a pass on WebAIM’s contrast checker.)

[vergissberlin]

@mgrhm Great. When we use custom properties, the colours are changeable very easily. So, I don't care too much about it. I just want to get rid of the brightness in my eyes. 😎

Current status

I've seen, that this project uses tachyons and parts of bootstrap. Both frameworks using custom properties already (tachyons, bootstrap) which is great. I never heard of tachyons before, but I've found a repository with modified properties for a dark mode: https://github.com/ocd-sg/ui-tachyons-dark/blob/master/src/index.css

Starting point

After a short look into the code, it seems that Monica currently don't uses custom properties at all. To replace all colour values with custom properties, is a good first starting point.

I started to work on it by creating a fork. What do you think is the best way to work together on it in this case? Separat forks and rebasing from time to time OR work in the same repository (fork) OR sth else?

[mgrhm]

I’ve had a look at the SASS code and there are 80 different colour codes used. Many (most?) of them are very, very close to one another.

I don’t think it’s possible to work on a dark mode without first fixing this. I think the first step needs to be to fork and radically reduce these. I’m confident it could be reduced to a dozen or so. Once we have that smaller colour base merged into master, we’d be to create a second fork to select the dark mode alternatives.

I’ll make the simplify-colours fork tomorrow and start the spade-work of reducing the colour palette to a manageable number of colours.

[mgrhm]

The SASS code has a _variables.sass file, which defines colours but doesn’t use them in the actual styling code. Once I’ve consolidated the colours down to a manageable level, we should use that file to specify them globally.

I think it would make sense if we used the established HTML colour names where possible.

What do you think?

[vergissberlin]

Hi @mgrhm

Naming

Naming is always a thing :) In this case I would disagree to use color names for variables. Just think about in case of dark mode, the variable --colour-white has to get the opposite value #111 (for instance) because you just override the variables in your media query.

Example

 :root {
  --color-bg: white;
  --color-text: #555;
}
@media (prefers-color-scheme: dark) {
   :root {
    --color-bg: black;
    --color-text: #eee;
  }
}

I would prefer variables which are not related to the colour itself. This article describes it well. It also describes the benefits to use color palettes with names like primary, secondary, …

For whatever reasons, bootstrap uses a combination of both concepts. Long story short: I would prefer this way from tachyons.

Performance

In the next step, to keep the code size small for ordinary white people, I would split the variable overrides (aka themes) into separate files as follows:

<link href="dark-mode.css" rel="stylesheet" media="prefers-color-scheme: dark">

Do you agree?

BTW, I like ASCII art in your CSS file 🤣

[djaiss]

Thanks for the help. Feel free to simplify the colors in the CSS used throughout the app.

[mgrhm]

Hi @vergissberlin:

Naming is always a thing :) In this case I would disagree to use color names for variables. Just think about in case of dark mode, the variable --colour-white has to get the opposite value #111 (for instance) because you just override the variables in your media query.

Yeah, naming is a nightmare -- but I don't suggest we'd be naming them ourselves. I'd recommend using the W3C's naming scheme, which would result in code that looks like this:

   html {
           background-color: #1a281f;
           font-size: 1em;
           font-family: "JetBrains Mono", monospace;
           background-color: WhiteSmoke;      # AKA #000000;
           color: Black;                      # AKA #000000
           line-height: 2rem;
   }
   @media (prefers-color-scheme: dark) {
           html {
                   background-color: Black;   # AKA #000000;
                   color: WhiteSmoke;         # AKA #f5f5f5
           }
    }

Much more readable and understandable than #f5f5f5 and #000000, which are actually two of the more easily understandable ones. Using W3C's colour names means we're working to a standard rather than an André and Mike special.

This is pretty efficient since we only change the variable that is actually affected. Dark mode wouldn't touch the layout code, just the code for colours.

I'm keen to avoid adding complexity to this by concocting our own variable names like primary-bg-light and secondary-bg-light because of the additional complexity it introduces by being project-specific. Those variables don't contain any information about the colour itself, which is helpful to those reading it. (And to me; I'm not a programmer so my mind doesn't grok and store variable names very well.)

I'm not wedded to this approach, but think it's worth batting back and forth to get opinions on.

In the next step, to keep the code size small for ordinary white people, I would split the variable overrides (aka themes) into separate files as follows:

<link href="dark-mode.css" rel="stylesheet" media="prefers-color-scheme: dark">

I didn’t realise there was an option of a separate CSS file for dark-mode, but it makes sense given that you can have print stylesheets and such.

If it was up to me, I’d keep them all in ‘in-line’, directly underneath the CSS that they modify. The overhead will be perhaps an increase of 25% file size (likely less), but will make it much easier to maintain and update if changes are made to the CSS later.

If we’re looking to increase performance, I’m sure the CSS file itself could be heavily optimised – most easily by minification before being served, but also by manually taking out what’s not used.

BTW, I like ASCII art in your CSS file 🤣

Thanks! I'm just old enough to remember when ASCII art was common in email signatures!

[mgrhm]

Thanks for the help. Feel free to simplify the colors in the CSS used throughout the app.

I've spent a good part of the day on this, and I’m confident it can be reduced to under 20 colours with no impact on how the site looks or operates. Once we have it to <20 colours, we'll be able to do the dark-mode work. Working on it while it's 81(!) colours is just infeasible.

[vergissberlin]

Hi @mgrhm,

instead, override the whole CSS declaration you can use the custom properties. It reduces the complexity and file size a lot. Here is a full example:

 :root {
  --color-bg: white;
  --color-text: darkgray;
}
@media (prefers-color-scheme: dark) {
   :root {
    --color-bg: black;
    --color-text: whitesmoke;
  }
}

body {
  background:  var(--color-bg);
  color: var(--color-text)
}

Colour values

Of course, if the colours match the w3c colour names, we can use it instead of hex value! Sorry, that was my misunderstanding caused by my English language skills.

CSS status report

Report about the current status of CSS https://cssstats.com/stats?url=https%3A%2F%2Fcrm.andrelademann.de%2F

• 57 unique colours
• 59 Unique Background colours

Do you have a link to your fork for me? I am curious. :)

Kind regards, André

[mgrhm]

Sorry for the slow reply. I’ve had a busy few days and haven’t had a chance to do any more work on this.

Instead, override the whole CSS declaration you can use the custom properties. It reduces the complexity and file size a lot. Here is a full example:

That’s really clever – I’ll steal that for my fork and work that in. I can probably pick out reasonably sensible names for the variables.

Do you have a link to your fork for me? I am curious. :)

It’s available here, but it’s kind of a dead-end at this moment. I’ve thought of a better way of implementing it, and I’m going to do it at the weekend. Keep an eye on it; I hope to have a substantial amount of work done on Sunday.

[mgrhm]

I’ve spent a while working on it this evening, and pushed the changes. I managed to reduce it to 21 colours in total. Most of them are near-neighbour substitutions so aren’t like-for-like, but should be close enough that they’re only noticeable when held side-by-side.

I realised I have absolutely no idea how to get the SASS files to compile into a CSS file I can test on my own instance, and none of the guides I found online were helpful. Any help you can provide would be much appreciated. I’d like to try this out before raising a pull.

[asbiin]

Glad to here that, I'm looking forward to see this. There is some slightly indications here, but basically, just run these commands:

yarn install
yarn run production

Thanks!

[mgrhm]

Okay. I've now spent three hours trying to diagnose and fix issues with yarn run production -- every time I think I've fixed something, a new error occurs.

I'm giving up.

If someone is willing and able to compile the CSS from my branch and send me a copy (you can send it by email), I'll test it on my server. I can then submit the pull with the updated code once I've tested.

Otherwise, someone else will need to take over.

[asbiin]

@mgrhm I've created this PR for your branch: https://github.com/mgrhm/monica/pull/1

[Schlauer-Hax]

How is it looking right now? @mgrhm

[djaiss]

Dark mode is coming in monica v2.

[mgrhm]

I haven’t looked at this much for a good long while, but had started work on it again recently.

Should I stop working on this if it’s already planned, @djaiss? Do you have it in hand?

[DJFriar]

Is this still planned for release soon?

[mgrhm]

I haven’t done any work on this recently – @djaiss’s reply, and the recent announcement of “Chandler”/Monica 2.0, put a freeze on it for me.

@asbiin, @djaiss: Is there any point in finishing off a dark mode for this current version of Monica, or should we treat it as abandoned?

[djaiss]

We should treat it as abandoned. All our efforts are on the new version.

This is what dark mode in the new version looks like. More information on https://github.com/monicahq/chandler

[mgrhm]

Noted – I won’t do any more work on this Monica.

Will we be able to import our database from Monica into Chandler? Or will we lose everything and have to start from scratch?

[djaiss]

Will we be able to import our database from Monica into Chandler? Or will we lose everything and have to start from scratch?

It's planned to you will be able to migrate, but we are not there yet, since the database structure is extremely different than the current one.

[Xyz00777]

i hope its okay to write into these issue, im trying the beta release at the moment on your beta servers and i would recommend to make the word color brigther, because when the display brightness at example at an laptop is not really bright its extremly hard to read the text.

[Rayregula]

oh, chandler was abandoned/archived :(

https://github.com/monicahq/chandler

[andersmmg]

@Rayregula No, it was just moved into the main repo. Read the last issue: https://github.com/monicahq/chandler/issues/558 Chandler is the beta branch on the main repo now, it's useable on https://beta.monicahq.com/