wongaBlog
23Jan/071

Good and bad points of web design templates

A while ago I was asked to help with a website for a relative's company. I'm not so hot at all-round website building; the technical aspects aren't too bad, but I'm no graphic designer and it takes me a while to produce decidedly average layouts. I suggested she take a look at the many online template stores, who employ designers to build attractive layouts and then sell the results reasonably cheaply (on the basis that the design can be used by multiple parties - if you want an exclusive license it's a lot more). She picked out a template and asked what I thought. My brain was yelling 'form follows function', but short of hiring an expensive graphic designer it seemed like the best option, so we bought it. I don't mind playing around with something that looks good to begin with - in fact, it's quite good fun - but the main problem in this case was the table-based nature of the design.

The world-wide-web was never designed to be world-wide. It just happened that way. Because of this, the methods for laying out elements on a page were, to begin with, very basic. Every web browser in the world understood different sizes of text, bullet points, tables etc., and this was fine when most websites displayed data and technical information, but as the WWW spread people wanted their pages to look pretty. The simple methods weren't up to positioning graphics with desktop-publishing-like accuracy, but you could make a reasonable approximation using tables. Make a large three-column table and you've got a page layout where you're able to line up pictures and text relatively neatly.

For a long time, this was the best way to do things. But nobody liked it much. Tables within tables quickly get complex, and the inability of any browser to reliably draw individual cells to a specified height meant blank 'spacer' images had to be used to ensure everything lined up correctly. This could, and usually did, become horribly messy. It was normally possible to fudge a solution, but the slightest tweak would send the whole design out of whack, and trying to make sense of your own code, let alone anyone else's, could be nightmarish.

Eventually a standard called CSS was developed, which was far superior. There was far more scope to position elements precisely, and the background code became much more manageable due to the brevity of CSS - for example, it allowed you to say 'all images on this page will have a black border', rather than having to set each image individually. For all the quirks, inconsistencies and outright errors of individual browsers, CSS is still better than tables for positioning. But, admittedly, it's equally frustrating while you're learning - tables do at least work the same in all browsers and operating systems.

This particular template company, unfortunately, were sticking with the tables. And it was a horrible, horrible mess. So this morning, after a week of prodding around and finding that every change I made would break something else, I decided I'd keep the design but re-build it from scratch using CSS. Eight hours later and I finally slipped out of the weird daze I go into during web design sessions, but thankfully it's all finished. Of course, to my client's eyes it looks exactly the same as it did this morning, but when I have to add something in six months' time I'll hopefully be glad I changed it.

24Apr/063

IE6 display problems solved

I've finally managed to fix the display bugs plaguing readers using IE6. This site looked fine in Opera / Firefox, but IE users had many sidebar problems, including: images that were partially invisible, inconsistent spacing of text, plus all sorts of text-sometimes-appearing-sometimes-not weirdness. Turns out that they were all to do with an IE6 whitespace bug, officially called Whitespace-in-Lists, and this page told me all I needed to know.

If you have any kind of HTML list element, either <ol> or <ul>, IE6 will add extra whitespace between the <li> elements. This normally isn't a problem, but when there are margins of other elements close by the rendering gets all screwy - it seems like IE isn't accounting for the extra height when trying to render other elements, although I don't know this for sure. For whatever reason, the way around the problem is to define a width for the <ol> or <ul> elements. For example: ul { width:100%; } will handle it in the majority of cases, or you may need to specify a pixel width.

Hopefully the site looks much neater for people using IE6, now. Please let me know if you see any bugs.

Tagged as: , , , 3 Comments