Constructing the Patio Garden

The concept

This started as a reaction against views that a table was somehow an impediment to the advanced layout and presentation capability available via CSS.

There was no point in placing any emphasis on the styling of non-table elements. No one has doubt that they can styled, whether they are within a table or not. Neither was there much benefit in showing what can be achieved by adding extra mark-up, for example extra s or

s, to a layout table, to provide sufficient "hooks" for CSS to work with. What would that prove?

Therefore, the basic concept was to start with an unadorned layout table, then discover what could be achieved by pushing CSS as far as possible. No extra elements would be added. This would then be an illustration of what can be achieved with layout tables in general. The main concession for this exercise was that every element of the table, including the s, had a unique "id" for CSS to operate upon. Another concession was that only the document from ... must remain unchanged. This would allow extra stylesheets, or the use of scripts, etc, because the aim was to see what could be achieved by pushing tables to the limit.

The frustrations

Apart from the fact that I am not an expert on the application of CSS to tables, the problems I hit were the following, further discussed below:

  1. The table, mark-up and contents, was very restricted. There was no extra mark-up, so the CSS capability was limited.
  2. I hit several browser bugs and non-compliances. These were not well documented on the web, neither were the solutions, if at all.

Restricted mark-up

CSS2 does not separate layout & presentation from mark-up. It doesn't even pretend to. All major features of CSS2 depend on the document tree. Inheritance (by definition!), floating, absolute-positioning, and normal flow for layout down the page, (and its neighbour relative-positioning), are all governed by the document tree.

It is common for practitioners of CSS-positioning, (including myself), to add extra mark-up, such as wrapping, and clearing-

s, etc. We ensure that the wrapping & nesting & sequencing of the top-level elements of the document tree provide the structure & "hooks" for our CSS to operate on. We use our ingenuity to simulate "columns", even though CSS2, unlike table-mark-up, doesn't have columns. We add extra wrapping at other places to ensure that various combinations of elements are treated as entities. (Often, this is actually to make them behave as though we had used a simple table at that point!)

The CSS Zen Garden (X)HTML provides vast amounts of extra mark-up to give ingenious designers the capability they need. This is necessary if it is desired to be able to layout & present pre-given documents in ways that were not pre-determined. CSS2 is not a proper page layout language, and can only work with the cooperation of the mark-up.

I devised the table mark-up used for these exhibits months ago. It doesn't provide any of those "hooks". It is minimalist!

Bugs & non-compliance

Obviously, browsers don't support all the CSS needed for maximum flexibility of tables. (Nor for anything else). As always, hacks & kludges & work-arounds are needed. That is the nature of the web, and different people have different tolerances & constraints. (Some people appear to tolerate hacks in the CSS that they wouldn't tolerate in the HTML. Are they simply old-fashioned people who care less about CSS-quality than about HTML-quality?)

It has taken years to discover a useful set of CSS hacks & kludges & work-arounds to enable those people who know of them to use CSS to replace many of the uses of table-layout. But, it appears that an equivalent set hacks & kludges & work-arounds for layout tables has not yet been discovered.

I feel that I am having to discover bugs & non-compliances & work-arounds for CSS layout of tables for the first time!