ArticlesCSS Principles
For the last twelve months, I have been trying to toe the party line when it comes to Cascading Style Sheets.
- Tables are our enemies.
- Div and span are allies and friends.
- Content shall never be mixed with formatting.
- Animals shall never sleep in beds.
Err.. sorry, got distracted. Where was I?
I understand the principles behind the stance that you should separate content from the style, but frankly, I am having a little bit of difficulty with the practice.
CSS Maturity
I think the main problem is I adopted too early. CSS and the browsers need another year or two of maturity before CSS is ready for the real-world web-sites.
CSS Maturity is not actually the topic I wanted to discuss today.
Instead, I am trying to work out what the party line is on the formatting of tabular data.
When to Use Tables
I understand that it is actually correct to use the <table> tag to format tabular data as a table.
Roger Johansson explains this clearly in his tutorial on appropriate use of HTML tables. This tutorial revealed to me that HTML tables actually have quite a lot happening behind the covers, including some tricky accessibility options.
How to Format Tables
Where I get stuck is figuring out how to make my tables look good.
My first thought was that I would define a “house” style for tables in my style sheet. It would ensure that the borders were colour-coordinated with the rest of the site. It would ensure that the font choices matched the appropriate heading levels. All of the tables would have a common feel.
However, I got stuck at the first gate: text-align.
A: It depends: Large Integers look best right-aligned. Short strings look best centered. Longer (especially multi-line) strings look better left aligned. Full-justification is rarely called for in the small space available in a table.
So, I can’t make an overall style decision – it depends on the content type. It’s not just limited to alignment: borders, padding, caption position… the list goes on.
The answer would appear to be class tags.
I could either constantly edit my stylesheet to handle every data type that I am ever use in my tables (e.g. class="Name", class="Reservoir Volume (Megalitres)") and add it to my stylesheet. Ugh! Editing your stylesheet shouldn’t be a day-to-day operation.
I could indicate in the class how I want to format it (e.g. class="Left-Justified") but that is just back to the bad old days of including formatting information in with the content.
I could add an embedded (or additional) stylesheet for each new table. That has two problems: style-sheets being edited daily, and a need to add new tags in the <head> section of the HTML. Along with the general push to separate content from formatting, many architectures (including WordPress, FrontPage, etc.) are keeping the <head> out the way of the day-to-day content contributors.
Most recently, I resorted to an inline stylesheet. Every tag told the browser how to format it. It is a deprecated way of doing things, and rightly so, but I had a deadline, and I threw up my hands when I realised I had just wasted yet another 30 minutes on fighting with CSS.
I am open to suggestions here – especially those that actually deliver on the promise of allowing me to get the formatting right just once, and then focus on the content after that.
Comment by Aristotle Pagaltzis on February 12, 2006
An minor point first off:
class="Reservoir Volume (Megalitres)"won’t do what you think. The value ofclassis actually a whitespace-separated list of class names. So in your example you’d be applying the classReservoir, the classVolume, and, well, classes may not contain parens, so the third string would be thrown away as junk.Anyway; back to the subject at hand. The thing to realise is:
Class names convey no semantics.
The goal of choosing class names is to group together styling options in such a way that when you want to make a change to the presentation of your documents, you will not need to edit the markup, only the stylesheet. You should not have to edit markup to change which classes are applied to which elements in order to be able to achieve whatever it is you are trying to do.
Avoiding presentational class names is therefore not an end in itself. It is only a good rule of thumb, so that you won’t do things like
style="bold red size-5", which would require you to change the markup in order to change the presentation.For tables, then, the granularity of names should be roughly between the examples you gave:
numeric(right-aligned),symbol(centered),multiparagraph(justified, smaller, some padding), etc. Think “data types.â€Comment by Julian on March 11, 2006
Aristotle,
Thanks for the correction re: whitespace.
Thanks also for the recommendation regarding granularity.
You’ve given three good examples of data-types I might need. I’ve been trying to think ahead of all the others I might need in the future. It occurs to me that I don’t have special needs here. My types are likely to be the same as the next person. Has anyone produced a good master list to copy? I haven’t found any.
Comment by Julian on March 11, 2006
On a related note, Sunny at the USS Quad Damage makes a interesting argument.
What I took from this article was that an appropriate choice of style can reflect and enhance the content. However, that introduces a (one-way) dependency:
I see this argument as having some impact here. The data in the table is (sic) independent of the stylesheet. However, the choice of presentation depends on the nature of the data in the table. I’m trying to work out how to include the right meta-data in the table that avoids making the dependency go the other way…. I think.
Comment by Aristotle Pagaltzis on March 15, 2006
Yep, exactly. That’s the essence of it.