Richard Flynn :: no comment

My first foray into Web design was for my sister Helen’s site which went live in the summer months of 1999. I’d taught myself HTML from a book called HTML Goodies, by Joe Burns. The first design was frames-based, with a navigation frame on the left-hand side of the browser window which drove the content pages on the right-hand side. The first site had I think ten pages or so, and had a cream background which we now refer to as “vomit” coloured.

Even back then I saw the benefits of using CSS to control the layout of the page, though I was only using style sheets really to define the fonts, and even then I got caught up with a mixture of relative and absolute font-sizing that looked different on every browser and OS combination I tried.

Gradually I moved away from the basic frames design, got a copy of Macromedia Dreamweaver 1.2 free on the front cover of .net magazine, and moved onto a predominantly green table-based layout. Since then I obtained Dreamweaver 4 as part of a Macromedia Studio deal for students, and the site’s design was changed again into what is currently on the site. That is due to change some time soon, and Helen Flynn’s site version 4 has been imminent for the past three years or so, much to Helen’s and my embarrassment.

A couple of years after starting Helen’s site, I got this domain name (richardflynn.net), primarily so that I could have a permanent personal email system—I’d been stung by companies who claimed that their service would continue indefinitely when those services didn’t. I used Dreamweaver 4 for the first design of this site, which was entirely static HTML (apart from one guestbook script, which wasn’t too great). It was difficult to update, and so I never did—consequently there were three sets of photos on there from 2003 which remained the sole photos.

Then in .net magazine a couple of months ago (the same magazine which had first tempted me away from hand-coding with their free distribution of Dreamweaver 1.2) there was an article about the way in which CSS could entirely drive the design of your site, rather than relying on clunky table-based designs. I knew that my site designs had become rather stagnant in the light of modern sites, so I read the article with interest.

I’m not going to go into great detail here about the benefits of using a solely CSS-driven site design, since that is available all over the web; however, I’ll briefly mention some of the salient points:

1. Smaller file sizes—Tables require a lot of code in your HTML pages, which pushes up the file size, and therefore takes longer for the end user to view your site. With CSS all that is in your HTML pages is the content itself. Ideally, all design is left to an external stylesheet, which instructs the user’s browser how to display the website. Once the user’s computer has downloaded the stylesheet, it can use it for the whole browsing session.
2. Ease of use—Now, if I wanted to redesign my site, I could just rewrite the stylesheet which controls the display of every page on this site, and that would be that.
3. It encourages the use of ‘semantic’ coding—This sounds a bit more complicated than it is: what this essentially means is that by having solely the content of the site in your HTML files, unencumbered by intricacies of design, then those HTML files are written in such a way that the tags (the <code snippets>) used in the files describe the content. Then, the stylesheet tells the browser how to display specific types of content, as defined by the HTML files. This means that a machine—such as a search-engine listing or ranking spider—can come along, read the site, and ‘understand’ (as far as a machine can understand anything) what type of content is on a page. Since your site is easier for the spider to read, it is more likely to get listed, and possibly even a higher ranking on the search engine.
4. It’s standard—The W3C has announced that it is not part of the current HTML specification (XHTML 1.0) to use design tags within your markup code. Browsers should all display markup and CSS which conforms to the specification the same way. In practice this isn’t the case, but I decided to take a pragmatic approach, and have ensured that my code complies to the current specifications. More about that later.

Anyway, I decided to take the time to learn how to make CSS work for me—HTML has now developed into XHTML, and so I looked for books that could provide guidance and training. I ordered three from Amazon:

1. HTML Utopia: Designing Without Tables Using CSS, by Dan Shafer (Collingwood, Victoria; 2003) [amazon.co.uk] [amazon.com]
2. Web Standards Solutions: The Markup and Style Handbook, by Dan Cederholm (New York, 2004) [amazon.co.uk] [amazon.com]
3. The Zen of CSS Design: Visual Enlightenment for the Web, by Dave Shea and Molly E. Holzschlag (Berkeley, California; 2005) [amazon.co.uk] [amazon.com]

These are books that I’d highly recommend, especially the first two. The first one (by Dan Shafer) is a step-by-step guide to using CSS: he runs through ways in which it can be implemented, examines a few problems and possible solutions, and the last section of the book is a complete CSS reference, which I found useful for those times when I couldn't quite remember the exact usage of a specific tag.

The second book (by Dan Cederholm) doesn’t concentrate solely on CSS—instead he looks at markup in general, always encouraging the semantic markup approach I mentioned above. He looks at individual aspects of a site and discusses the best ways of marking them up into successful code, before going onto the best ways to style them. It is from this book that I got the idea (and indeed the code) for the green horizontal navigation bar at the top of this, and every, page.

The third book is the companion for the CSS Zen Garden website. I strongly recommend you visit that site to see what it’s all about—it’s all explained there. However, this book shows the way in which CSS (and only CSS) can be used to create striking and vibrant designs. Its principal slant is towards heavily graphics-based designs, but it’s very interesting to read and I took a lot of inspiration from the designs featured in the book and on the site, especially with regard to colour schemes and font layout.

Anyway, I began coding, wrote out a test page with loads of diverse elements on it so that I could see how it would all look eventually. That took some time, but it was necessary. At this stage I was still working at static XHTML pages, and was looking hard for a photo gallery script that output standards-compliant code (in keeping with the rest of the site) whose layout I could easily switch over to be controlled by my newly-written stylesheet. If you didn’t know, there are a lot of PHP photo gallery scripts available out there, most of which produce horrendous code, look ugly and are almost impossible to style, and which have far too many features for what I needed. Eventually, I gave up looking on specific PHP script sites, and instead started searching on Google: I used a search phrase something like "photo gallery" php css xhtml. I found this page by Mathias, where he seemed to have been going through exactly the same things that I had. I checked out the script that he mentioned, iPAP by Markku Seguerra, and it seemed to fit the bill perfectly.

Markku was very helpful indeed when I couldn’t get the script to work first time on my server set up: he soon sent me alternative versions of individual files to try out, and eventually we got it working on this server. I’m very grateful for everything that he’s done. He’s currently promising a new version of the script which includes the opportunity of comments on individual photos, and I’m looking forward to when he releases that.

Just a note about standards-compliance. Obviously it’s important that your code conforms to the specifications for XHTML and CSS made by the W3C, since it gives some way of future-proofing your design against new browsers. However, unfortunately browsers today aren’t entirely standards-compliant. Internet Explorer (on Windows), for example has a problem with the way in which it calculates the width of individual elements on a page, which can result in pages looking radically different from the way in which their designer intended them. However, I firmly believe that only by writing compliant code can we encourage browser developers to bring their software into line. There are well-documented hacks which can be employed, all the while retaining the standards-compliance of your code. I haven’t yet had a chance to deploy any hacks into my stylesheet, but I will do in due course.

So, there’s the story of this site, or at least a somewhat potted version of it. I know I still have a bit more to do for it (e.g. designing a separate ‘print’ stylesheet), but I’m quite proud of what I’ve done. Feel free to rip it apart using the comments form, below.