Version 30

TemplateChangelog

plans for template changes in dillenger

Created by: xing, Last modification: 07 May 2005 (10:26 UTC) by xing
at the moment, these suggestions are mostly meant for the dillenger release, as they would cause too many backwards compatibility problems if applied in clyde.

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

already implemented in clyde

.contain and .admin

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

we have decided to change these classes to
.display
.listing
.edit
.admin



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.

olfactory

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

use <ul><li> 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:
<div class="top" style="background-image: url($foo); background-position: top left;">...</div>

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:

<?php
...
<
th>
{
smartlink ititle="foo" isort="title" isort_mode=$sort_mode}
</
th>
...
?>

additional notes:
to view a full list of options please see the file
kernel/smarty_tiki/function.smartlink.php

reducing number of divs

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

could become:
{code(color=css)}
<div class="box">
<h3>foo</h3>
<p>bar</p>
</div>
{code}

would allow for same amount of styling freedom. the only downside is that <p> doesn't allow block elements in xhtml, which means that we have to close off </p> before adding divs and lists

{code(color=css)}
<div class="header">
<h1>foo</h1>
<div class="date">bar</div>
</div>
{code}

could become:
{code(color=css)}
<div class="header">
<h1>foo</h1>
<p class="date">bar</p>
</div>
{code}

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

theme
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.
style
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

Page History
Date/CommentUserIPVersion
20 Apr 2006 (08:25 UTC)
update code blocks
xing194.152.164.4535
Current • Source
xing194.152.164.4534
View • Compare • Difference • Source
xing194.152.164.4533
View • Compare • Difference • Source
xing194.152.164.4532
View • Compare • Difference • Source
xing194.152.164.4531
View • Compare • Difference • Source
xing194.152.164.4530
View • Compare • Difference • Source
xing194.152.164.4529
View • Compare • Difference • Source
xing194.152.164.4528
View • Compare • Difference • Source
xing194.152.164.4527
View • Compare • Difference • Source
xing194.152.164.4526
View • Compare • Difference • Source
xing194.152.164.4524
View • Compare • Difference • Source
xing194.152.164.4523
View • Compare • Difference • Source
xing194.152.164.4522
View • Compare • Difference • Source
xing194.152.164.4521
View • Compare • Difference • Source
laetzer217.231.172.10120
View • Compare • Difference • Source
xing194.152.164.4518
View • Compare • Difference • Source
xing194.152.164.4517
View • Compare • Difference • Source
xing194.152.164.4516
View • Compare • Difference • Source
xing194.152.164.4515
View • Compare • Difference • Source
xing194.152.164.4514
View • Compare • Difference • Source
xing194.152.164.4513
View • Compare • Difference • Source
xing194.152.164.4512
View • Compare • Difference • Source
xing194.152.164.4511
View • Compare • Difference • Source
xing194.152.164.4510
View • Compare • Difference • Source
xing194.152.164.459
View • Compare • Difference • Source
xing194.152.164.458
View • Compare • Difference • Source