plans for template changes in dillenger

Created by: xing, Last modification: 20 Apr 2006 (08:25 UTC)
at the moment, these suggestions are mostly meant for the dillinger release, as they would cause too many backwards compatibility problems if applied in ReleaseOne.

please raise any concerns / ideas you have as comments at the bottom of this page.

already underway in ReleaseOne

.contain and .admin

currently every page has a div wrapper with the following:
class="<content type=""><relevant class="" such="" as="" wiki="">"
currently content type is either

we have decided to change these classes to

API changes

Replacing tabs HTML with smarty block functions 2005-05-09

i have just replaced the existing html tabs code with smarty block functions. now, all you need to do to get tabs on your page is use the following code:

jstab title="foo"}
some useless text
jstab title="bar"}
some more useless text

The reason why we do this, is to allow for a simpler template code, an easier, centralised control of the tabs code and an easier way of changing to a different tabs script if needed.

$areaName to $textarea_id 2005-05-15

due to the introduction of the WYSIWYG editor PackageTinyMCE we need to specify what textareas should be targeted with the editor. this is done by assigning the id of the textarea to $textarea_id. (used to be $areaName).

dillinger progress

theme upload

i have just uploaded a theme called olfactory, which contains templates that will most likely be applied as soon as we have a dillinger branch. the reason for this is, that we have decided not to waste time updating old themes - perhaps only 1 or 2 with every version. this might seem radical, but tastes change and nowhere as much as on the web. in addition, new themes are generated relatively quickly and frequently.
if there are many requests for the maintenance of any given theme, i'm sure we can find someone willing to maintain it.


the olfactory theme contains custom template files for some prominent packages such as wiki and blogs. if you are interested you can get a copy of the theme from cvs. i can't post a copy here as the theme is currently in constant flux and anything here would outdate rather quickly if i don't upload a new version almost daily.

additionally, we are planning on rewriting the theme structure. please see ThemeStructureIdea2 for details.

package specific class

outermost wrapper around entire application
div id="wrap1 {$gTikiLoc.ACTIVE_PACKAGE}" ... package specific styling, totally cool

due to the nature of the ID tag as a unique identifier, it can't have a space separated list of selectors. for this reason i have opted for the following:
div id="wrap1" class="wrap-{$gTikiLoc.ACTIVE_PACKAGE|lower}" ...

this should not cause any compatability issues (keeping everything lower case for netscape) and the classname is unique as well.

Future changes

  • to be in accordance with w3c and wcag recommendations and it also allows for amazing styling possibilities using css

    • tools --> move to the bottom of the page (???)
      • lock / unlock
      • export
    • tabs --> move to the top of the page
      • edit
      • history
    • sorting --> remain just above the table
    where do the structure and backlinks dropdowns belong?

    use fisheye for banners

    allow for package specific banner inclusion. this will override whatever is set in the css and thus the css setting will be visible whenever no image is set for a given package.

    we can do this using css properties, which i think is the more elegant way, compared to including the image inline and it allows for text placement above the background image:

    advantage of inline CSS: this option could be a checkbox in every package's settings

    this could also become a page-specific inclusion

    page specific classes

    div class="display <package><pagename>" ... for page specific styling, comes in handy when only one listing in a page should look funky, or the 4th image of the 2nd gallery

    making tabs optional

    this means that it should be possible to disable the inclusion of the tabs javascript file. some minor tweaks of the appropriate css files should make die forms display quite nicely.

    tables and their headers

    we really need to sort out these friggin table headers and the sort links. it's impossible to debug these endless links in the tpl files with all the conditions.

    i propose we pass a comma separated list of values to a smarty function, which does the rest

    the template stuff:
    {smartlink ititle="foo" isort="title" isort_mode=$sort_mode}

    additional notes:
    to view a full list of options please see the file

    reducing number of divs

    the number of divs used in bitweaver is still a bit excessive. perhaps we can find a couple more places where these can removed / changed to something else:
    <div class="box">
      <div class="boxtitle">foo</div>
      <div class="boxcontent">bar</div>

    could become:
    <div class="box">

    would allow for same amount of styling freedom. the only downside is that

    doesn't allow block elements in xhtml, which means that we have to close off

    before adding divs and lists

    <div class="header">
      <div class="date">bar</div>

    could become:
    <div class="header">
      <p class="date">bar</p>

    themes manager

    since the structure of themes is changing considerably, we should change the user interface as well.
    the first coice will be how many columns should be present on your site (one, two or three). after this, you are taken to a page that has a set of styles you can choose from. every style is accompanied by a small screenshot of the given style (perhaps 150x150px or so).

    deleting themes

    there will always be an option to delete a given style from your server, but not an entire theme. this is way too radical and might cause the unwanted loss of styles. if a given theme doesn't contain any styles, it isn't displayed anymore for selection.

    editing themes

    due to the complexity of the css files, i'm not sure how to deal with a css editor. perhaps it's best to just use a textarea that allows users to edit a copy of the css file directly, and allow the upload of images that can be used.
    i will try and simplify stylist and get it working again soon.

    term definitions

    a theme is the basic definition of what the layout of the page should be, such as the number of columns, which in general can range from 1 to 3 columns.
    a style is the look and feel of the site without interfering with the layout.

    minor changes

    using .current instead of .selected
    better choice of words and isn't as similar to select


using H-tags and SEO

by Jonas Bohlin, 15 Mar 2005 (12:28 UTC)
Isn't using css to modify the look of the header (be it H1 or h2) inside the header-class better than wrapping an actual header with a P-tag?
From a Search Engine Optization-viewpoint I would thik it much wiser to actually indicate that it is a header being displayed. For WAI as well.

Re: using H-tags and SEO

by xing, 18 Mar 2005 (08:58 UTC)
good point jonas,

the reason why i put that in was that the h2 tag in the header frequently gets used to display some random information rather than a subtitle.

i have removed that proposal though. the only thing that could be done, whould be changing that to an h3 rather than h2, making it slightly less prominent when printing.

so we'd end up with



btw, thanks for the comment. didn't know anyone took interest in these pages.
  Page 1 of 1  1