Just wondering if there is any documentation covering the hierarchy/order in which the CSS is applied in Omeka? The "Working with Public Themes" tutorial only seems to cover the Sass approach...
eg1a. will the style.css for a supplied theme (eg. Berlin) always control all possible elements in that (uncustomised) theme? Or could there be situations where the CSS is inherited from somewhere else?
eg1b. is there any situation where entries from admin\themes\default\css\style.css might get used within the main (non-admin) pages?
eg2. Sometimes the PHP or JS seems to inject or override CSS - we are still trying to narrow down when this happens (One example is jcarousel.responsive.js where the width gets adjusted).
Thanks in advance for any insight...
In order to use css provided from an external source, you'd have to modify the theme's
header.php in the 'common' directory. I would look at the documentation for 'queue_css_file()', 'queue_css_string()', and 'queue_css_url()'.
If you include another stylesheet file within the theme's 'css' folder, you can add it to the theme's css call after the default. It would look like this (taken and modified from the Seasons theme
queue_css_file(array('iconfonts', 'normalize', 'style'), 'screen', 'yourcss');
If you'd rather add your own CSS via the admin interface, there's the CSS Editor plugin, which adds css rules that take priority over the theme's default css.
Regarding the PHP and JS that overrides the CSS, it's hard for me to assist without seeing a more specific example, but offhand I'd say inline CSS, which is what typically gets injected by JS, tends to override stylesheet rules.
I'm not sure what kind of use case you're thinking of with (eg1b), but that's only used if the theme doesn't provide a stylesheet or you specifically modify the theme to call it.
Thanks - that helps, especially now knowing the CSS Editor overrides the theme's style.css.
The eg1b is not so much a use-case as clarifying whether admin CSS can override the theme's CSS?
A colleague claimed he had to make a change to the admin style.css (specifically ".image img") to customise the display of an image on a SimplePage (Berlin theme) - but I thought admin CSS only affected the admin dialog, and am hesitant to allow any changes to core Omeka code that should get done via plugins or themes (and we do not go back to uni for a week for him to demonstrate).
If the hierarchy is essentially like below then I can reject the admin code change in favour of the CSS Editor approach:
inlineCSS <- CSS-Editor <- Theme-CSS <- Admin-CSS
Yup, that hierarchy should be accurate.
Just wondering if the following refinement to what was stated might be accurate (after I found some CSS within /plugins and /application) ?
/admin | /themes(public)
+-- /application --+
If this is the case, then it clarifies my original eg1b completely (so a change on /admin CSS cannot affect the public pages, and CSSEditor code would override every other possible path except inline).
I guess it also opens up extra options for omeka.net users who cannot find an aesthetically suitable theme (though wondering whether there might ever be a JSEditor and a PHPEditor in future?).
The "hierarchy" really only applies to the loading of CSS files. On the public side, it goes:
theme > application/views/scripts
There are some more rules when it comes to plugins, but this is good enough. CSSEditor uses a hook which conventionally will put its CSS after all the links to external stylesheets, so its styles will generally override anything else. Note: CSSEditor only puts its styles on the public side, not the admin.
As for "inline" styles, the theme writer controls whether those appear before or after the "normal" stylesheets and styles. If before, they get the lowest precedence, if after, the highest. (Assuming of course the selectors are the same, otherwise CSS's own precedence rules come into play).
For the admin side, things are similar:
admin > application/views/scripts
As you said, admin is totally separate from the public side stuff. A change to anything under admin, including CSS, will not affect the public side. The only "shared" styles or views are in application/views/scripts or in the "views/shared" folders of plugins.
Ok - thanks! I think I've got it now, having also just read about CSS precedence/specificity rules.