Koha uses the Yahoo! UI Library Grids CSS framework for both the OPAC and the staff client. When we revamped the Koha interface for 3.0 the Grids framework was chosen because it would simply the process of structuring pages while giving us a pretty good selection of possible layouts.
A nice feature of the Grids framework is that you can control the layout of your page with relatively minor changes in markup. Here’s an example for one of the basic layouts:
<div id="doc"> <div id="bd"> <div id="yui-main"> <div class="yui-b"> <p>Main Content</p> </div> </div> <div class="yui-b"> <p>Sidebar</p> </div> </div> </div>
You can see that YUI’s Grids framework suffers from the same problem a lot of CSS frameworks have: the class names are pretty nonsensical if you’re not used to them. I consider this to be par for the course: Better that they be nonsensical than have semantic-sounding names which aren’t appropriate for your actual page structure.
The above example shows how the “primary” page structure can be changed. I say primary because you can only choose one of those layouts at a time. If you want to have additional columns or blocks within that layout you can use “grids” and “units” within that main page structure:
Just like with the page structure, there is a set of pre-defined grid structures you can use within your page. The simplest is a set of two equal-width containers:
<div id="doc"> <div id="bd"> <div class="yui-g"> <div class="yui-u first"> <p>First grid unit</p> </div> <div class="yui-u"> <p>Second grid unit</p> </div> </div> </div> </div>
Just like with the page structure example, a change to the grid’s class name can affect the layout of the units within it. Notice that the grid/unit structure is changing within the page structure we defined before: a single main block with a left-hand sidebar:
The power of the framework’s grid/unit structure really comes into play when you start nesting grids within grids. Start with a grid which creates two equal columns, and then nest the same two-column grid within each of those columns:
<div id="doc"> <div id="bd"> <div class="yui-g"> <div class="yui-g first"> <div class="yui-u first"> <p>Unit one, sub-unit one</p> </div> <div class="yui-u"> <p>Unit one, sub-unit two</p> </div> </div> <div class="yui-g"> <div class="yui-u first"> <p>Unit two, sub-unit one</p> </div> <div class="yui-u first"> <p>Unit two, sub-unit two</p> </div> </div> </div> </div> </div>
In the markup above, instead of nesting a unit (‘<div class=”yui-u”>’) inside a grid (‘<div class=”yui-g”>’), we’re nesting a grid inside a grid. The containing grid can still be altered to change the layout of the units inside it:
The Koha OPAC’s grid structure
How is this implemented in the Koha OPAC? Koha has to take advantage of the Grids framework’s flexibility when obeying different conditions in the OPAC. Take, for example, the main page of the OPAC. There are four possible layouts the user might see based on state and system preferences:
Using some logic in the Koha templates, the layout can be easily altered based on each of those conditions. And because the Grids framework makes it so easy to switch between those different layouts, the template can be much simpler:
<!-- TMPL_IF NAME="OpacNav" --> <div id="doc3" class="yui-t1"> <!-- TMPL_ELSE --> <div id="doc3" class="yui-t7"> <!-- /TMPL_IF -->
The template logic can check one condition (whether the OpacNav system preference is populated) and alter the page layout accordingly.
What does this mean to me?
Unless you’re hacking Koha templates you won’t many opportunities to build your own grids. However, there are a couple of instance where you might want to try it, and I’ll talk about that in my next post.