Help Me Learn CSS Zen Garden Techniques -- and How to Do CSS/XHTML Mock-Up?
January 8, 2005 8:10 AM   Subscribe

CSSFilter: I'm a long-time Web wonk looking to become a CSS maven - my next gig is the development and implementation of a completely modern, table-less design for a fairly big company.

What learning resources out there (on the Web, in print, or otherwise) are the best for someone looking to master the techniques espoused by places like the CSS Zen Garden? What new tools should I consider using? One thing I'm having trouble with in particular: how does the designer mock up a fully CSS/XHTML design? It seems more counterintuitive than the old process of design -> cut-up into table-based layout.
posted by killdevil to Computers & Internet (20 answers total) 3 users marked this as a favorite
Based on my experience, unless it's a very simple design, a completely table-less design is probably not a good idea. I realize that's standards heresy, but creating a table-less design that works across browsers will entail lots and lots of rigorous testing. It will be more cost-effective to just break down and use a few simple tables. You won't burst into flame.
posted by lodurr at 8:16 AM on January 8, 2005

I seem to be following lodurr around this morning.

This is a painless and easy introduction to doing table-like layout with CSS (it's a presentation from a Seybold conference in 2003.) It offers many print and online tutorial and reference suggestions at the end.

Tools-wise, it would probably behoove you to hand-code your CSS while you're learning, but for everyday use after that, I love me some TopStyle Pro (Bradbury Software.)

As for design - keep doing your wireframes and mockups in whatever tool you are comfortable with. If you decide to do a CSS-based layout after that (and as lodurr observed, there are often good reasons not to) you can still use your designs as a guide.
posted by enrevanche at 8:38 AM on January 8, 2005

A List Apart.
posted by Prince Nez at 8:55 AM on January 8, 2005

Killdevil, trying to do a completely tableless design in CSS is maddening, if you want more than two sections, and don't want fixed sizes on everything. It actually drove me away from designing my own web sites because it was so frustrating to get even simple things that I wanted, and could get so easily with table layouts. I mean, you actually have to use "hacks" to get basic functionality out of CSS positioning. Come on.

Ok, ok. Anyway, a couple of good sites:

1. CSS Vault (general resources)
2. Nemesis Project (a collection of basic layout templates--very useful)
posted by Hildago at 9:09 AM on January 8, 2005

marking up for CSS

posted by nakedcodemonkey at 9:46 AM on January 8, 2005

Response by poster: Nakedcodemonkey, that is a very interesting approach you've linked to. Particularly since I already use Fireworks for mocking things up (though its HTML slicing leaves so much to be desired).
posted by killdevil at 9:57 AM on January 8, 2005

Best answer: I'm only slightly ahead of you, with the same goals. I was familiar with CSS for font stylings, but ignored CSS for positioning due to so many browser compatibility problems. However, I definitely think the time has come to get into the CSS for layout game and I feel I have a lot of catching up to do.

I agree with the idea of handcoding to start with. I believe that unless you understand what the tool is doing for you (such as TopStyle) you are at a disadvantage.

In addition to collecting good CSS information sites, I recommend "deconstructing" others' sites. While fairly simple, this site is a good one to "deconstruct". I deconstruct by viewing the page code and creating a nested outline of the classes and IDs used in the various divs and spans. This gives me a visual layout of what objects are parents to what other objects.

Then you look for the location of the .css style sheet to analyze what each of those classes and IDs actually do. A good site to start doing this with might be this one.

CSS sites that I have marked to use as resources:

w3schools tutorials

rounded box generator

Sensually Styled Definition Lists

CSS Discuss

CSS Play

A Web Standards Primer

The way forward with Web Standards

CSS Rollovers with no preload

CSS Panic Guide:

All CSS Properties:

10 CSS Tricks you may not know:

CSS CheatSheet:

Good explanation of block-level elements, inline elements & replaced elements in CSS:

CSS diagrams:

190 style sheets:

Creating a pullquote with javascript:

CSS float model problem:

Andy Budd's selection of CSS goodness:

CSS code-based navigation:

CSS quick reference:

float layouts:

CSS sanity-saving shortcut:


clearing a float with no structured markup:


Simple tricks for more usable forms:

Common coding problems for html/css:

css layout-o-matic:

a PRINT css primer:

one method of building CSS layouts:

IE css bugs exposed:

Good starter page for teaching CSS:

css cribsheet:

Layouts to use as a basis:

fun with forms: customized input elements:

css templates:
root site:
posted by spock at 10:15 AM on January 8, 2005 [1 favorite]

I agree with lodurr and Hildago on a practical level, and yet... understanding the table-free discipline is something every web developer should do, I think. You may or may not stick with it, but you'll learn so much about browser rendering differences and markup/CSS as a tool that it's worth it no matter what.

I like the link nakedcodemonkey gave. It's actually very similar to the mental process I go through -- though I don't usually write the markup details on another layer in the Fireworks file, it does seem like a good exercise. And when I'm doing pure CSS Positioned layouts, I rarely actually use the Fireworks HTML production feature -- I export slices individually or write images only, and then create my markup by hand.
posted by weston at 10:21 AM on January 8, 2005

I guess I'll just repeat what everyone else seems to be telling you. CSS is best used for what it was designed for: text styles. Strict positioning has always been easiest using plain-jane HTML (provided you're not nesting hundreds of tables). Standards-wise, you'll have to implement various hacks to get your positioning to work cross-browser, while boring tables will work with any browser (including old ones).

Here's another list of all the various CSS attributes.

Introduction to CSS positioning.
posted by Civil_Disobedient at 10:40 AM on January 8, 2005

Wow, spock freaking rocked the links out there. I have to admit, though, I'm a bit surprised no one's pointed to Eric Meyer yet. His site and mailing lists are great and his books are indespensible for newbies and oldbies alike.

killdevil, as to the counterintuitive nature of CSS design, it also helps to consider the semantics of your markup. This can be difficult for design-heavy corporate sties, but for information rich sites, it's very helpful. Structure your div tags so that the markup itself makes sense, then use CSS to style that content. You'll read plenty about separation content from design.

Best of luck, when you start using CSS, you'll wonder how you ever did it the other way!
posted by jimray at 10:45 AM on January 8, 2005

This is the CSS Reference roundup that I like best.

I don't lay out the page and then figure out how to tag it. I tag the page and then figure out how to lay it out. Obviously this usually involves a little extra tagging, and there's a classic design spiral involved, but that's the general idea.

It's worth noting that you can do layouts in CSS that you simply can't do (or aren't worth doing) with tables. It's also worth noting that theoretically speaking it's not hard to do table-like designs in CSS--you can simply display block elements as table cells, getting the best of both familiar table-ish design and structurally correct markup. Of course, IE gags on this, so it's not a practical solution (unless perhaps you use IE7). In fact, 90% of the pain of doing CSS layout is making it play nice with IE, IMO.

However, no less an authority than Eric Meyer has said that using tables for overall layout is OK, so I'm not going to come down too hard on it.
posted by adamrice at 10:52 AM on January 8, 2005

I'm not sure what's a good place to start, but Zeldman's book on the topic is the best intro. Beyond the obvious info, he gives a solid foundation to grow from: how to properly use classes, how to use inheritance, etc. I'll try to think up some good beginner links, but it looks like you already have a lot to work through above. One thing I can't live without is Chris Pedrick's Web Developer Toolbar. It builds in a lot of helpful links and tools, but the View Style Information is the one thing I use 100x a week. Mousing over an element shows its entire inheritance path. Clicking on the item pops up a window that shows all styles applied to the item, what stylesheet they came from (including line#) and which takes precedence.

Now here comes the part where I sorta jump ugly. CSS layouts are practical and possible. You need to define what browsers you support. If you hae to have pixel-perfect layouts in Netscape 4 and IE 4, forget about it. But from your question, it sounds like the client wants a standards-based site and thus probably understands the tradeoffs. Our baseline at work is IE5.x PC and Mac (though we may drop the Mac IE), Gecko browsers and Safari. We neglect Opera and Konqueror because no one's ever complained, but that doesn't mean you should too. It's just our browser support. I'm disappointed by Opera's support CSS implementation, given they have one or both of the creator(s) of CSS working for them. The important thing is to communicate the trade-offs to the client. There may be slight differences, the site may be text-only in older browsers, but the benefits outweigh the costs, especially the next time they want to redesign.

My recent work has been mainly UI designs for products in XHTML+CSS, so it's hard to find sites that haven't been altered by the client since I finished them, but here are a couple: (looks like they dumped a table in the homepage subsequently)

As for the mock-ups, our designers never changed a thing when we stopped using tables. They just give us layered Photoshop files and we cut them up. The only thing you want to be careful about with full CSS sites is scaling. It can be difficult to do "liquid" sites in CSS. And understand the box model/ broken box model issue. Build in Mozilla, force IE6 into standards mode with a proper DOCTYPE (we're lazy anduse XHTML 1.0 Transitional), etc.

Also, break stylesheets up into logical components (the base.css and dom.css I used in the sites above are main site styles that work in NS4 and then overrides for "modern" browsers). When an area of the template starts to take up 50 lines in a mixed stylesheet, consider breaking it into its own sheet. At the risk of tooting my own horn, I'd highly recommend the coding style I used in places sheets like, where children that inherit styles are tabbed in to make that inheritance obvious at a glance. Very helpful for debugging. I suppose that would prevent the use of TopStyle, so it's a trade-off. Don't use the image replacement headers I did for the first site. It's impressive to other developers and accessibility friendly (maybe) but a huge pain in the ass to maintain. Instead, yell at the designers not to use images for navigation or headers.

Use classes sparingly. Whenever possible, just define the styles using selectors. A simplistic example would be to apply a class to a ul and then define the li styles with ul.className li {styles} rather than applying a class to every li in the list.

That's enough. I think 90% of this I wrote in a dead AskMe thread a while back. Yup. I'm in repeats. And it's not even summer yet.
posted by yerfatma at 11:15 AM on January 8, 2005

Yeah, as I entered my list I was wondering where my Eric Meyer link was. This is another link that I should not have left out: little boxes and css beauty.
posted by spock at 1:34 PM on January 8, 2005

Be prepared for about 10x the amount of work. I mean CSS can't even vertically position an image in the middle or bottom of a DIV for crying out loud.

You need to know about these things before you even start designing in photoshop otherwise what you have designed will not even be possible to produce. Creatively stifling but hey, that's progress!
posted by derbs at 2:23 PM on January 8, 2005

It is a new way of thinking, but I think the code is much easier to grok and making changes universally across your web site is much easier (just change a single class rule in your .css and all pages referencing that stylesheet are instantly updated).

derbs: It sounds like you are simply substituting div for td in your mind. A div is what you make it.

Why Tables for Layout is Stupid
posted by spock at 2:53 PM on January 8, 2005

I don't think using CSS for layout has quite gotten to the point where it's a smart, universal replacement for tables. I'm the CSS guru of my IT department, and while I don't claim to be an expert, using a complete CSS design is a lot more work and has enough drawbacks presently to make it inadvisable.

Want to make two different-colored columns where the background color of the shorter column stretches to the height of the taller column? Can't do that without the clever hack of background images! C'mon, that's just nonsense.

But I do think CSS will eventually get there, so start small--style text and paragraphs-- then get into the cumbersome layout.
posted by lychee at 10:26 PM on January 8, 2005

I must admit that it amuses me when those that use table-based layout don't consider the 82 uses of "spacer.gif" in their page a "hack".
posted by spock at 7:54 AM on January 9, 2005

Oh, it's definately a hack, but at least you know it's going to work on all browsers back to 3.whatever.

And you only have to download the spacer.gif once, then it's all cache, baby!
posted by Civil_Disobedient at 9:59 AM on January 9, 2005

You've just hit upon the single main advantage of CSS. Anything you put in your .css file is code that gets cached on the first loading and doesn't have to be repeated over and over in your html.

So, I guess the problem isn't that something is a "hack". It depends on whether it is a hack you've already learned or decided to accept. Those who are learning to think a different way (CSS for layout) are simply not content to use the same things that worked for them in 1998.

If you want to continue to use table layout, feel free. I just don't understand the discouraging comments to somebody who asked the question because they want to learn. Just because somebody doesn't think something can't be done in CSS doesn't mean it can't be done. I recommend CSS-discuss as the place to get good answers to CSS, not ask.mefi. Also this book is great.
posted by spock at 1:37 PM on January 9, 2005

posted by joelf at 9:39 AM on January 10, 2005

« Older Overexposed   |   How do you find a therapist? Newer »
This thread is closed to new comments.