No more fuzzy math

October 8, 2001

In a perfect world, where browser manufacturers didn’t publish bug-ridden trash, where Web authoring tools always generated compliant markup, and where the Document Object Model reined supreme, maybe we wouldn’t need to read W3C specs. We could just design it as we see it, just as Tim Berners-Lee originally intended. And if sometimes we did have to read the spec, it would be easy to understand what the W3C meant. You just wouldn’t have to worry about the internals.

No such luck. Even some new browsers have truck-sized bugs, GoLive spew abounds and JavaScript is a worse advertisement for cross-browser compatibility than CSS. So you can’t just check your page in one browser and assume it will work in all the others. Even if you could, you still need to understand the conceptual basis of CSS if you want to create stylesheets from scratch. It’s a pity, but that’s the reality of early 21st-century Web design.

Padding up – it’s not cricket

The most important thing to understand about CSS is the box model. Unless you only create linear pages with no elements side by side, and probably even if you do, you must understand this part of the standard. Get a good book or tutorial on the subject: Either of Eric Meyer’s books will give a clear and accurate explanation, as does the book written by Hakon Lie and Bert Bos – all three have been involved in the development of the CSS standards at some stage. There are probably many other books (and online tutorials) that are just as good.

The main thing to remember is that margin, border and padding do not count towards the width or height of an element. So if you define a DIV to have a width of 400px, and then define another DIV inside the first DIV to have 10px of padding and a width of 400px, something has to give – usually your sanity. Elements fill up the available space of their parents, so assuming there are no margins anywhere and no padding on the outside DIV, the inside DIV will have 380px of width (400px-10px-10px) without you having to define a width explicitly.

Literacy and numeracy

Things add up. If your layout isn’t working, and the HTML and CSS both validate, check your arithmetic. Graphic designers in the print world are used to thinking carefully about layout grids and making things balance. Even though screen-based Web layouts are never going to be millimetre perfect, there are still right and wrong ways to define layouts. Plan your layout carefully, and don’t throw something together without thinking and then wonder why you get a horizontal scrollbar.

Consider the following layout: You have three columns, which you want to be flexible in width but have consistent proportions between them. For example:

#left {width:20%;}
#center {width:60%;}
#right {width:20%;}

All well and good, but what if you want some padding around the text in those areas?

#left {width:20%;padding:2em;}
#center {width:60%;padding:2em;}
#right {width:20%;padding:2em;}

Now you’ve managed to define a page that’s wider than your window, guaranteed. Sure, some browsers will try to second-guess you and save you from your own innumeracy, but outcomes may be very unpredictable. Try leaving out the width definition for the center column, and you’ll be back in business.

Defining a layout entirely in pixels will lead to trouble, too. A fixed pixel width might look fine on your screen, but you can’t guarantee that your readers will view the page in a similarly sized window to you. Many people don’t use a full-size window when they browse, so knowing their screen resolution is pointless. Sure, you can play clever with JavaScripts to find the width of the window, but if you put some thought into your layout, and design for flexibility, you won’t need to.

Shake it up, baby

Another thing that can get you into trouble is to mix your units up. I mentioned this in passing in an earlier column, but it’s essential to understand the problem. I’ve seen it before on many sites, and worse, the first place I even saw it was an HTML tutorial site. (No, I’m not telling who.) If you define a font size in ems, for example, don’t define the line-height or the height of the containing block in points or pixels. This will only lead you into trouble if the reader has his or her browser’s default font size set to something you weren’t expecting.

Grit your teeth and grid, girl!

By now, some of you are probably wondering if this isn’t in conflict with my view that HTML should not be hard. Well, not really. Word processors are easy to use, but it still takes a little bit of common sense to make something look good in Word or its competitors. DTP was pretty easy to do even without much formal training, but you still needed to think about layout grids and making your leading add up. This isn’t hard stuff. This isn’t chasing down fifteen browser bugs in seven versions of three different browsers on two platforms, with solutions that are mutually inconsistent. It’s just some storyboarding on a scrap of paper, some simple arithmetic and a little bit of common sense.

— CodeBitch (codebitch@macedition.com) is the grumpy cow who does the HTML production for MacEdition. Read other articles by CodeBitch

E-mail this story to a friend