Joshua and I have been discussing the future of the prog templates, and we'd like to get some input from the group. The prog templates were originally intended as minimal templates with only structural markup with no style information. They would be used only by programmers when develeloping new features. Because the templates would be minimal, it would be easier for designers of alternate templates to diff changes and incorporate them into their own templates. Now that 3.0 is starting to be used in production environments it's time to ask, are the prog templates still serving that purpose, or are they becoming the defacto default template? The issue is important to me because I believe that in order to provide the right amount of flexibility and detail for good design and usability the templates would have to be expanded: additional markup would have to be added to create the possiblity of one, two, and three-column designs, for instance. Divs would be added for the purpose of controlling layout--divs which have no semantic meaning. This kind of change is at odds with the original intention of the prog templates. If it is agreed that the prog templates should be expanded to allow more flexibility for more complex styling, some discussion would have to follow about the kind of layout scheme we should use. The system I chose for NPL's dev_week opac, for instance, is based on this one: http://www.positioniseverything.net/articles/onetruelayout/appendix/holygrai... It has worked well for us, but includes some extra markup, as I said. If others have a tried-and-true layout that uses less extraneous markup please chime in. What does everyone think? Thanks, Owen -- Web Developer Nelsonville Public Library http://www.athenscounty.lib.oh.us
Hi Owen, I haven't compared it for how much extra markup is involved but a template I've been using lately is based on http://www.tjkdesign.com/articles/3cols.asp It took a little while to get the hang of how it worked but it is very flexible - changing from a 3 column layout to a 2 column one involves 3 changes in the css with no changes in the markup. Disadvantages of it include requiring gifs to get coloured left or right columns. Cheers, Richard -- Richard Anderson Web Team Leader Katipo Communications PO Box 12487 Wellington Web: http://www.katipo.co.nz/ Ph: (04) 934 4251 (DDI) (04) 934 1285 Fax: (04) 934 1286 Mobile: 021 043 3649
Owen Leonard <oleonard@athenscounty.lib.oh.us> wrote:
The issue is important to me because I believe that in order to provide the right amount of flexibility and detail for good design and usability the templates would have to be expanded: additional markup would have to be added to create the possiblity of one, two, and three-column designs, for instance. Divs would be added for the purpose of controlling layout--divs which have no semantic meaning. This kind of change is at odds with the original intention of the prog templates.
I'm still AWOL really and I'm neutral about most of this question - anything is better than taming the jumble of html that was there before - but here's my stupid question: why would non-semantic divs be needed for controlling layout? Can we add semantic divs and use those to create the layouts instead? Regards, -- MJ Ray - see/vidu http://mjr.towers.org.uk/email.html Somerset, England. Work/Laborejo: http://www.ttllp.co.uk/ IRC/Jabber/SIP: on request/peteble
I'm still AWOL really and I'm neutral about most of this question - anything is better than taming the jumble of html that was there before - but here's my stupid question: why would non-semantic divs be needed for controlling layout? Can we add semantic divs and use those to create the layouts instead? This is my initial reaction as well -- but I suspect we'll run into some
On Mon, Nov 20, 2006 at 11:57:56PM +0000, MJ Ray wrote: limitations in the CSS standard's ability to lay out the page the way our clients want it laid out (all pretty like). I think our goal should be to keep the non-semantic markup to a minimum -- and certainly if anyone has suggestions for how to improve the semantics of a given template without sacrificing the flexibility we need by all means please speak up. Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
MJR wrote:
why would non-semantic divs be needed for controlling layout? Can we add semantic divs and use those to create the layouts instead?
I'm not an expert at CSS layouts, so I rely on the expertise of others. What I find is that the flexible CSS layouts offered by the pros these days include (at the very least) div elements which don't have a semantic purpose. The link Richard posted is a good example, complete with diagram: http://www.tjkdesign.com/articles/3cols.asp That particular solution includes an outer wrapper, wrapper, and container div, each serving a purpose in controlling the layout. NPL's layout scheme is similar, using more than one layout div that's not semantically meaningful. Joshua wrote:
I think our goal should be to keep the non-semantic markup to a minimum
Of course. Like I said, I'm not an expert in CSS layouts, but when I see the experts relying on wrapper divs, I come to the conclusion that they're necessary. The direction this conversation has taken leads me to think that folks do believe that the prog templates should be reimagined as the default template, providing a robust but minimal framework. If anyone disagrees, please chime in! I'm all for that, but taking that direction will lead to considerably more complex prog templates, as various spans and classes will have to be added in order to make it possible to fully control the design. -- Owen -- Web Developer Nelsonville Public Library http://www.athenscounty.lib.oh.us
Owen Leonard a écrit :
What does everyone think?
My opinion is : - we have 2 different templates design for librarian interface in Koha 2.2, and IT'S A PAIN (yes, I cry !) We MUST avoid at all cost the need of more than 1 template in rel_3_0 !!! For OPAC, it's not so critic, as there are "only" 15 templates or so. but I think it could be a good thing to have only 1 set of templates for OPAC. - I've added a include_dir systempreference in cvs that let the library define it's own includes directory content. the includes directory contains all CSS, but also all templates headers, menus & footers. That introduces a 2nd level of customization (css only being the 1st one). - I think http://www.tjkdesign.com/articles/3cols.asp is close from what we have now (and comes 80% from npl templates) : we have a menu level (=header, on the left by default for PROG), a module menu level (= sidebar, on the top by default for PROG), an action level, for all actions we can do on a page (= left, on the top by default for PROG). I even have added some options in the CSS to show how to move the action bar to the right in just a CSS modif. - The coding guidelines says that every div should have a unique ID (even if I know it's not 100% followed) So my opinion is that PROG templates will be the default one for 3.0 (it is already, as all default templates have been removed ;-) ) AND we can continue improving them, knowing that we already have a strong & customizable basis. -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org) Tel : 04 91 31 45 19
participants (5)
-
Joshua Ferraro -
MJ Ray -
Owen Leonard -
Paul POULAIN -
Richard Anderson