It would be great to support a second or more color scheme on the OPAC.. many apps now have 'dark mode' and 'high contrast'.
Last mention of such an idea was in bug 20554
I agree this would be really great for accessibility, both for users in the OPAC and in the staff interface. Dark modes don't work for all users so just editing the CSS etc for the OPAC isn't a full solution.
I have been asked about the availability of a dark mode several times in the last few weeks when showing or discussing the new staff interface with different groups of people.
*** Bug 8634 has been marked as a duplicate of this bug. ***
I don't know the best way to do this from the CSS point of view for Koha (especially with the new staff interface), but I have some thoughts from the system point of view. Do we want dark mode to be available to all users or only authenticated users? I think apps like Github only allow you to customize the app's appearance if you're logged in. Then you can go to an "Appearance" option in your account to choose "dark mode". If it's only for authenticated users, we could save that option, and present that through something like the "userenv". In the templates, I imagine that we'd probably set a class or attribute at a high level. (Looking at Github, it seems that the "data-color-mode" attribute on the "html" root element lets them toggle between "dark" and "light". Obviously there's more that goes into it than that, but that's the initial hook.) -- The problem with a "dark" mode is that we already allow so much customization to Koha, so I wonder how many libraries would be able to actually customize and test a "light" and "dark" mode. We'd definitely want system preferences to control this feature. But it would be a great feature to have out of the box.
Hello, all! The color customizations on the Koha instance I support have fallen behind with version changes, and I've been working on simplifying the OPAC's appearance and minimizing the content of OPACUserCSS. This bug attracted my attention. Does anyone know how many colors, in total, are in use on the default OPAC? It's easy enough to determine or scrape the main ones, but there are others lurking out there. In the course of this task, I've been thinking that if the color palette was kept simple (4 or 5 colors), and if the base CSS was relatively simple (more importantly, consistent), then Koha could have a built-in function *like* that offered in ByWater Solution's OPAC theme plugin (which is out-of-date). An admin could perhaps pick from a few-preconfigured color palettes or enter custom colors. It would be *totally* sweet if Koha was compatible with and could tap into the WordPress catalog of themes. Alas!
I've was working some more on our own OPAC customizations, and not being a web developer or design professional, I had cause to look up some aspects of CSS. It was then that I learned about CSS variables. (See https://www.w3schools.com/css/css3_variables.asp.) It occurred to me that CSS variables for colors could make Koha theming really easy. There *is* a list of such variables listed in the ":root" section of opac.css, but it seems that none of them are in use. Instead, colors are specified directly by each rule. If a default color palette was formed for the Koha OPAC, and the CSS contained something like this: :root { --kColor1: #abcdef --kColor2: #fedcba --kColor3: #123456 --kColor4: #654321 ... } AND the CSS rules in opac.css (and others) were edited to *always* refer to colors by way of variables, then a *basic* theme variation would simply need to change those variables. The change could come by way of OPACUserCSS, a custom CSS file, a built-in light/dark mode switcher, or a plugin. Some color variants can be created programmatically – e.g. lighter or darker, shades or tints – so they wouldn't have to exist as separate variables. The color-mix() function is a good example of this. (See https://developer.mozilla.org/en-US/docs/Web/CSS/color_value/color-mix.) As I wrote, I'm not a web pro, so I could be wrong, or there could be a more efficient way. In some ways, I'm just recording my own thoughts on the matter.
Another follow-up to my previous entries. A developer page for Chrome similar to the one I referenced at Mozilla gives support to the notion of dramatically simplifying theming and dark/light preferences by using :root colors, color variables and the color-mix() function: https://developer.chrome.com/docs/css-ui/css-color-mix#building_a_light_and_dark_color_scheme
(In reply to David Liddle from comment #8) > using :root > colors, color variables and the color-mix() function: Those CSS features are baked into Bootstrap 5, an upgrade I'm actively working on these days. Hopefully once the upgrade is in place it won't be too hard to implement a dark theme.
That interesting and encouraging news, Owen. If there's a need and a way to get involved with the refinement of theming, I'm open.
Just looked into it. This is quite a bit of work!
Created attachment 173536 [details] [review] Bug 31327: PoC Dark theme See https://getbootstrap.com/docs/5.3/customize/color-modes/
Remaining work: 1. Move all HTML colour codes to variables 2. Find a dark variant for the different colors 3. Make the theme selector nicer 4. Add other themes (high contrast) Is it as easy as that? Who is interesting to help here?
I'd be ready to help here if the need arises.
Jonathan, this a great start! I clicked through to look for places that are going to need tweaking and/or aren't currently covered by the variables on the staff side. Some places I'm noticing need different colors text/placeholder in top search bar (or background of it) text in new (or background) Text or background of messges Text or background in moremember.pl The form for editing a patron is white with dark boxes and light text, as opposed to still light in the search bar. These should probably match for consistence. Datepicker fields are a different black/grey to other form fields Datatables are still all light with light colored text. The yellow for links doesn't look quite right and in some cases (like circulation.pl) it doesn't contrast enough. "Leave a message" on circulation.pl "limit to the following" on search.pl In general a number of the "panel" areas on search.pl and moremember.pl have a lot of white space still, setting show backgrounds as darker would probably be better. itemsearch.pl dropdowns for selecting things have very low contrast. h3 on the homepages (such as circulation-home.pl) don't have enough contrast. Similarly on both the main pages and the homepages I think the buttons (circ-button etc) should be darker as well. Reading some into UI dark mode and with some examples here https://m2.material.io/design/color/dark-theme.html#ui-application One of the comments on the other bug mentioned solarized as a more readable than some dark mode https://ethanschoonover.com/solarized/ For the theme picker could it be in the dropdown similar to "Set library and cash register"? or possibly an icon that opens a picker? I imagine once this feature is pushed, a likely next step would be the ability to add custom themes that could also be picked from so having a picker rather than a switch would be nice. I'd be interested at least in testing and helping with color selection.
(In reply to Jonathan Druart from comment #13) > Remaining work: > 1. Move all HTML colour codes to variables > 2. Find a dark variant for the different colors > 3. Make the theme selector nicer > 4. Add other themes (high contrast) > > Is it as easy as that? > > Who is interesting to help here? I actually just overhauled a different app using Bootstrap 5 and my own CSS variables recently, so I'm interested in step 1 there.
(In reply to Jonathan Druart from comment #13) > Remaining work: > 1. Move all HTML colour codes to variables > 2. Find a dark variant for the different colors > 3. Make the theme selector nicer > 4. Add other themes (high contrast) > > Is it as easy as that? > > Who is interesting to help here? I can put time into this in whatever way I might be qualified. Determining good Koha color palettes -- a few light, a few dark -- may be the part that needs the most collaboration. Lisette Scheer has some good suggestions. It would be important to keep it as simple as possible.
Datatables can be styled via bootstrap 5: https://datatables.net/examples/styling/bootstrap5.html They also have a dark mode and a snippet for autodetecting dark or light mode: https://datatables.net/manual/styling/dark-mode#Enabling-dark-mode I think probably to handle all the bugs we have discussing themes/dark mode/styling option, we have a couple of steps here. Step 1: Add a dark mode and theme switcher Step 2: Add a configuration page where themes can be set up by users and set as defaults/matching dark and light themes Either as part of that or as step 3: add the ability for some ui elements to be configured per library within the theme? Such as a header color based on logged in library from Bug 37054 Also do we want to do opac and staff interface as separate bugs? If so we have this one for OPAC and 38550 for staff interface.
> Step 1: Add a dark mode and theme switcher > Step 2: Add a configuration page where themes can be set up by users and set as > defaults/matching dark and light themes > Either as part of that or as step i agree, although i think it would be easier to provide different "pre-defined" color-schemes (and the dark mode) for the staff interface, from which the libraries can choose from later, so it doesn't get too complicated for the staff in the libraries
(In reply to Christian Stelzenmüller from comment #19) > i agree, although i think it would be easier to provide different > "pre-defined" color-schemes (and the dark mode) for the staff interface, > from which the libraries can choose from later, so it doesn't get too > complicated for the staff in the libraries We have a lot of partners who want to do more customization and currently use a combo of custom css and js to customize. We've had some similar and related discussion over on Bug 37054. https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37054
I would also be interested in testing and helping with color selection here, and in the related bugs. How could we move forward?