How to design your website with CSS

Cascading Style Sheets (CSS) allows you to create fast loading pages, increase your search engine rankings, and modify your whole site with one style sheet. So why don’t more people use them? This is because they got so used to html design and are afraid or too lazy to upgrade their skills. Some will also use ready made templates that contain flashy graphics, bloated code and sometimes even contains hidden code embedded in the page.

In this series of articles I will show you how to create a simple web site using CSS, so you will have no excuse to begin incorporating them into your future designs.

What are Cascading Style Sheets?

Cascading Style Sheets is the name of a simple language that allows you to add any style (font, colors, graphics, links, layouts) to your web pages.

Benefits of Cascading Style Sheets

1. Separate content from presentation – you can separate your HTML markup, text, graphics and multimedia from presentation.
2. Consistent site wide look and feel consistency – you can apply one style for 100s of web pages all at once. So if you had to change the color of all pages on your site, you only have to edit one style sheet. This saves you a huge amount of time, especially if you had to edit each page separately.
3. Web site maintenance – apart from being able to make site wide changes easily through one CSS file, the clean code it generates makes it easier to update. Properly marked up web pages permit them to be maintained by more than one person. It will also work in more browsers. Website redesigns will take much less time.
4. Improve [search engine rankings](https://www.chennaihost.com/– search engines generally spider the code at the top of your web page first. For most sites that means the navigation bar will be spidered first (resides at top of page code). CSS enables you to position the code for your content at the top making your page search engine friendly. Properly marked up HTML pages can easily found and properly categorized by search engines
5. Fast loading – CSS reduces the amount of tags used therefore producing clean code. Tableless design can reduce your load time by 25% to 50%.
6. Reduce bandwidth – compacting the amount of code used will reduce the amount of bandwidth needed to host your web pages. Therefore you won’t have to pay higher fees when adding more web documents to your site.
7. Accessibility – increasing accessibility with CSS means being able to serve web content to a larger audience, increasing web site usability, even for non-disabled people. Content can easily be formatted for projection as well as screen display. Tableless layouts display well on hand-helds.
8. Improve the printing of web pages – most printers will only allow you to print a portion of the web page. With CSS your whole document can be printed.When you use CSS it becomes quick and easy to apply new styles that can not only effect all styles on your web page but even your whole site.

Introducing, Fun With Fonts

The principle I used is that I would pull no punches, well not exactly, there is no point in using CSS features that are not supported in any browser. I took Mozilla 1.1 as my ‘base’ as it is the most advanced browser where CSS is concerned, and it is my main browser of choice anyway. If what I was doing didn’t work in Mozilla 1.1, I backed off. I should point out, in case you don’t know, but Mozilla 1.x and Netscape 7 are almost identical twins.I produced a siteful of samples, all fairly jokey things, in fact it’s called Fun With Fonts . Here you will find a variety of typical home pages for imaginary sites, some concrete poetry and a short story. I used some fairly standard CSS, some Flash with CSS and some CSS that borders on the impossible.

Now, I have to confess, I wouldn’t normally do a Web site from the ground up in a text editor. Most of the time I use Adobe GoLive 6 or Dreamweaver MX – but more about that later in the review section.

CSS for Layout

One of the things that you can’t do with a tables-based layout is put text or images on top of other images, so the first thing I wanted to explore was the layering of graphic images to get a ‘look’ to a page that you just can’t get with conventional html. Normally you can use a repeating pattern as a background for a Web page. This page, for instance, is a good example of a tiny GIF file that is stepped and repeated to fill the entire page with negligible file size overhead.

Sometimes you see Web page backgrounds that are huge GIF or JPEG files that take ages to download and don’t show up for several seconds after the rest of the page has been rendered. Also, any background image will repeat eventually. If you want to fill the entire browser area with one background image, you have to make it so big that it will not tile on the largest monitor.

• A repeating GIF on top of a small
• JPEG makes a page background
• more interesting but you can only
• do it with CSS

With CSS, you can set an image to fill 100% width and height of its containing box or you can use several tiling methods to govern how it repeats – no-repeat, repeat-x, repeat-y etc. If you set a regular image to 100% x 100% of the browser window size, it will probably look awful. Web images don’t generally scale well and look bad at anything other then their natural size. For a JPEG image to look decent at full screen size would require an unrealistic file size. What I did was produce a small JPEG using high compression, which was just tonal in nature in create website – a simple gradient or shaft of light effect. On top of that, I have a repeating GIF file with transparent holes in it allowing the tone of the JPEG to show through. As the repeating GIF is crisp and sharp, it completely disguises the low quality of the JPEG behind but gives an overall impression of a high quality background image that is NOT simply a repeating pattern and resizes perfectly with the browser window, regardless of the size.

Absolute necessities

Absolute positioning with CSS is fairly easily understood and works in browsers as far back as Netscape 4.x – that is, provide that the elements are positioned relative to the top, left corner of the page.

CSS allows you to set the absolute position of element using ‘bottom’ and ‘right’ too so, for instance, you can have a navbar that sticks to the bottom edge of the browser window. It’s like having a constant ‘footer’ on the page, in fact, this principle makes the use of frames, and all their many disadvantages, virtually redundant. For several samples on the site, I tried locking elements to the bottom and right edges of the screen and when it does work, it’s great!

Relatively speaking

Relative positioning in CSS is one of those concepts that confuses even the most experienced of designers – and the browser programmers too it would seem. The big question is ‘relative to what?’

In theory, when you place a box using relative positioning, it ‘relates’ to whatever is above it and to the left margin so, if you put one box on a page, it floats to the top like a block of polystyrene in water. When you put another box in, it’s like putting another block of polystyrene under the first one; it floats up hard against the bottom of the first, and so on. You can offset the left of each box relative to the left margin to stagger them horizontally. That’s all fine.

The trouble comes when you start to use the ‘top’ property along with relative positioning. You can move a box up or down relative to the bottom of the box above by giving the ‘top’ property a negative or positive value – but what happens to any boxes below that? The ‘real world’ polystyrene blocks would float up or down to match the bottom of the one above, but CSS specs call for it to stay put. Unfortunately, the browser manufacturers do not agree and virtually anything can happen – and usually does.

Padding anomalies

The other major ‘gotcha’ you have to watch for is with box padding, which is counter-intuitive by specification – and most browsers get it wrong. Unlike table cells, padding for CSS boxes goes ‘outside’ the box size you specify, according to the official specs. Mozilla/Netscape 7 and Explorer handle this quite differently. For best multi-browser compatibility, I found that I had to avoid using padding altogether. The simple workaround is to use tall, narrow empty boxes as spacers.

Little boxes made of

ticky-tacky

CSS boxes generally want to stack one on top of the other. When you need to produce multi-column layouts, you can use ‘float-left’ and they should end up side-by-side instead. Giving each box a ‘margin’ value takes care of the column gutters. If you wrap the whole lot inside an outer containing box of an appropriate fixed pixel or percentage width and specify ‘auto’ for its left and right margins, the whole thing should centre nicely on the page – but set the body text-align property to ‘center’ too for best compatibility across browsers.

You can simulate most table layouts using combinations of stacked boxes (for rows) and nested boxes using float-left (for columns) but by setting negative values, you can make the ‘cells’ overlap and break out of the rigid grid. The things to watch for here are the discrepancies in how the browsers handle ‘inheritance’ – that is the feature whereby a ‘child’ object takes on attributes of the ‘parent’ – like when you put a box within another box. To be safe, be explicit in specifying things like text-align and font styles. Don’t always assume the default (unspecified) behavior or you will be caught out.

How did the browsers do?

Having designed and marked-up all my pages and tested them in Mozilla, I tried them in Internet Explorer 5.1.5 on my Mac. Luckily, most things worked right off and if they didn’t, my previous tips about avoiding the ‘margin’ property of boxes and not assuming default behaviours of nested boxes took care of the nasties.

Browsers used for testing

• Netscape 4.78 Mac
• Netscape 7 PR1 Mac
• Mozilla 1.1 Mac
• Mozilla 1.0 Windows
• Explorer 5.1.5 Mac
• Explorer 5.5 Windows
• Explorer 6.0 Windows
• Opera 6.05 Windows
• iCab Preview 2.8.1 Mac

I then moved over to Explorer 6.0 on my Windows XP machine and was pleasantly surprised. Only a few minor tweaks needed there too. Explorer 5.5 on Windows 2000 was a little more troublesome and I had to revise a few layouts to find workarounds, but it wasn’t as bad as I expected. There are a few minor cosmetic glitches remaining, but I doubt if many will notice them unless they are doing a side-by-side comparison create website with Mozilla or IE 6. The main problem with Explorer (on Windows) seems to be that it doesn’t get the font ‘line-height’ property quite right when font sizes are specified as pixels.

Explorer 6 and 5.5 on Windows and 5.1 on Mac, accounts for something like 95% of all Web users – if you believe the stats. The site works perfectly in Netscape 7/Mozilla 1.0. What about the rest?

The latest 6.05 version of Opera for Windows lagged behind the mainline browsers in CSS rendering create website capabilities. It claims to be fast, but it wasn’t noticeably faster that the other browsers, in fact screen redrawing of the layered graphics seemed slower than the other browsers on my machine.

** Note: ** A couple of readers have pointed out how a few minor changes to my CSS definitions can make Opera render these pages much better. I have amended the scores accordingly. More about that next time.

Likewise, iCab Preview 2.8.1 for Mac, was hopelessly inadequate at rendering many of the CSS positioned pages. It broke most of them and failed to render five pages to any meaningful standard.

Good old Netscape 4.78 coped with absolute positioning reasonably but failed to render any background colours or layered graphics. With this browser, most of the pages were compromised to one extent or another but in no instance did it totally fail to render a page. A side effect of the inability to cope with positioning is that, although you could see the navbar on the screen, the links just did not work making it impossible to navigate the site. To get around this problem, I produced an alternative menu page, ‘altmenu.html’, using tables instead – it’s still W3C compliant!

The Crunch!

If you really need to reach Opera, iCab and Netscape 4.x surfers, it is best to stick to conventional table-based layouts and use CSS only for specifying type within the table cells Netscape 4.x is too long in the tooth to worry about and getting rarer by the day, but the other two are current versions and really should be able to render CSS a lot better than they do.CSS gives designers many new possibilities to create website and lots of new headaches. Its advocates say that it is the way of the future, and I don’t doubt that for a minute, but things don’t change overnight. Surfers don’t jump on the latest browsers as soon as they come out the way designers do. Some don’t have the choice, some don’t know how and many don’t care. In the end, the Web is about communicating and it is your job to get the message across in the best way you can for your intended audience.

** Testing method ** Each of the twenty pages of the site was viewed in the various browsers three times over a period of one week and then given the following scores. The best possible score is twenty times five (100). Except for minor tweaks and avoiding some known browser bugs as mentioned above, no attempt was made to cater for substandard CSS rendering.

• 5 – for a perfectly rendered page
• 4 – near perfect rendering but minor cosmetic glitches
• 3 – rendered but with elements in the wrong place
• 2 – broken, but readable
• 1 – too badly broken to be of any use

As Mozilla 1.x (Mac and PC) and Netscape 7 produced identical results, only one is included.

** Note: ** The scores shown only relate to the pages tested and should not be interpreted as general performance. I mentioned in the article above that I used BBEdit to produce the funwithfonts.com site and that I wouldn’t normally do a site like this from scratch. Unfortunately, the main WYSIWYG web page editors like Macromedia Dreamweaver and Adobe GoLive are just not up-to-speed with the latest CSS specs even though the browsers are.

Here are my experiences with trying to use these two editors. Neither were particularly successful at displaying the layouts and made editing them in WYSIWYG mode difficult or impossible. I could have used their built-in ‘source’ editors but I prefer BBEdit for that kind of thing – especially as I’ve written lots of AppleScripts for BBEdit that automate many of the more tedious tasks.