Pascal, Luci, Gary, Patrick, Marc, Mike, Sylvie, and Rob (in various combinations) discussed the following:

Cleanup of CSS tags in templates.

Specific items

• Divs with the attribute "elegant" eg. in tiki-editquiz.php
• Align tags in divs
• Purpose of clear tags clarified.

Question: to what extent are we willing to break existing custom themes? The consensus seemed to be that users who customize themes need to be responsible to keep them up to date. If CSS classes change, it isn't possible for the Tiki project to take responsibility for themes produced outside the project having compatibility problems as a result. Changes need to be properly documented - advance warning needs to be given.

BIRT (be it resolved that): removing all atributes that are not strict xhtml-compliant - forcing the removal of most attributes that cause a nuisance. - consensus

Compliance tools:

To chack if a given template/page is valid. use the firefox developer tools extentions.

Themes in Mods

Common repository - most legacy themes in the Tiki package have been moved into Mods (

For these themes to work they have to be compatible with Tiki 2, currently.

Reiterated that lite.css will be used as a base for all bundled themes in 3.o.

Default templates

Idea: wiki template should have button row appear at top or bottom or both.

Note: wiki UI and site identity project in the works for december ??

• Method for UI fixes: can we turn on all the features and then design them so that they are not ugly together?
• Using javascipt to improve usability is desirable but the rule should be not to break Tiki - this needs to be evaluated case by case - explain on dev list.
• Increasingly more stringent guidelines are emerging for standards like accessibility.

Look and Feel (Site Identity)

Site identity allowed certain parts of the theme to be contained in the database. this makes it much easier to upgrade sites with custom themes because the special header is defined by the database.

Basic layout

Can we provide for user to pick a basic layout via the admin panel?

discussion could we have different tpls for different. ??

- Full-page width with header, three columns, and footer
- Centered "fixed-width" content area with side margins

Discussion favors keeping to a single (if more complicated) tiki.tpl

About themes in TikiWiki 3.0

Have only one tiki.tpl in the core files (all bundled themes use templates/tiki.tpl, not a theme-specific variation).

TikiWiki should(?) ship with

Darkroom
Tikinewt (or maybe not since it replicates an old style and the CSS file is not modernized)
The News
Simple (but Luci said it needs to be updated and some custom files removed)
Feb12

Gary pointed out that the lite-based themes are remaining in trunk not because they are particularly wonderful, but their methods and designs are more modern, etc. More theme contributions/ideas are welcome.

Other ideas

Default theme should be the theme of the tikiwiki.org website.
Default theme should be attractive and flexible because many people don't change it.

tiki.tpl — should there be just one?

Kubrick rejected for simplicity ??
no forking of tpl's period.

Move everthing possible to separate tpls so that only layout exists in tiki.tpl.

Background image configurable in the admin panel.

Ability to override theme styles with DB-stored theme information - then themes could be managed with profiles.

To show "best practices", examples can be shown in a wiki page and/or in a "template template".

devtools

-a template template - what we think a template should be.

a wiki page to read showing a

Indentation in templates - needs to be readable.

More readable CSS

Gary recommended TopStyle CSS editor (for Windows users), which has a palette tool that shows all colors in a file.

Mike's suggestion of CSS selector organization:
included
color manager
Layout
basic html
sitewide classes
feature specific classes

CSS Best practices

Modify as few templates as possible

Customizers can use display:none instead of removing code to hide things.

Avoid feature specific classes use decendant selectors instead.

Function specific classes ok.

CSS for data tables.

• Guideline for CSS for tables being worked out, specifically . . .
• Feature-specific classes in tables are being removed.
• New classes for aligning data table column content.

Reducing the number of selectors.

Functional selectors for specific features - which are added as new features are available should be either.
used for relative placement etc. - should not have design (color formatting size etc.)

design selectors -

Where to find the developer rules (guidelines says marc) about CSS and templates

See