Tiki_110_Theme_Ideas

(See: 110 Theme Project)

My idea is that there should be two basic methods for Tiki themes:

1. A no-tables liquid layout method, to implement web design best practices, and
2. A "table-assisted" layout method (with a couple of basic page-framing tables) for special design needs, mainly to support "fixed-width" themes in all browsers (i.e., IE).

Actually these two methods would differ only in a few template files (tiki.tpl and maybe header.tpl). In the template files in general, tables used for layout should be replaced with divs and uls, etc. (as in modules and within the center column and top and bottom bars, etc.) as much as possible.

Of course there can only be one templates/tiki.tpl, so a decision would have to be made about which template type to use as default. My opinion is that this should be the no-tables liquid layout.

I may have overlooked something or might just plain be wrong about something, so welcome any feedback anyone has.

Liquid layout

For the liquid layout, luci's *litecss (cache) or something based on it can be used, and for the "table-assisted" layout, a variation of the current default tiki.tpl can be used.

First, reasons to support the liquid layout method:

• It is generally considered the best practice these days.
• It enables "semantic" design — i.e., markup has meaning regarding page content rather than appearance.
• It promotes accessibility.
• Code tends to be reduced.
• Main content is above the side columns in the page source.
• The trend in web design is clearly this direction.

A few possible downsides:

• Some page designs don't work well in all browsers (i.e., IE).
• This method may be more vulnerable to the display breaking due to faulty code by page authors.
• This method (especially the floats needed) may be less familiar to theme authors, but some good docs can help here.

I think the positives outweigh the negatives so suggest going to this method for the default Tiki theme and advocating it for new themes.

A few other points regarding the no-tables method specifically for Tiki:

• This method works fine in all browsers for full-page layouts which have been the Tiki norm.
• Tiki's own *litecss is possibly a unique method to successfully produce three-column, source-ordered, liquid layouts that work in all major browsers for dynamic pages of varying content widths.
• I've reduced tables for layout (such as in modules) in most of my new Tiki themes, so this work can be adapted.

"Table-assisted" layout

But the *litecss method can't handle every design possibility, primarily because of problems caused by the IE browsers Update: Table-assisted litecss. For this reason I think it's good to also maintain a table-assisted method.



Tiki's current default tiki.tpl uses a table (tiki-midtbl) to contain the three content columns. Maybe ironically, I would like to expand the table in this template to make it full-width and height in the page body, and to add some new cells. There are a few reasons for this:

• In IE, "width: 100%" divs don't resize (widen) to match the new page width when new center-column content is loaded. This means the header and footer stay at their original widths (the original viewport width) even if a wide table or image pushes tiki-mid wider.
• Presently the Tiki page is a stack of divs (siteheader, tiki-main and tiki-bot) with no element containing all of them, which isn't sufficient for themes with a page-framing border of some kind.
• Also, for themes that have some visual/graphic separation between the viewport top and the header area (i.e., tiki-top_bar or site_header), especially imposed by a framing table, it doesn't work to have tiki-site_header.tpl included from header.tpl. At least for this template method, the SI include has to be moved to tiki.tpl.
  
  
  As an aside, I wonder why the include statement for site-identity_header.tpl is in header.tpl at all. What is the rationale for the break point between header.tpl and tiki.tpl?

In any case, for "fixed-width" designs such as Kubrick, it is necessary to move the SI include to tiki.tpl.

Another case in which table layout is needed, or at least arguably less kludgy than the no-table alternatives (IMHO) is to get full-height column backgrounds or borders.

Again, this is what I recall from my experience of trying to get no-tables designs to work with Tiki, but please comment if I have overlooked something or if you have other information on this.

Some details regarding liquid layout

[+]

Timeline

• About the Branch 110 rc release

For the first 1.10 release, if the goal is to get it out as soon as possible, the current templates should be used. The plan is to have several new themes that use the default templates. In other words, no dramatic change in template construction for the first 1.10 release.

• Transition opportunity

But because anyone who has an existing Tiki with customized templates will have to revise them for 1.10 anyway, the transition to 1.10 is a good time to make general changes in the themes/templates. Also, to make a big change such as theme methods, this upgrade time is a good opportunity. So as soon as possible in the branch 1.10 process, it would be good to decide on the path and start making the needed changes.

• Accessibility and validation

At the same time, when looking at how to improve theme files, we should try to upgrade Tiki's accessibility (http://www.w3.org/WAI/ (cache)) and overall compliance validation.

---