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
<table>
gets some new tags:
colgroup
thead
th
tfoot
(under discussion)
tbody
summary
(only tables used for data-listings)
<form>
gets:
<fieldset>
<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"
td class="heading"
to th
(without the class)
{* comment *}
. In fact, I vote for a construct like this: {* <!-- comment --> *}
a class="link" href="...
)
title=""
that start (ideally) with something like "Click here to ..."
alt=""
, but no title attribute
attr="value"
instead of attr='value'
...page... Wiki page pagination has not been enabled.
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.
Should get appropriate classes, but an icon-class concept is missing yet.
Like [ are not cool anymore. They should be optional. In fact, they should be taken care of by CSS. Does IE support this yet?
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.
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.
{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.
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).
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.
1) |
Tiki birthday |
2) |
17 Oct 2024 14:00 GMT-0000
Tiki Roundtable Meeting |
3) |
21 Nov 2024 14:00 GMT-0000
Tiki Roundtable Meeting |
4) |
19 Dec 2024 14:00 GMT-0000
Tiki Roundtable Meeting |