We are streamlining a theme that should be an example for beauty and speed. In other words, we're introducing clean XHTML and thought-through CSS. This page summarizes what should be considered while shaping the code. Checkout TikiWikiTheme for more information.
3 pages

XHTML

Tables

• <table> gets some new tags:
  • colgroup
  • thead
  • th
  • tfoot (under discussion)
  • tbody
  • summary (only tables used for data-listings)

Forms

• <form> gets:
  • at least one <fieldset>
  • a <legend>

To kill:

• <div align="center">
• class="tableheading"
• class="normal"
• border="0" in <img> but leave it for tables (tables are taken care of later)
• class="form"
• class="cell"
• class="formcolor"
• class="tabcal" (NOT id="tabcal")
• class="tabnav" (NOT id="tabnav")
• class="link"
• hspace="8"
• excess spaces (i.e. trailing whitespace & such)

To change:

• td class="heading" to th (without the class)

And ...

• indent with 2 spaces
• don't extra-indent Smarty syntax, unless it's very complex. (worth some discussion)
• indent and add line breaks, to make source code readable (the white space is taken care of later)
• add comments to make source code easy to understand, but only use Smarty syntax: {* comment *}. In fact, I vote for a construct like this: {* <!-- comment --> *}
• put the attribute right behind the tag (example: a class="link" href="...)
• all links get a title="" that start (ideally) with something like "Click here to ..."
• all images get alt="", but no title attribute
• use attr="value" instead of attr='value'

CSS

• shorthand (never vs partially vs always; to be discussed)

...page... Wiki page pagination has not been enabled.

Where do we compromise?

Browser quirks force us to compromise. The new theme should degrade efficiently. The compromises are mostly workarounds for the widely used but not so great Internet Explorer. I might make sense to stick those styling attempts into an extra CSS that gets @imported.

tag/attr	compromise	explanation
-+<input type="button">+-	insert class="button"	Despite CSS2's attribute selectors (-+input[type=button] {...})+- add a class to input elements that represent their type. Now it's possible to style different input fields for IE users, too.
tag/attr	compromise	explanation

...page... Wiki page pagination has not been enabled.

some other things to be taken care of

Templates

icons that need "hspace"

Should get appropriate classes, but an icon-class concept is missing yet.

hardcoded link delimeters

Like [ are not cool anymore. They should be optional. In fact, they should be taken care of by CSS. Does IE support this yet?

hardcoded URLs

Like the ones that lead to tw.o for info about certain features shouldn't be hardcoded, but optional: if they're there at all, and where they lead to.

Intelligent labeling

It's crucial for accessible sites to have an intelligent labeling system. Fieldset and summary and longdescr attributes and whatnot. During the process, some of us (especially beerlounge.de) haven't been so careful and doubled and trippled the same information, like when a header is followed by a table is followed by a form ... it makes little sense to lable all of these with title/summary/legend of the same content. A TikiLabelingGroup shall be formed that developes a concept that takes care of these problems.

white space

I tested big templates like webmail and forum-view. We save between 100 and 500 bytes without whitespace (or by using Smarty's {strip} tag). Unfortunately it appears that {strip} doesn't work if missing page for plugin INCLUDE
is used inbetween. Too bad. Will {strip} have to be applied in every "blind end" template. Seems so. Size-wise we're talking about a few hundred bytes only, but with that new indentation freedom the templates will look and feel much nicer - without impact on rendering. So I'd say we should go for it and put up a law against "strip-less templates" (am I the only one who reads "topless strippers"?). In other news, when indented files get compressed (if GZ enabled) the whitespace shrinks to like almost zero byte anyways.

CSS

class hierarchy

Chunks of template should be grouped by classes. Example: a form is used to let the admin control newsletter settings. The classnames should now follow a certain hierarchy (yet to be found), not based on "how does the chunk look" but based on "what is the chunk there for". Good name: "adminsettings". A wider scope like a surrounding <div> might be named "newsletter". An abbreviation like "admset" is not too cool. Now the form has a one or a bunch of fieldsets. Their classes should be automatically set by a cycling Smarty function. Like this, a theme designer can easily overwrite defaults that are global for certain form elements. He or she would just have to use child selectors, which are widely supported, even by Internet Explorer. So the idea is be to start with a specific class (newsletter) and then get more and more unspecific (adminsettings) until when only the tag is left without class (like <textarea>, it doesn't need a class if we know it's in newsletter - admin - fieldset 2).

tables vs rows vs cells

td-classes should be removed. tr-classes should be standardized - there's hardly another purpose then to alternate row-colors. This should be acheived with a global concept of letting Smarty cycle through rows and give class names like row1 and row2. Theme-admins can now set colors using child selectors like so: table.mytable tr.row1 {foo}
Styling of whole columns would be achieved through selecting the col tags in colgroups. Styling of single cells would be achieved through [http://www.w3.org/TR/REC-CSS2/selector.html#adjacent-selectors|adjacent sibling selectors]. Like this, the less common a styling attempts is, the less common is the browser supporting it.