Background:
I built a solution to provide darkmode/lightmode and other themings (e.g. themings for different companies in an organization) for an application. To achieve this, I’m using CSS variables that are remapped to Sass variables and then can be used in the custom-variables.scss and for any widget/mixin/helper scss-file. This all takes place in a UI Resources module. The file that has the CSS variables is linked in the theme/web/main.scss with an @use. In mendix Studio Pro I gave the UI resources module the highest priority.
The problem:
The mendix build-algorithm first looks into Atlas_Core and then overrides its styles with additional styling from the UI resources module. So far so good.
But in case we are using CSS variables to be able to dynamically replace the values (e.g. hex codes) of their mapped ancestors (Sass variables), depending on a certain body-class, we run into a crash. That happens because in Atlas_Core there are the function lighten(), darken() and mix() in use. These functions cannot handle CSS variables. After reviewing the problem with other colleagues, we came to the conclusion, that there is currently no clean solution to this. The algorithm will always first look into Atlas_Core, run its styling and then will crash – although our UI resources module is considered to have the highest priority.
Current solution:
Currently, all imports of files that use the lighten(), darken() and mix() functions have to be commented-out/removed from the mains.scss of the Atlas_Core module. The affected files need to be copied to the UI resources module and the functions have to be replaced by color variables that represent actual values (hex codes).
Affected files known:
Idea/Solution:
Get rid of all lighten(), darken() and mix() functions in Atlas UI or replace them with color variables that are present in custom-variables.
Value:
Atlas_Core does not have to be touched. This leads to better maintainability and less effort. For the customer it can prevent a lot of internal support calls of developers that import the UI resources module in an existing project and then run into errors + cannot run the app.
Criticality:
This is of high priority because a lot of big customers are asking for theming and want to switch between light-/darkmode or only want to maintain one starter app that contains the same design system but is scalable in the way that as many color schemes as desired can be added.
Contact:
If you have ideas or feedback about the inquiry, please feel free to contact me. peer.guba@mendix.com or via Slack
Are there some possibilties now to solve this issue?
lighten(), darken() and mix() arnt too bad as long as they are ONLY used in the variables sheet.
alle the variables could use with a good revamp as there are a lot of things missing, or that don't make sense.
especially any variable that communicates that it is lighter or darker (brand-primary-lighter) doesn't scale when changing themes to dark mode, (opt for contrast ratios instead primary-100 vs primary-900)
this vid explains how maui9 solves this
https://www.youtube.com/watch?v=j-ZMOdHiEjU
The datepicker is also affected by this i.e. core/widgets/date-picker.scss
Yes please! Dark mode from the get-go will be a HUGE plus!
@peer, the Atlas team is (at least used to be) very open to pull requests from GitHub.
I believe that lighten/darken should not be used outside of the custom-variables file.
If you see any outside of it create a pull request and replace with brand-primary-darken or lighten or what ever makes sense.
I would very much like mx to adopt the “contrast method” where brand-primary-900 has more contrast then brand-primary-100, this will allow for easy switch between light and darkmode, because brand-primary-light doesn't make sense in darkmode or viseversa
if you run into any issues let me know :D
Maui9 already supports css variables, realtime styling, whitelabeling.
https://www.youtube.com/watch?v=VfDWCfLn128
That would be great! We have issues to use our custom theming module with the current situation.That would be great! We have issues to use our custom theming module with the current situation.
That would be great! We have issues to use our custom theming module with the current situation.
Yes please!
Multi tenant / White labeling is actually a must