Pascal, Luci, Gary, Patrick, Marc, Mike, Sylvie, and Rob (in various combinations) discussed the following:
- 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: 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 ??
- 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.
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
Tikinewt (or maybe not since it replicates an old style and the CSS file is not modernized)
Simple (but Luci said it needs to be updated and some custom files removed)
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".
-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:
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.
- 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.
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