Here’s the link to the doc (just a starting point):
I’ve been going through some of the restyled themes and can’t help but notice how some are disjointed due to bootstrap overrides of theme styles. We really should rethink the load order of bootstrap and theme. It’s just intuitive that bootstrap should be loaded first then theme style sheet, otherwise the theme creator can’t be sure whether their style will have precedence or not. If changing load order upsets look and feel of existing, then we should go ahead and bite the bullet and fix now.
Btw: Light and radiant are my favorites so far (radiant has a problem with the encounter pull down style tho)
Radiant and Lightbwere built specifically for bootstrap. I’m hoping we retire the old themes.
Themes should really be developed using SCSS instead of overriding bootstrap using our current implementation.
It’s on my list of todo’s: convert Light to a fully SCSS based them as an example for other themes to use
To expand on my previous post a bit.
Bootstrap has a variables.scss file where everything gets defined. Those variables are referenced throughout their CSS.
In order to create a solid theme solution, we should create our own variables.scss where we only define the variables wanted for that theme. So if a theme wants a different background color for alternating table rows but leave everything else vanilla bootstrap, that file would only define 1 variable.
Then the developer would run a Gulp task which compiles the SCSS down to CSS (could also minify here as well). Then, the final CSS for the theme would have all the bootstrap stuff, with the theme changes baked right in.
This would allow us to only include the theme CSS and never import the vanilla bootstrap file (it’s already inside the theme CSS).
I use this workflow all the time. I’ll be spending some time on theming MedEx soon and can easily add this into my stuff, it’s just a matter of getting to it.
The biggest takeaway is to not add non-bootstrap classes unless absolutely required. And when doing so, defer to bootstrap to figure out how to best integrate any custom classes.
I’ll write up some documentation
Robert, I hope nobody thinks I’m being critical because far from it. Thanks to you and some others our U.I now is starting to reflect, to the user, the very good underlying architecture that is OpenEMR. I’m also confident you have the engineering well in hand and understand you can only do so much time wise. However, in the interim, I have one major concern, which is, the current order the theme is loaded. Eventually, those themes (all twenty or so) will be used to help create the variables and currently the theme is loaded, then bootstrap css. This causes the theme to not appear as intended. All i’m saying is that until you get the theme structure in final order, we should allow zigbe and others the benefit of knowing that the themes will have the correct precedence i.e change header to load bootstrap then style. I’ve tested this on a couple themes and the difference is fairly noticeable and more consistent thus, while folks are adjusting these themes for next release, now is the time to make the loading order change.
Again, thanks for tackling this tedious process that needed to get done. You can know, I appreciate it.
btw- would you not want to have the one variable which then is changed to reflect a new value for say a color change of a given class? Also, i’ll go back through and change the stuff I’ve restyled recently and also fix any I find while i’m going through code now for the new bootstrap based modal dialog. Any documentation of normal styles is greatly appreciated.
Agree that @robert.down 's plans will not impact the next OpenEMR 5.0.1 release(we can shoot for this in 5.0.2), which should be going out in 6-10 weeks.
For fixing the ordering of themes, lets get a PR out there so we can assess the damage 
(And if possible, I would not couple this with your modal work, or then one may drag down the other)
-brady
I’d like to echo @sjpadgett’s point… I am also confident in @robert.down’s abilities here as well. It’s a massive project and it has been fun to watch! The system is very nice looking now.
Will hopefully get a PR out either tonight or tomorrow with the theme ordering switch.
Great thanks. I’ve switch them and have been watching as I work on other stuff. Maybe I should open another thread for anyone to report issues after switch.
I’ll prioritize this along with getting a better solution in place.
Robert, I’d be more than happy to help if you task me with something.
Wow, that was kind of a let down. I was expecting explosions and for the OpenEMR world to end with the above commit, but the only thing I noticed is that maybe the default font size is just a bit too small.
Now the font family and sizes should have the proper precedent where, when I tested, the global fonts works nicely. Now if only we had a property in the Header class to exclude loading style sheet, we’d be golden…
I am also willing to bet the smaller font size I noted is just in the upper menu and tabs titles and will be easy to adjust (I had to do this in the past, as I recall).
Do you have a use case for skipping the style sheet (so have place to test it out)?
No production work flow I can think of but for testing and styling new pages it could be very helpful to start from the base class or to compare a style to the base bootstrap. So no for use in production but could be nice for development.
Maybe the login page? Also noted some portal/institutional pages that didn’t use main theme.
My changes in the Header class may of already given @robert.down chest pains. Would hate to cause more grief
That’s okay, I figured out I can just create blank style sheet to load… I would expect to see some issues just let me know and I’ll help resolve them.
Testing well after a couple minor styling fixes and just brought this into the main codebase.