History: 508ThemeDev

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.

XHTML

• <table> gets some new tags:
  • colgroup
  • thead
  • th
  • tfoot (under discussion)
  • tbody (where no thead/tfoot its needed, use tbody anyway)
  • summary (only tables used for data-listings)

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

• kill:
  • <div align="center">
  • class="tableheading"
  • class="normal"
  • border="0" in <img> but leave it for tables (tables are taken care of later)
  • class="button"
  • 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)

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

• 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 ...". Maybe one day, when all tags are standardized like that, they can be remotely configured. * all images get alt="", but no title attribute
• use attr="value" instead of attr='value'

CSS (to be discussed)

• shorthand (never vs partially vs always)

in other news

icons that need hspace

Should get appropriate classes, but an icon-class concept is missing yet. Until then hspace and vspace stay.

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.

classes: 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.

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. I've never noticed that before, but I couldn't get {strip} working when applied to header.tpl and footer.tpl. First I thought it might be a bug in this Smarty version. {strip} has had some quirks in older versions, I read so in their forum, but then I tested it with another project ... missing page for plugin INCLUDE
does break {strip}. 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 in theme musus, 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.