Pascal, Luci, Gary, Patrick, Marc, Mike, Sylvie, and Rob (in various combinations) discussed the following:
Specific items
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: http://zvon.org can be used as a reference on validity.
To chack if a given template/page is valid. use the firefox developer tools extentions.
Common repository - most legacy themes in the Tiki package have been moved into Mods (http:mods.tiki.org). Tikineat will follow.
For these themes to work they have to be compatible with Tiki 2, currently.
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 ??
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.
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
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.
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 TemplateBestPractices
Indentation in templates - needs to be readable.
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
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.
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 -
See 110 CSS