On Thursday 21 August 2008 10:52:50 Mike Kerr (kerrnel22) wrote:
> > split the CSS in two maybe tree :
> > layout.css : for positionning stuff
> > design.css : for colours, borders and other attributes
> > images.css : for icons and images
> >all three placed in styles/my_theme/ directory
> It's difficult enough keeping track of the theme files. One of the
> things I like about Tiki themes is that they are simple. Unlike PHPBB
> or such where there's dozens of files.
Simple ?!? did you already tried to make one from scratch ? :/
I like sept_7's proposition because our unique .css file is too huge and
there's too much work, IMO, to maintain each themes css.
For me, multiple .css files is more a solution than a problem. It helps
separate things cleanely, in order to reduce the work needed to make a new
theme from scratch !
Well... as Sept_7, I'm just a developper, but used to work on new themes for
TikiWiki too. I both tried to make themes based on tikineat and tikinewt
(done for my boss), and also new themes from scratch (e.g.
jardin-botanique-saverne.org ). So, chibaguy, luci and patrick will probably
have more experience, but since we are speaking about this, I want to share
my experience and my thoughts about this...
For me, the main problems are that:
1) there is too much css classes defined in our themes and we don't know
were and how there are used until we use the related feature,
2) we are not able to know which parts of the css can be changed for simple
relooking (colors, sizes, etc.), and which parts are needed for the whole
3) it's quite hard to keep our own themes in synchro with official ones,
especially when done from scratch or too much forked
So... for those problems, I would prefer those solutions :
1) dramatically reduce the number of classes, list them and document them to
know in which kind of places they have to be used (this has to be used as
guidelines for developpers who create or modify .tpl files). We spoke about
this at TikiFest Strasbourg too. If I remember well, Luci has agreed to start
the work on this. What I expect (or need, when making themes) is a simple
list of basic css classes/id that I have to style in order to have make a
theme quickly. Something like this :
.icon : class used to style each action icons,
.button : class used to style each action buttons,
table.normal : class used for every table listings,
tr.odd : ...
tr.even : ...
div.box : ....
h3.box-title : ...
... and so on ...
If we can have a list as short as possible that enables newbie designers to
theme 90% of tiki, it would be a victory (IMO).
I think this list should be made even if it does not reflect all tiki parts
yet. We will be able to change .tpl to use those classes when needed, in
order to have a more homogen application. Changing the tpl files is the easy
part, but we need some guys to propose this kind of list / guidelines first.
This should avoid newbie developpers to create more and more css classes, just
because they did not know that there was already some styles for the same
2) To solve this second problem, I would have suggested something like
sept_7's suggestion. I think we need a way to separate styles that are used
to make things work/usable from styles that will just be there to change
colors or image backgrounds, etc.
Suppose we follow, for example, sept_7's proposition, with at least those two
* layout.css : for positionning stuff,
* design.css : for colours, borders and other attributes
Then, making a new theme will simply imply to make it's own design.css.
If you don't have to dramatically change the structure of things, which is the
most common case (nearly 98% of cases, I presume), there is really no need to
worry about things that are used to place elements correctly on the page.
Then, sept_7's proposition is not to maintain two files for each themes, but
still only one file (design.css) which will be really smaller (and even less
dangerous). I think this is important for designers. They should be able to
start a new design.css from scratch, if they want, and still have everything
that displays correctly with an empty design.css file.
3) About keeping own themes in synchro with official ones, again, Sept_7's
proposition seems a better choice compared to the current one. You usually
need to update your own theme css due to page structure changes. Not all, but
a lot of them will then be in layout.css, and you will just have nothing to
do (if you didn't forked the layout.css).
The, your design.css will have to be updated, which will imply less work than
what we have to do today.
> I like the way my theme is now one css file and a couple of template
> changes. It's hard to reconcile custom templates specific to a theme
> back to changes made to base themes. I've had several situations where
> things broke horribly because of minor changes that seemed to have major
As said above, for me you will still be able to have only one css file in your
theme. It will just contain less things by default. And if you really need to
fork templates, you will again have either the choice to add your specific
things into your own design.css, or fork layout.css and have then two files
instead of one, which is not a big problem compared to the other benefits...
I understand your specific case of forking some .tpl files. But this is surely
not the most common case and if we want to allow more designers to contribute
themes, we will have to simplify their work. Forked templates is something
bad, especially when thinking about official styles and themes.
I'm personnally really against forking templates. For every tiki sites I used
to make, I always tried to avoid forks as possible, by contributing to the
main code (with options) instead. It's a bit more work, to make things
generic and reusable, but both the community and you will benefit from this
in the long term.