[#42209] - [5.0] Allow OS color scheme override
- Closed
- 24 Oct 2023
- Medium
- Build: 5.0-dev
- # 42209
- Diff
- dgrammatiko:5.0-dev-tristate
User tests: Successful: Unsuccessful:
Pull Request for Issue #42134 .
Summary of Changes
- introduce a selector for dark/light or OS controlled colour scheme
- Reflect the state to the HTML element with a
data-forced-themeand adata-theme="light|dark"
TODO:
Create a new _root.scss so that the theme follows the states of the above HTML element states. (ie like: https://github.com/dgrammatiko/muta/blob/b675f730671e3dcf43e2c1331c6f7d80fcc6cb2c/media_source/templates/administrator/muta/scss/_root.scss#L1-L3)
Testing Instructions
Check that in the Atum template the HTML element reflects the state of the User settings
Actual result BEFORE applying this Pull Request
Atum Template is always set to the OS Color Scheme
Expected result AFTER applying this Pull Request
Atum Template can override the OS Color Scheme
Link to documentations
Please select:
-
Documentation link for docs.joomla.org:
-
No documentation changes for docs.joomla.org needed
-
Pull Request link for manual.joomla.org:
-
No documentation changes for manual.joomla.org needed
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration com_users Language & Strings Templates (admin) |
| Labels |
Added:
Language Change
PR-5.0-dev
|
||
Why 2 binary switches? Why not one ternary option?
Not a particular reason, I can change the code to that. A minor thing is that BS supports more than dark/light themes so limiting the options and also making the addition of new themes harder might not be the best option (future wise).
Let’s see if more opinions drop in regarding what’s better from a user point of view.
Other question: Shall we close the issue as we have a PR, or shall we leave it open until the ToDo is done?
Shall we close the issue as we have a PR, or shall we leave it open until the ToDo is done?
Meh, keep it open so people have a place to express their legitimate concerns ?
The description of this PR should be adapted to the change to one tristate (list) parameter.
We're going to need two different compilations of the css file to support this and bundle that (plus admin template overrides in potentially two places and code to support that if you're setting bonus CSS vars - which presumably would be part of this - but missing). I really don't see the need. More people have moaned about this because they don't like the design which should be fixed in the other PR than because they actually want a dark mode browser with a bright site. I think we should focus efforts on making the styling of dark mode better than the all black thing I did (obviously I'm not the worlds best designer) than adding extra options and overhead.
We're going to need two different compilations of the css file to support this and bundle that.
Nope, check the link in the description, there is only one cas file!
why don't we go the bootstrap why?
Adding the switch functionality to Joomla.themeSelector javascript class similar what's used by bootstrap saving the manual switch in the browser local storage and allow to use Javascript Options be loaded from the use personal settings?
btw. I wouldn't separated front and backend, we already have to many switchs.
why don't we go the bootstrap way?
The bootstrap way:
Joomla5:
The difference is that the state is saved in the DB which (for the logged in users) doesn't need writing in the users HD (local storage as cookies are data written in the disk). The JS switch could save the state to either: local storage, session storage, indexDB, cookie which only session storage is on the RAM (so the other require permission).
In short saving the state in the DB is one of the possible solutions but not the only one (ie: in Muta I'm using cookies).
btw. I wouldn't separated front and backend, we already have to many switchs.
Can do
I like the switch, but I think we should not create our own wheel again and just using what we already have in Joomla. Also only one attribute is needed but we have to change this parameter to e.g. "data" (or something else and fix the broken and wrongly added definitions).
You can test this by adding data-bs-theme="dark|light" attribute to the html tag in joomla backend. So please don't add another dark/light mode layer on top of the existing one.
we should not create our own wheel
It's just a DB value for a given key, people/devs could use it or not. Ie if I want to roll out something that is not requiring permissions (due to EU law about asking before writing to users HD) then such a value is the only way (also it doesn't require JS, not tightly coupled to Bootstrap, etc).
Anyways I'm closing as it's not worthy our time
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2023-10-24 16:22:36 |
| Closed_By | ⇒ | dgrammatiko |
More people have moaned about this because they don't like the design which should be fixed in the other PR than because they actually want a dark mode browser with a bright site.
This is your personal thinking. Facts are different.
Actually it’s based off the direct feedback that we had in mattermost from a dozen people during the betas and RCs. What’s your facts based on?
Actually it’s based off the direct feedback that we had in mattermost from a dozen people during the betas and RCs. What’s your facts based on?
Some billions of people ?
#42134 (comment)
Only a small bunch of people. It's not good ignoring what large public in the world are using.
Why 2 binary switches? Why not one ternary option?