Quantum Gypsies

How I built a web site and learned to love Cascades

First steps

Needless to say, I started my web building in completely the wrong way, trying to cram maximum content and fully developed style sheets onto the site from day 1 and I advise everyone to make the same wrong headed start to web page building.

Here is a screenshot of one of these early pages, complete with multi-level menu and clickable images. More than half the page is taken up with navigation. Leaving aside the cluttered look that this produces; the real problem was that I didn't know enough about either HTML or CSS to have proper control of design changes.

Any changes I made in either content or style was likely to have unexpected side effects, which would be fixed with another change. You can see where this is going, it's the classic software regression problem. However, the reason I suggest that all new web builders follow the same path is that it introduces the stretch goal. The Canadian air force used to run keep fit exercises using the stretch goal principle. Do as many press-ups as you possibly can without stopping, now cut that limit in half and do that number of press-ups in each session until you feel really comfortable. Then repeat the stretch, comfort cycle.

Getting into a complete mess by stretching way beyond my skill limit gives me a good idea of where that limit currently lies and I can even surprise myself by occasionally figuring out something I didn't think I had a clue about.

I soon decided that I had enough material to publish, so uploaded it onto the server, pointed Internet Explorer at it and was reasonably happy with the result and that was my biggest mistake. A couple of days later, I decided to try Firefox and, naturally enough, pointed it at Quantum Gypsies to see how splendid it all looked in the latest raved about browser. I gasped in horror. Well, not literally of course, I am just trying to introduce some literary tension. Nothing on the page I was looking at was in the right place, the beautiful flowing design that IE displayed, was an unstructured heap in Firefox. I made enough emergency changes to get everything looking reasonably OK in both browsers and decided that it was time to retire to a defensible position, take stock and come up with a coherent development strategy.

Separating chalk and cheese

So what had I learnt, apart from the fact that I needed copies of every browser I could get my hands on for testing purposes, that is?

The cross browser problems that I had encountered were probably down to the fact that I was using a strict XHTML document type definition and that IEs idea of a strict definition was different from Firefox's. However, I decided to stick to strict XHTML because that was where W3C wanted us to go. Recently they have changed their mind and published HTML 5.0 alongside XHTML, so I will have to read through all the docs again and see in which direction I want to head. I currently favour XHTML, which seems more restricted in function but makes life much easier for machine content creation and analysis, but I am keeping an open mind.

It really is important to try to keep content and style separate, using HTML to organize content semantically and CSS to create visually appealing web page style. My early bumbling about mixing both up had convinced me of the correctness of that approach, although I still find it necessary to use semantic delimiters like <div> and <span> for purely stylistic reasons, as this sentence shows. But the most important thing I had learned was that whilst the cascading part of cascading style sheets could be a great ally in creating coherent styles, it would kick you in the teeth if you failed to understand what the cascade of dependencies really looked like at any point in the design.

I needed to get my head around the fact that whilst an element with a particular ID can be contained in an element of a particular class, it is equally possible for an element of a particular class to be contained in an element with a particular ID. The sort of thing that rang alarm bells when I was looking at logical database designs, sits perfectly happily in the domain of a web site.

Fluid Dynamics

All my early designs relied on some form of absolute positioning to achieve a style. Whilst this is no problem if the design of a page is fairly static over time, it does mean that even small changes in content can necessitate changes to the associated CSS. So a design goal is to allow everything to float on the page, with just gentle nudges to float left or right, which should make the eventual feed of content from a database much easier. Have I achieved that goal yet? No way, but I am getting slightly closer with each incarnation of the site. In woodworking, we call this process sneaking up on a fit.

The key to making it all work is simply to group things together semantically and then order the groups logically. The CSS will follow naturally from that. Occasionally I still have to stick in the odd empty paragraph, just to get the visual relationship between elements of a group to work, but generally form is following function.

KISS

That old acronym for "Keep it simple stupid" is never more appropriate than when constructing a style sheet. When I look at my early efforts, they are an impenetrable thicket of attributes, many of which simply repeated values that had already been declared. CSS attributes need to be pared down to their leanest, meanest size and then you will be able to use them elegantly rather than struggling with them.

There are two CSS structures in particular that I had to become fluent with, the box model and the list model. The box model is very simple and consists of three visual areas:

Each of these areas can take style not only as a whole, but for each side individually. The padding and border are fairly straightforward, but the margin can take a negative value allowing one box to overlap another. You can see this being used on the Leonardo Da Vinci page. Boxes can contain any content you like, including other boxes and this is where confusion can reign unless I keep the CSS clean.

As a simple example, if I have a paragraph class that sets the font size to 80% of the normal size and place that paragraph in a div that sets the font size to 200%, the font in the paragraph will be 160% of normal, which may not be what I was looking for.

The list model consists of either an ordered or unordered list object, stuffed with list elements that can be whatever takes my fancy: text, images, links and other lists. So once again it is necessary that I pay careful attention to what attributes I am setting at each level of the list model. The "Not the Da Vinci code" page shows some list attributes being set from the general list level down to a particular list class level.

Last updated 18 January 2009