Thu. Sep 06, 2001
Gulag CSS
Gulag CSS – I’ve witnessed much pain and suffering lately, and I fear some of it may be my fault. I built a web site using Cascading Style Sheets for compliant browsers (ala the Web Standards Project), and while under the influence of marathon code binges, I may have evangelized a bit about the sweet life at Gulag CSS.
I’ve since witnessed a few friends pass through the Gulag Gates, perhaps influenced by my glowing description of this Lesser Hell, and, well, I fear I may end up getting sued for their pain and suffering. So let’s get busy with some damage control.
Robert is moving his work to his first domain. For the past five or six months, he’s been working hard to absorb the wide spectrum of components that are used in web authoring, taking classes, and building on what he’s learned. While, like all of us, he’s stumbled at times with so much to learn, I think he’s done pretty well (my wrinkled brain vaguely recalls being in about the same place in April, ’96, and look at the aesthetic mess I came up with).
Then he took on CSS: ”For the past two days as I have struggled to work on learning Cascading Style Sheets, it has been very easy to lose my cool” [...] ”I think that I am going to keep things simple and just use templates in the mean time.” These are the temperate sounds of a man who’s been steamin’ over his keyboard.
I say this with clear conscience as One Of The Guilty (now semi-reformed), but sometimes web authors react to validation like a lost man reacts to the concept of asking for directions. After an error occurs, we’d rather keep blundering, changing things that aren’t broken, and refreshing ten gazillion times in hope of improvement, rather than simply take that initial error to an HTML or CSS validator. It will quickly and objectively tell you, ”you blundering idiot, you foolishly left off one closing semi-colon in your style declaration, and no self respecting browser will render a thing that follows. Go fix it before everyone realizes what an Imposter you are.” Now wasn’t that simple?
In Robert’s case, in addition to validation, it took a twist of thinking; instead of floating the menu left, we floated the content right. Now all compliant browsers, and Robert, are happy campers: ”It might be unpleasant at first, but then you look at what you have learned.” That goes for me as well, as this exercise resulted in me ruminating (cocktail napkin draft) about a CSS future for this domain.
OK, there’s one happy ending. Let’s move on to Jim, a respected web veteran who’s been publishing a long time, who’s got a cool new button/banner to promote his site, and who writes great toilet stories (among other things) with classic lines like ”That toe, sadly, has no name.” (Note: toe since identified and tagged)
When Jim showed up at Gulag CSS, he really tried to like it. ”I’m a little fuzzy on the whole good/bad thing with using tables for layouts. I never had a problem with them. But, apparently, they’re evil. I don’t like evil. Not even a little.” Tables do have proper uses, but they can be somewhat evil. They can cause a slowing of page rendering in some circumstances, and they definitely bloat your page code. I usually see about a 20% reduction in code when converting from a table based layout to CSS, even more if you’re also removing font tags. Plus, for the author, the code is so much easier to read and grasp quickly, without sorting through three levels of nested tables, cells, colspans, and font tags. But there are more reasons to use it.
”For starters, CSS separates content from design. Yeh, I don’t quite know what that means either. I think it means that my content (the words part of my site) is not tangled around all sorts of positioning elements like table rows and frame sets.” Yes, the presentation aspects are removed from the HTML document itself, so that changing the seperate CSS document can automatically update the look and layout of many web pages. Or, one set of content can be rendered in multiple ways, like this, or like the 4th of July, or Father’s Day, or simply a low bandwidth version (there are indeed a few HTML changes on those pages, but the majority of it is CSS alterations). If you have an ounce of control freak in you, once you grasp the power of it, it’s nearly impossible to resist.
”It’s the future of the web. So I figure: Freely learn it now or be forced to learn it tomorrow.” Yes, it’s a bit of Web Darwinism. We’ve reach a point where the percentage of non-compliant browsers is low enough to make this approach a valid one, and that number is only going to continue to dwindle. The future is here, there’s just a few remnants of the past hanging on. It appeared Jim had been to the mountain top.
Then, Sisyphus let the rock slide back down the hill: ”I didn’t like what the CSS was doing to my pages.” Victim… (often a sure way to goad a man into beating his head against the brick wall a few more times). ”I’m sure it’s the wave of the future. But, jeez, it’s like learning a whole new language. And, with CSS as a layout tool, I’m a clumsy foreigner trying to get a cab ride to the airport and I wind up buying two sows and a basket of eggs.”
Hehe, I can empathize. I still feel that way myself much of the time. My forehead has become somewhat calloused from repeated contact with the bricks (Note for later, ask lawyer: can I sue the W3C for repetitive stress injury?). And I have to admit, in some ways, I cheated. When I moved into Gulag CSS, I was starting from scratch. PixelPile.org was built from the ground up with this architecture in mind.
When I look at converting my existing personal site (beyond the CSS weblog version I’ve done), and its hundreds of documents, well, I think tables aren’t quite so evil. At least I must not, as I use so many of them. It’s shameful, and I will do penance by converting my domain entirely over to compliant code, but not today. Maybe by Thanksgiving.
Once I’ve done that, this evangelist will be insufferable, so enjoy your respite until then. But don’t go over to the Other Side. There lies more years of hell for web authors worldwide.
And utilize these fine CSS resources when your forehead gets sore:
Web Design Group CSS and W3 Schools CSS – A couple of good basic primers and starting points.
CSS Layout Technologies – Eric Costello’s fine repository of CSS layouts.
The Layour Reservoir – Another collection of CSS layouts, from Blue Robot.
W3C CSS Validation Service – Go ahead. Ask for directions.
Published 10:27AM, Thu, Sep 06 2001
Category: CSS
Previous: «« Never Ending Amazement ««
Next: »» Chinese Chair Race »»
Peanut Gallery
I have to admit I'm still a table loyalist. Yeah, well, you still capitalize your HTML, too. Dinosaur. From a pure layout standpoint, there are still many things that are much easier to do with tables than with CSS I agree. I recently read a tutorial on how you can put thumbnail images on a page using only CSS, complete with captions, and they will reposition themselves based on browser width. They made it look so easy. Trust me, it isn't, in all situations. Tables still rule for presenting tabular data, and I think you can make a stong argument that thumbnail images with captions are just that. If 100% CSS-usage could do everything layout-wise, and degrade nicely on every browser currently in use, I'd be glad to go that route - but that's just not the case. No, you can't quite do it all. But you can do 95-98%. And as for degrading, I've opened myself up to a new definition of that term. For example, if you view PixelPile.org in Netscape 4.x (as a whopping 1% of our visitors have), it's quite readable, you can easily navigate, and every scrap of content is presented. It looks like 1994 (which some would translate to, "it looks like Hell"), but, in my new opinion, it "degrades nicely." In fact, I think it even would meet the accessibility requirements for government web sites, as even the Lynx Viewer doesn't totally barf on parsing the page. It's certainly not for every site, and as you point out, one of the great things about web design is choice. If having very similar presentations for all visitors is a priority, like for a business, then 100% CSS is not a total solution. It's a 95% solution, which for that type of site, may not be enough. But in a year it will be a 98% solution, and in two, 99.5%. When XML takes over web databases, as it will rapidly over the next 6-18 months, your non-compliant browser will be the equivalent of driving a moped on the interstate - you will not be able to access even a fraction of the benefit the system provides.
You're trying to goad me back into using CSS for layout again, aren't you? It might work. My site is very, very simple. One table, straight down the middle. The CSS should be horribly simple. And it is. But I couldn't squeeze out of it what I wanted. I panicked. I put the table back -- but all the attributes (except for the centering) are CSS controlled. Just like Noah's site is designed to show his photos, mine is designed to show my writing. My Grandma also reads JimFormation. She uses an old WebTV browser. I have to think about Grandma -- which is why I never really got into much fancy stuff on my site. Anyway, thanks for using me as an example. I got a real kick out of it. Read it twice. And re-read some of my stuff. And I learned some stuff.
Yeah, I figured that "victim" comment might push your buttons. But you are indeed a good example, even in your CSS regression. When you originally switched over to CSS, I noted immediately the different look on the front page. When you "switched back," going back to a table for layout, I did not notice the change visually. In fact, I was starting up writing this entry before I found your later post about what a backslider you are. The fact remains, my eyeballs didn't see a difference. So even though you may have 'regressed" structurally, the presentation via CSS attributes remains. In my book, a victory for CSS.



I have to admit I'm still a table loyalist. I started working on a design for a new project recently, and I tried - really, I did - to go the all-CSS, 100%-validating, tableless route... and it just wasn't working out. From a pure layout standpoint, there are still many things that are much easier to do with tables than with CSS (and vice versa) - and a good table layout will still look as the designer intended it to look on a wider range of browsers (Netscape 4.x anyone?), which is important when you're trying to design something with both semi-complex aesthetics *and* maximum browser compatibility in mind. (No new browser's ever going to come out without table support and break 90% of the web, anyway.) If 100% CSS-usage could do everything layout-wise, and degrade nicely on every browser currently in use, I'd be glad to go that route - but that's just not the case. I don't think it's an either-or proposition, anyway; a good designer should still know how to make clean and effective use of both. (Even Zeldman still uses tables.) In any case, having coded HTML by hand since 1995, tables are ingrained in me enough that they're still easier & more comfortable for me to use than CSS (plus, I store the layout in SHTML include files, so I still only have to change one file to tweak the appearance of my whole site). Part of the beauty of webdesign is that there's rarely one best way to do everything - do what works and feels best for you, make sure it works well (or at least works at all) on the widest range of browsers you can, and as in all things, in the end listen to your own heart above all else. (And, of course, thank you for the incredibly kind previous entry... I'm more honoured than I can say.)