Is it really worth the effort to learn CSS and ditch table-based layouts?

January 20, 2004 10:55 PM

I'm about to design one or more sites I may need to maintain for some time to come. I've always used nested tables and HTML 3 tags to get the job done, but nowadays, CSS seems to be all the rage. I can appreciate some of the advantages it offers [more inside] but given all the questions I've heard about "How can I do XYZ in CSS?" and miscellaneous browser compatibility snafus, I'm wondering whether it's really worth the effort to learn CSS and change all my habits. Convince me? I'm not looking for tutorials or help getting started, I'm looking for arguments in favor of learning the standard, reasons why my life will be easier after doing so. Thanks in advance!

When CSS was first getting off the ground, its appeal was changing stylistic elements throughout an entire site from a central location. But some years later, I have never found myself in a situation where I've needed to do that. I can perhaps see myself using it in place of the font tag, because it's structurally more elegant, but what else?

At this point in time, any multi-page site is probably managed on some sort of template basis, be it through ASP, PHP, or even something like Blogger or DreamWeaver. The hassle of republishing all my Blogger archives under a new template is nothing compared to (what appears to be) the significant challenge of learning CSS. Am I missing some key benefit that makes it all worthwile? If so I'd really like to know.

Bear in mind that I'm really comfortable hand-coding in old-fashioned html, and it took me some time to get there.

posted by scarabic to computers & internet (16 comments total)

scarabic, the short answer is that if you do take the trouble to learn CSS thoroughly -- including the concepts of CSS positioning and the black art of getting around browser bugs -- you'll find yourself with a fuller arsenal of tools for building cleaner, more easily maintainable code. In some cases, more quickly, too.

Example: about a week and a half ago, I found myself coding this site. You'll notice images that float to the right of content area headers on a number of pages like that. When I was given the design of the site to convert, those images actually sat all the way across the content area. This wasn't great, and the client saw it and didn't like it. He asked if we could change the images so they were only half as wide and floated right and had some kind of border. Because I'd set up the page carefully using CSS, I added the following to the master style sheet:

.content img {
height: 100px;
border: 1px solid black;
float: right;
}

And it was done across every page in the site. 1 minute of work, versus at least a half an hour where I would have had to resize each image, change align="right" and border="1" on every image tag.

OK, you could have done that with a well-thought-out template system, so another example... on my quasi-webnotebook blog thing there's the border around "like a sleepy golden storm" that I did using nested table markup before I knew better. That mess is:


<table width="310" cellspacing="0" cellpadding="1" border="0">
<tr><td bgcolor="#444444">
<table width="100%" cellspacing="0" cellpadding="5" border="0">
<tr><td bgcolor="#FFFFFF" valign="middle" align="center">
<font size="-1" class="Narrative">like a sleepy golden storm</font>
<img src="../img/pixel.gif" width="1" height="37" align="middle">
</td></tr>
</table>
</td></tr>
</table>

vs what could have been something like:

<div style="padding: 1em 0; text-align: center; width: 310px;">like a sleepy golden storm</div>

It's easier on the browser to render, it's easier on the coder to code.

There are also some benefits having to do with semantic markup. It becomes easier to make your site accessible to odd browsers (like lynx or stuff used by those with disabilities), and more easily parsed by very stupid entities like machines that only have algorithms and heuristics a programmer gave them for brains. So automated extraction of data, in theory, becomes easier.

But I'd also say: do not drink the CSS kool aid -- don't treat CSS and semantic markup like a religion. Treat them like a discipline while you're learning them, but in day-to-day use, they should be just another tool in the box. I say that because last year I wasted a lot of time trying to get perfect XHTML transitional stuff working for clients who, when it came down to it, just didn't care, because they saw HTML documents as visual presentations, not semantic documents. So I wasted a lot of time that could have been better spent playing the guitar, writing music, talking to friends, and diluted my fee over a larger number of hours than the projects should have taken. And made the project late.... anyway, I won't go to much on with that, because it's borderline advocacy, but I do want to point to an article in progress I'm writing about it (any feedback appreciated).

The final benefit to all this, though, is that I think there's a strong personal benefit from the intellectual exercise of being able to see and understand a document from a semantic standpoint -- much in the same way there is from learning algebra. Even if you only use it rarely, you learn to think in a different way that can be remarkably useful on occasion. So I say learning CSS/XHTML is good for the brain , and maybe the soul. : ) "Geometry will draw the soul towards truth."
posted by weston at 11:37 PM on January 20, 2004

Great thoughts, weston, including your article. Can you explain your usage of the word "semantic" for me? I think that this has come to mean "modular with respect to data/content" recently, but I'm not quite understanding something. Thanks!
posted by scarabic at 11:52 PM on January 20, 2004

I love AskMe. Excellent post weston. Fantastic!
posted by Witty at 11:56 PM on January 20, 2004

I'm just learning CSS little by little as I go along, and generally I find it just a much more elegant and satisfying thing (in addition to the convenience of being able to change styles across the board with a linked stylesheet), but when it comes to positioning, some things just make me cry. The difficulty (or impossibility) of centering elements, especially when you want them to be centered in relation to the page, whatever size the page might be in whatever browser window size or resolution it's rendering in is just awful. It seems that CSS positioning works very well if you give most things absolute widths/heights, but gets to be a real bear if you want your layout to be dynamic in the old html sense. This also seems to me to be a reason that we see so many CSS layouts looking so similar. CSS is great, but it falls down in a few critical areas, and I'm not ready to sacrifice a layout I really like to its limitations just yet.
posted by taz at 12:41 AM on January 21, 2004

I think "semantic" in relationship to HTML/CSS relates to the use of the standard HTML 4.0 tags (e.g. P, UL/LI, H1) to define the structure of the page without concern for the display side of things (e.g. worrying about getting pixel-perfect layouts) -- that is, defining what each part of the page is, rather than how it looks.

The example Zeldman gives in his excellent-ish book is a screen reader (that is, software which reads out a webpage to a blind user), and how it uses these tags which indicate lists and emphasis (which explains why EM is preferable to B, since "bold" means nothing to a non-visual browser) to actually impart an idea of how the page should actually be read.

Of course, with "normal" browsers, you'd be able to include a stylesheet that would make H1 text 8pt pink on a red background, but the semantic structure would still be there.

The antithesis of this approach, but one that still uses CSS, would be using a bunch of DIV tags -- which would make it impossible for a screen reader to divulge the page structure.

He also suggests that search engines of the future (and perhaps even the present) may favour results which make semantic sense, rather than just have the words you're looking for in the page.

I actually found this approach a really easy way of marking a page up with CSS recently -- I started with a basic page that had all the content arranged correctly on a semantic level, and then progressively added display-level information which transformed it into something quite flash.
posted by John Shaft at 12:44 AM on January 21, 2004

I designed sites a lot like you do, and I think that CSS has made my work so much easier. You can change things throughout the entire site so quickly and easily, and, after having spent several hours changing over <font> tags, the five seconds it takes to change font-family is just fantastic.

Start off slow. Use CSS to get rid of your <font> tags and all the stuff you put in the <body> tag. Play with those until you think you know what's going on. Read the sites that are out there to see what you can do with other bits of CSS. Experiment. But always take it slow -- the client doesn't notice that you've made something out of nested tables, s/he just notices that it's done.

You'll figure it out. And then you'll be the one here telling people how easy it is.
posted by Katemonkey at 12:55 AM on January 21, 2004

Just as a side point, if you are really using HTML3 then a lot of what you are using is being depreciated, partly because it's buggy across browsers and partly because it makes access more difficult for diabled visitors. Oh, and because if they didn't change the specs the w3c would get very bored and start planning laser beams on the moon.
posted by twine42 at 2:28 AM on January 21, 2004

the big problem area still seems to be multicolumn layouts. and there's this big taboo about using tables. yet imho tables work fine in many cases.

i think the answer is that you need to learn css because it's another tool - it helps you separate concerns which makes your code cleaner. but it's *just* a tool, not a doctrine, and not always the best one (maybe i'm arguing against a straw man, but on the tables issue it seems to have become almost an unwritten law).

also, with current cms systems, templates, xhtml, and support for xml in programming, i don't think css should be used to separate content from presentation (ie content (text) + structure (html) in one file, presentation (css) in another). content shouldn't be in the html. so you have three "files" - content, structure and presentation. with content out of the way it's less clear what the difference is between structure and presentation ("page structure", since there will also be "content structure").

that last para is maybe confused. i'm saying that css seems to have been largely motivated by a need to solve a problem that can be better solved in other ways.

disclaimer - i'm not a web designer, but a programmer.
posted by andrew cooke at 2:41 AM on January 21, 2004

i'm saying that css seems to have been largely motivated by a need to solve a problem that can be better solved in other ways.

This assumes that normal browser presentation is the ultimate and only use for the content you're putting on the web. Using a scripting language template gives you much of the benefit of CSS, but it can never make table-based content easy for screen readers or allow the page to be queried like it was part of an XML database. To me, the goal of the semantic web is to ensure content is provided in a standard way (regardless of how it looks in a web browser) so that others can use it in ways you never imagined.
posted by yerfatma at 5:10 AM on January 21, 2004

I wasted a lot of time trying to get perfect XHTML transitional stuff working for clients who, when it came down to it, just didn't care, because they saw HTML documents as visual presentations, not semantic documents

Sorry Weston, you're saying it's a waste of time writing valid code for clients that don't appreciate it? You can't expect every client to know the ins and outs of the benefits of code validity. Surely it's worth taking a little time to explain exactly why valid code is important, and if they don't get it, hell, do it anyway: they're paying you to be the web know it all (unless they specifically asked for quick, cheap and easy).

Scarabic, you're going to save yourself a lot of time getting CSS under your belt in the long run. Perhaps you don't find nested tables the headache I used to, but since switching to XHTML/CSS-based sites (er, that's not an invitation to go and validate anything on my profile - I'm comfortable with my hypocrisy ;) I've found that it is easier to create websites, and, perhaps more crucially, due to the separation of content from design it's much much easier to modify either the content or design, either in a small way, or completely.

If you're concerned with your sites working properly across browsers in the future, then valid code is going to be important, and this will be much easier to achieve with CSS.

In short: CSS is your friend, and, I'd argue, more fundamental than "just another tool".

disclaimer - i'm not a web designer, nor a programmer, but a silly monkey.
posted by nthdegx at 5:11 AM on January 21, 2004

if we're "concerned about the future" we want content totally separate from any presentation. including html. when (if!) we finally get a client technology that really does need a different presentation, we won't be trapped with css (although it would be an option if it turned out that css has guessed the future correctly).

for example - what about site structure? maybe different client devices will require different site structures? css doesn't help there, but if content is separate from html then we can accomodate such a shift.

yes, this is all completely at odds with the semantic web (at least, a semantic web based on parsing html). the current model forces you to use html to structure your content - something it wasn't designed to do (it was designed to structure pages, not ideas). one future solution might store data as xml with an appropriate (custom) dtd and provided transforms (xsl?) for appropriate clients. even then, it's not clear how to solve the problem of changing site structure. at the moment everything is a disorganized mess. :o(
posted by andrew cooke at 5:31 AM on January 21, 2004

Most people's difficulties with CSS are due to either bugs with browsers (which are the browsers' fault, not CSS), or that the've forgotten that table-based layouts can be quirky or illogical too. (Leaving out the closing TD tags does different things in different browsers, some browsers need a nonbreaking space--or a 1-pixel transparent GIF-- to display widths correctly.)

Adaptive Path's The Business Value of Web Standards outlines other benefits, including reduced download time and lower bandwidth costs.

The difficulty (or impossibility) of centering elements

• BlueRobot's Centering: Auto-width Margins is pretty easy
• Max Design (which has some excellent CSS tutorials) CSS Centering - fun for all!
• The W3C's Centering Things has some simple tips, including vertical centering
• Web Page Design for Designers' Vertical Centering with CSS has a fuller description

we see so many CSS layouts looking so similar

CSS Zen Garden has 75 (and counting) beautiful, unique CSS designs
posted by kirkaracha at 6:11 AM on January 21, 2004

I've used those tips before, kirkaracha for certain things, but I have a situation where I'm using percentages for what you could call headers and footers, with the text centering in the middle of the content area - and I haven't had success trying to position something 50% from the top when it's in an area in which the height is defined as a percentage.

CSS Zen Garden does have fantastic designs, and believe me, I'm not arguing against CSS positioning, I just feel that when you want to do something relatively simply that CSS won't allow you to do, why use it?
posted by taz at 11:41 AM on January 21, 2004

er... why use it for that particular layout, in other words.
posted by taz at 11:43 AM on January 21, 2004

These are fantastic and balanced responses, everyone!
posted by scarabic at 12:57 PM on January 21, 2004

one future solution might store data as xml with an appropriate (custom) dtd and provided transforms (xsl?) for appropriate clients. even then, it's not clear how to solve the problem of changing site structure. at the moment everything is a disorganized mess. :o(

Yeah, the semantic web is about the result and to abstract from that involves having a good publishing cycle and the way that's going is xml/xslt/xsl-fo/xml pipelines which lends itself toward software like Apache Cocoon.
posted by holloway at 4:23 PM on January 21, 2004