Customize the Appearance of the Site
= Index DOT Html by Brian Wilson [bloo@blooberry.com] =

Why Did I Change To CSS?

To be honest, it was partly an experiment, but there was a very good secondary reason. This site began its life as a much smaller resource in an intranet environment. At that time, I could guarantee what browser the readers would have, so some of the design decisions I made were limiting. I chose the color scheme that I did after some playing around, never thinking it would be permanent. If I had it all to do over again, I would have made the site much more adaptable. The amount of work required to make it adaptable now is prohibitive due to the size.

So, of course, I did it. =)

What I Did And Why

I have converted all files on the site to use Cascading Style Sheets. To do this, I have created situation specific, CLASS-based markup on a foundation of simple formatting. This should help ensure that the site looks good on most any delivery platform. This extensive use of the CLASS structure to classify information is not highly recommended for use in HTML, but for complex informational webs like this, it is THE best solution to conquering the complexity beast in this language.

This has been a lot of work, but I believe the effort was worth it in the long run (even though some mid range contemporary browsers will suffer with a "duller" appearance due to lack of CSS support.) Changing to CSS allows several major capabilities that are unignorable:

• I can change the appearance of the entire site very quickly by changing only a few files. I have wanted to change the scheme of the site since I first created it, but the effort was too large to take on. I don't have to worry about that any more.
• Anyone downloading the site can also change the site appearance to whatever they wish. No explanation of this benefit needed!
• Whole site becomes more accessible. This first round of conversion to CSS was merely to get the site to the same level it was at previously when it relied on the FONT element for visual classification. There is much more I could do in the way of classing of different elements on the site to make further structural enhancements, but that will have to wait until my hands recover from this round. 8-}. The simple formatting currently used should degrade well on all browsers (testing that theory may take some time...)
• CSS solution is adaptable to many needs. I have included three CSS files that control the appearance for monitor based viewing, but it should be fairly easy to add CSS pages/rules that would accommodate ACSS (speech styling) or CSS printing properties for a browser that supports them.

How To Change the CSS Files

Currently, the CSS rules used will make the site appear as it always has. There are three CSS files that are used to control the appearance of all the files in the Index DOT Html site. These files exist in the '[SITEROOT]/css/' directory. Changing the CSS1 properties and values in these short documents will affect the appearance of the entire site.

    support.css - Controls all files in the Tag History Support Key

    cssguide.css - Controls all files in the Cascading Style Sheet Guide

    general.css - Controls all other files

The files are well commented and the class names used should be self-explanatory - you should be able to tell what it is you are controlling by the class name. If you do not understand what some of the CSS properties or values do, or don't understand the syntax, take a look at the Style Sheet Guide on the site. I am hoping that I haven't made any stupid or silly mistakes in this conversion process, and I would love to receive any comments or feedback on what I have done so far.

Details: Bugs I Had To Work Around

IE3 Bug

CSS properties specified for the BODY element in an external style sheet (via the LINK element) are NOT applied.
Regardless.
This is a BAD and far-reaching omission of behavior. It makes it almost impossible to specify global properties for all pages using just a few style sheets like I do here. I could not just let this pass either, because background field color is intrinsically tied to contrast comfort with colors chosen for foregrounds.

Solution

My solution was to apply IN EVERY SINGLE PAGE a document level style sheet specifying the document background color. Netscape 4 and Internet Explorer 4 do not have the aforementioned bug, but if you are using IE3, this is a vital issue.

The tag sequence that is found in EVERY file is as follows:

   <style type="text/css">
   <!--
   body          { background: #000000 } /* Workaround for _Stupid_ IE3 Bug! */
   -->
   </style>

If you wish to change the background color of the site, it would REALLY help if you have a tool that allows global search and replace capability. If you are using Netscape 4 or Internet Explorer 4, you can just delete this section if you wish - This rule is also controlled in the CSS files - where they OUGHT to be controlled. If you are using IE3 or just don't wish to delete this in all the pages, an automated tool that can change the BODY tag rule above to whatever you wish is vital... OR you can change the several hundred files manually. 8-} Good luck.

Netscape Bug

Netscape 4 has a minor bug which is still a nuisance to deal with. After tables occur in a document, regular text that is not given special CSS formatting will, um... disappear.

Solution

I have not investigated this deeply, but I found a workaround. I added a 'text' class name and it is used on all content after tables that cause this bug. It seems to have done the trick. You actually should never have to worry about this problem, but someone may wonder why the 'text' class was necessary. =)