Theme development: Segmentation, control and normalization?

[mbria]

Hi fellows,

I'm building a new theme for a new magazine and as in every OJS theme... I found I need to deal with /styles or /lib/pkp/sytles folders (In other words: shared CSS for every OJS magazine).

May be it's just me, but would be nice to avoid those shared CSS if you want.

So those are my suggestions to improve OJS's templates:
a) Separate "presentation" and "functionalities" (just in case somebody don't want -for instance- change notifications tooltips, but wants to remove the CSS responsible of the fonts, colors and so on...)
b) Add a new function in vim lib/pkp/classes/template/PKPTemplateManager.inc.php called "deleteStyleSheet' or so (resetStyleSheet function could be a fast easy solution).
c) And last, but not least: Work over normalize.css (or resetCSS if is your preference)

BTW, I normally take the uncommon theme (or one of my theme adaptations) as an starting point but today I started over Vanilla.
Any suggestion about the BaseTheme?

Just my two cents, hoping it will be useful for OJS' improvement.

Cheers,
m.

[mbria]

I missed to say that normalize.css could be added to your theme (pe: FooThemePlugin.in.php) with activate method as follows:

Code: Select all

    function activate(&$templateMgr) {
            // Subclasses may override this function.

            if (($stylesheetFilename = $this->getStylesheetFilename()) != null) {
                    $templateMgr->addStyleSheet($path);
                    $path = Request::getBaseUrl() . '/' . $this->getPluginPath() . '/' . 'normalize.css';
                    $templateMgr->addStyleSheet($path);
                    $path = Request::getBaseUrl() . '/' . $this->getPluginPath() . '/' . $stylesheetFilename;
                    $templateMgr->addStyleSheet($path);
            }
    }

But I think it's a good idea to include it directly in every theme... and if somebody doesn't like it, just "resetStyleSheet()".

Cheers,
m.

[asmecher]

Hi Marc,

The CSS that's currently in OJS (and OCS and OHS) is pretty garbled and has been for some years. We've been hesitant to tackle it because a lot of people have tweaked the CSS and we wanted to overhaul it properly, once, rather than forcing people to adapt to successive refinements when they just wanted a stable layout.

The structures in OMP are most of the way towards the solution we want for OJS. They still involve lib/pkp, and in fact divide the stylesheets up into many more pieces than OJS did, but they use much more logical structures -- and in the coming spring we'll be working to improve those structures and fold them into OJS. One of our major goals here is to make theming easier.

In the meantime, the best way to theme OJS is to build a stylesheet overriding the specific styles that exist in the built-in stylesheets that you want to change. It shouldn't be necessary to modify existing stylesheets, just to override the styles they specify. This means the resulting stylesheet will be tasked with undoing many of the styles you don't like, but that's unfortunately a necessary evil at the moment.

Regards,
Alec Smecher
Public Knowledge Project Team

[mbria]

Hi Alec,

Thanks for your comments.

I noticed that OMP is better on a) [Separate "presentation" and "functionalities"]
but still lacks on b) [Methods to control CSS/JS loading from theme definition]
and c) [normalize.css or resetCSS libraries]

Finally, CSS mix and compression is not mandatory but would be also appreciated as performance improvement.

From this list, if I'm reading the code correctly "b)" could be implemented in less than 10 minutes (at least a simple resetStyleSheets()) and I believe will help themers that want a completely clean starting point to build their "skins".

What do you think?
I can submit a patch with the new resetCSS method if you like.

Cheers,
m.

[asmecher]

Hi Marc,

Your assessment looks correct to me; the remainder of the work will need to be done in the coming few months. (Note that we're using LessPHP, which compiles Less-format stylesheets into a single compiled CSS file; further compression could be added there.)

The style has not yet been well separated from the structure. My thinking is currently that we'll do a better job of this, and then allow the user to use their own style CSS rather than load it on top of the existing theme CSS to override previous styling (as is currently done with OJS). However, I'm very much open to input on the details of this, i.e. how much styling should be built in and how much should be left to the CSS author.

Thanks,
Alec Smecher
Public Knowledge Project Team

[mbria]

Including a CSS compiler are a really good news.
Thanks. It will definitively make themers' live easier.

About the resetStyleSheet() method I suggested "could be developed in 10 minutes"... I found it's not as easy as I expected.
Looks like in OJS 2.3.6 some CSS are hardcoded in header's templates so "templateMgr" object can't remove them in the same way addStyleSheet() method can add.

Any case, would be nice if PKP takes in consideration the proposal of improving theme/CSS/JS methods in future OxS releases with methods like deleteStyleSheet($path), resetStyleSheet().

Cheers,
m.

[asmecher]

Hi Marc,

When we get to coding that (which shouldn't be too long) I'll try to make sure we do some consultation on the forums first.

Thanks,
Alec Smecher
Public Knowledge Project Team