So I’m working on the encounters list (interface/patient_file/history/encounters.php), adding some optional stuff including the ability to show form data. More about that soon.
My topic here is that CSS for this page is in the main stylesheets - style_oemr.css, etc., where there is a bunch of stuff that applies only to this page. Talking about the references to “#patient_pastenc”. To get my new stuff working I have to change that, meaning changing all of the stylesheets. Furthermore these are things that are unlikely to vary between themes.
That just doesn’t seem right. If nobody objects I’m going to move that part back into the <style> section of encounters.php. This issue will doubtless come up in other places too.
I heavily disagree with content in <style> sections.
if you needbe, create a page specific stylesheet. its not hard to add more stylesheet refs, but it is hard to manage code mixed with presentation, even if its only ‘dont both the web designer and the coder edit the file at once’.
You’ll note that the xml form generator generates forms with .css stylesheets of their own. it makes it much easier to swap out ‘form themes’. I’ve found there are at least three different ‘common looks’ for forms, two of which my form generator can generate, by using a different .css file.
Perhaps the non-theme-specific CSS could be imported into each theme with @import url(“otherfile.css”); If there were a base.css to define some standard things, the themes would only have to override those classes to change colors and fonts. Might make themes easier to make.
I’d rather not see style tags and fewer inline styles throughout the html as well.
So that it is easier for Designers / Artists, please keep CSS outside of PHP files. For styles that are using “id” matches (e.g. #foo or .frotz p #leader), it actually makes sense to not have them in the site-wide stylesheet, so using a page-specific .css file seems sane.
It also makes sense to load the page-specific stylesheet before the site-wide stylesheet, so that custom site-wide stylesheets (say, for visually-oriented clients) can override the page-specific stylesheet without having to use !important rules. Last I checked, changing that one css file and a couple of images is all the “theming” you can do to OpenEMR without reading / writing PHP. It would be nice for it to have as much utility as possible, in particular being able to override page-specific defaults that might work fine for the default theme, but not for your “Hot Dog Stand” theme, e.g.
(Caveat: If the PHP file is editable in an HTML/XHTML editor that lacks specific PHP support, because the PHP is largely non-structural, it’s probably okay to not use a speparate file.)
Thanks for the comments. My main issue is I’d like to be able to work on a piece of code without having to make an identical change to each of a potentially huge number of stylesheeets.
A page-specific stylesheet would certainly do the job as well, and arranging it so the main stylesheet can override some parts makes good sense.
Rod - As an example in the current work Aron is doing for Decision Rules GUI the page specific css is stored in a subdir of the work php itself. we should try to be consistent. The dir format in use by the rules engine looks like this:
/interface/super/rules/base
/interface/super/rules/controllers
/interface/super/rules/include
/interface/super/rules/index.php
/interface/super/rules/library
/interface/super/rules/www
/interface/super/rules/www/css - page specific CSS
/interface/super/rules/www/js - page specific JavaScript
We already have a /library and a /library/js that are shared by modules all throughout OpenEMR, so I was trying to be consistent with that. Also I like the idea of a shared /library/css to keep the styles in one place for the convenience of theme designers. But I can go either way and yes we should strive for consistency going forward. Anyone else want to chime in?
Yes, I’m going to chime in and declare /library should be core parts of openemr that without which it doesn’t function. they should be documented, and meant for use by more than one target.
I’m currently going through a lot of effort to remove one file from /library/js/.
Could automate the calling of the appropriate theme page. If put in library/css in the same directory structure as the source code with the same names (with a css at the end). Then the same line of code at the top of each script could call in (check that it exist first) the appropriate css theme file for each script. Then would keep css stuff separate from php, but would be limited to having one theme page per script (ie. couldn’t have multiple scripts use the same theme page). Also, as an aside we, won’t have the luxury of modifying css settings in real time when separate them out of the php files (ie. placing php code within them, which is done for example when printing css/html prescriptions).
hey,
Just to step back, why are we moving style components that are one script specific to their own file? I can understand that this makes sense if there is potential that the stylesheet will be called by multiple scripts (then would fulfill criteria to be a libary function, such as the css stylesheets for the calendar widget), but not clear why this is done if it’s specific to one script.
-brady
To further expand on above, Julia’s example of creating a separate css file makes sense because it is used for multiple form scripts. But are we saying that all style stuff needs to go into it’s own file even if its very specific for that one script?
Brady, I think the advantage of a separate css file for styling used only in one place is that a theme will have the opportunity to override some aspects of it. If you put it in a <style> section then that won’t happen (or might not, depending on the browser). This is based on some assumptions that I’ve not fully researched or tested, so they might be wrong.
Perhaps static files like css, js, and images could hide under their own structure pointed to by a global? This might facilitate the use of a CDN and/or separating PHP code from the document root.
Well I was wrong. An embedded <style> section can have either higher or lower precedence than a separate stylesheet file. There are also rules for what overrides what according to specificity… for example, matching on ID trumps matching by class, regardless of which rule came first. Try out these files:
File css1.css:
.class1 { color: blue }
.class2 { color: blue }
#id3 { color: blue }
File index.html:
<html>
<head>
<style>
.class1 { color: red }
</style>
<link rel="stylesheet" href="css1.css" type="text/css" />
<style>
.class2 { color: red }
.class3 { color: red }
</style>
</head>
<body>
<p id="id1" class="class1">This is red locally, blue in the stylesheet.</p>
<p id="id2" class="class2">This is blue in the stylesheet, red locally.</p>
<p id="id3" class="class3">This is blue in the stylesheet with an id selector, red locally with a class selector.</p>
</body>
</html>
The output lines I get are blue, red, blue.
So, right now I’m not seeing any need at all for a separate stylesheet used by only one script. Just make a <style> section that precedes the link to the main stylesheet.
I’m good with housing the css and js in a common location across the project when it makes since. I really think we need to continue working toward separating the style elements and HTML from the php logic programming in as many a places as it makes sense for all the reasons Stephen pointed out. Aron’s model is based on industry standard practices for very large, robust deployments.
So, I think that CSS (and JS) that can or should be shared (like all common functions) should be in the library dir and stuff that is highly specific to a given page/module should be kept with that module. I prefer that it be kept separately and included versus embedded.
Still not clear of the advantage of separating style and js elements from the php code that are only specific to one script. Agree that if the code would be usable somewhere else, then should be separated and placed in library (same strategy for php code that is useful in more than one place) directory. Definitely don’t understand why stuff specific to one script should be in the global css file. Practically, my worry is that you’re simply adding another hurdle for developers to get their code committed. I’d rather have Rod get his code/feature committable in the quickest OpenEMR friendly fashion than delay it by adding an unrelated hurdle to his code/feature.
Well I see one practical advantage (noted by Stephen) of a separate stylesheet for only one PHP script - that I get nice syntax highlighting from my text editor. If it’s all in a .php file then I get PHP syntax highlighting but not CSS highlighting.
At least for OpenEMR, I see the notion of separate designers/artists vs. programmers as a fantasy. We all seem to be experts at both and/or nobody’s going to pay for both, and it’s just never gonna happen. On top of that, CSS extends into the realm of logic and PHP extends into the realm of visual design, so anyone working on the project needs some understanding of both anyway.
In this case I’ve got about 55 lines of CSS, so there’s some sort of justification for the syntax highlighting argument. And in spite of my own views I did ask for feedback and the response was 4:2 in favor of a separate stylesheet. So what I’ll do is create /library/css and put a new encounters,css in there.
My recommendation is: Make a <style> section if it’s just a few lines. Otherwise put your stylesheets in /library/css, unless your religious beliefs forbid it, and in that case do whatever you want.
