Trillium - CSS - Tables
- 15 November 2007
This is the first of series of posts I hope to be making over the next few weeks about what does/does not work in Trillium and therefore what L&C should/should not try to carry over to the new site…
Today I want to mention a major shortcoming: Trillium produces webpages based on tables, not cascading style sheets. The difference in flexibility and usability is documented
ad nauseam online and so not worth repeating here. (Trillium was of course created when table layouts were all we were doing, but things have changed for the far better.)
While we do use style sheets with Trillium to control small things like background and link colors, they could be used to control so much more. So I lobby a point which seems a no-brainer to me, but still must be mentioned: the new site must be based on style sheets not tables!
Filed Under
Comments
You’ll get no complaint from me.
I’ve been doing XHTML/CSS for three years or more and you might note, while it is the default of this wordpress’s themes, this design is such.
And perhaps here is the best time to talk about why this is important. To the average person, why should this matter? Before we start, it’s important to understand just a few quick terms: “design” is the look-and-feel of the page and “content” is the message — that is any text, visual or auditory element that is the purpose of the page’s existence.
Now, while this style of web design, also known as “web standards,” is now de rigeur, it was hotly debated at its inception and discussed at length. For that reason, I’ll just boil it down to what I consider the most essential point — the separation of presentation (design) from message (content).
When you use tables as a means to allocate page space in web design, you must decide, for example, that the site navigation elements are going to be in this table cell, the main page content in this other one, and sidebar content in yet another. And while the table structure is very flexible in terms of cell size or styling, it is not when it comes to order. You cannot move one cell in front of another without manipulating the page itself, and the content it contains. If you want your navigation to appear in the page above the main body text, it must appear before it in the actual source of the web page. (All the stuff you don’t often see.)
Further, because of the nature of allocating content to cells, you must segment the content in what are otherwise arbitrary means, simply based on your desired presentation needs. If you, or a visitor to your page want to alter the presentation to suit another need, you must physically alter its structure. For example, to provide a print-version of a page, where you undoubtedly wouldn’t need navigation elements (hard to follow paper links), you would have to create a different page entirely, without the navigation or other elements deemed unnecessary, perhaps reversing colors, etc. to provide a usable printout.
Now imagine, what if the design had the ability to control all the visual placement as well as the look, and the content was no longer pre-allocated to arbitrary containers, but arranged in a semantically- and message-appropriate order? (OK, too techie, hang on…)
Beneath the visual, web pages are all really just text files setup in a specific manner, with tags indicating different kinds of content. And in the table world, you’d contain everything with <table> tags (among several others), and you might have to list your navigation first, because that’s the order it would need to be to be on the page in the right place.
But with xHTML/CSS, you instead get to contain content with more appropriate tags better related to what the content actually is and what’s more important, you arrange the content with no thought about design. Design is separate. So, if you think your body content is the most important thing on the page, you can list it in the document first, with the navigation coming second. Then, the design parameters contained in the CSS design file are assigned to the document elements, and tell then where they should appear, if at all, and how they should look.
This means that we never need to touch the content of any page to alter the design. (And further, we can alter an entire site’s design at once from a series of core files.) So, returning to our earlier web page print-version example, with xHTML/CSS, we’d simply apply a different CSS design, setup for printing, to the original web page, and in doing that, we would simply hide the navigation, alter colors, etc.
Taking this one step further, we can then consider repurposing the page content into different formats entirely, since it is content only. We could then think of outputting the page as pdf, or a word document, or something else should we desire it. (I am greatly oversimpifying here, but this separation of presentation, or design, from message, or content is what makes this a viable thought.
Need a visual of the capabilities? Visit the now classic site that changed my mind: CSS Zen Garden. Simply choose an alternate CSS design file from the list (at right, when you first visit) and it will show you the exact same content with a different CSS design file applied.
Well said ![]()
[…] The design is table-less, and flex-width (between 760 - 960 pixels), which allows greater flexibility of design. See my blog post regarding the importance of this. […]
![The WhiteBoard [home]](http://www.lclark.edu/global/images/transparent.gif)




