When designing for the web, there are several constraints that are not encountered in designing for print. It is important to keep these issues in mind when designing your site in order to ensure that the average user will be able to see the site as it is intended.
Web Safe Colors
Web Safe Fonts, CSS, and You …

Web Safe Colors

In spite of the wide range and availability of cheap video cards that support millions of colors, many people are still using a palette of only 256 colors. Also, many users work on older computer systems, and many IT departments seem reluctant to adjust their settings. There are effectively 216 colors (see formula below) that can be used for the internet. Operating systems typically use 40. (This will vary slightly for non-Windows platforms, but the accepted standard is 216 colors.) Refer to The Safety Palette to see what these colors are.
Possible Web Safe Values:
Red x Green x Blue
6 6 6
Total = 216

In the process of creating a web site, an option for the web designer is to specify color values using a color’s name, but this is not recommended because different browsers will have slightly different interpretations of name (thus, the 40 named colors used by the operating system). It is safer and more consistent to use hexadecimal (hex) values for your colors. In terms of colors, a hex value is a six-digit code that breaks down into three two-digit sets – commonly referred to as “hex triplets”. Each set maps to a red-green-blue (RGB) value that is considered “web safe” and is defined as one of six possible choices – 00, 33, 66, 99, CC, and FF. The correlation between the hex triplets and their corresponding RGB values are illustrated as follows:
hexadecimal Code RGB Equivalent
00 = 00
33 = 51
66 = 102
99 = 153
CC = 204
FF = 255

Any three of these sets can be safely combined to render a color that will be more consistently interpreted by all major browsers. For a visual representation of the colors and their associated hex codes, see The Safety Palette.

Web Safe Fonts, CSS, and You … VERY IMPORTANT!
The fonts that are considered to be web safe are the following:
Windows Macintosh
Arial Bookman, Geneva
Times Times
Verdana Helvetica, Chicago
Tahoma Helvetica
Symbol (Symbol) Symbol (Symbol)
Courier Courier, Monaco
Georgia Palatino, Times
FOR THE LOVE OF GOD, DO NOT USE THE FONT TAG WHEN DEFINING FONTS! In HTML 4.0, the FONT tag is deprecated, which means that in future browsers the tag will become obsolete and may not be supported. This is important, because we want code that is clean and usable for as long as possible. If you must define an in-line font style (that is, defining the font on the actual HTML page within the content), make sure to use the SPAN tag with the STYLE attribute within the tag your are putting text in, to select both Windows and Macintosh equivalent fonts, like in the following example:

Text Goes
Here!

This produces the following result, within another paragraph:

Other Text Other Text Other Text Other Text Text Goes Here! Other Text Other Text Other Text

Generally, you shouldn’t have to worry about this too much provided that you have already defined the fonts and colors in the Cascading Style Sheet that accompanies the page. Here the page layout is defined, including fonts, colors, and DIV box dimensions and positions, and we can use header tags like H1, H2 and so on to call header fonts, and for the rest of the page, the BODY and P tag style definitions in the Cascading Style Sheet should take care of the rest. Defining fonts for table tags (such as TH and TD) is important as well, as fonts for tables are considered to be independent from the BODY element in the HTML 4.0 specification as defined by the World Wide Web Consortium,or the W3C. Remember the good old !DOCTYPE tag that’s found at the top of pretty much every page?

Netscape and Microsoft fought the first round of the browser wars with rival extensions to HTML, both offering their own specifications of the language and their own processing applications, or browsers. Both have conceded control of the specification to the w3c, but even so, without the support of processing applications, a language goes nowhere. We saw this with the doomed HTML 3.0 specification, which the browsers never supported – but enough on that tangent. The great thing about all this is that we now have a central file that defines all the fonts and page layouts for the entire site. And, if we write clean, cross-browser compatible code we can easily alter the appearance of the site by simply changing the contents of one page. That’s it!

There are also specific instances where a unique element on the page is defined. These are called ID’s, and are defined on the style sheet with a pound symbol identifier (#) preceeding the name of the unique ID. These unique style sheet ID’s are able to be used only once in the page. ID’s become very useful in writing dynamic HTML (DHTML) that refers to a specific element within a page’s JavaScript Document Object Model (DOM). Should you need to define an ID that is used throughout the site in many places, you can do so by specifying a CSS class exactly the same as you would specify a CSS ID, except that for classes, you use the dot (.) identifier instead.

An example of one such Cascading Style Sheet that defines fonts and other page layout properties is as follows:
An Example CSS Script

<STYLE>

<!–

BODY {

BACKGROUND-COLOR: #ffffff;

COLOR: #666666;

FONT-FAMILY: “Tahoma”, “Helvetica”, sans-serif;

FONT-SIZE: 12px;

MARGIN:5px;

}

H1 {

COLOR: #666666;

FONT-FAMILY: “Arial”, “Geneva”, sans-serif;

FONT-SIZE: 20px;

FONT-WEIGHT: normal;

}

.h1 {

COLOR: #666666;

FONT-FAMILY: “Arial”, “Geneva”, sans-serif;

FONT-SIZE: 20px;

}

H2, TH {

FONT-FAMILY: “Arial”, “Geneva”, sans-serif;

FONT-SIZE: 16px;

FONT-WEIGHT: 600;

}

.h2 {

FONT-FAMILY: “Arial”, “Geneva”, sans-serif;

FONT-SIZE: 16px;

FONT-WEIGHT: 600;

}

H3 {

FONT-FAMILY: “Tahoma”, “Helvetica”, sans-serif;

FONT-SIZE: 14px;

FONT-WEIGHT: normal;

TEXT-DECORATION: underline;

}

.h3 {

FONT-FAMILY: “Tahoma”, “Helvetica”, sans-serif;

FONT-SIZE: 14px;

FONT-WEIGHT: normal;

TEXT-DECORATION: underline;

}

H4, H5, TD, LI, P, DIV {

COLOR: #666666;

FONT-FAMILY: “Tahoma”, “Helvetica”, sans-serif;

FONT-SIZE: 12px;

FONT-WEIGHT: normal;

}

A:active {

COLOR: #ff0000;

TEXT-DECORATION:underline;

}

A:hover {

COLOR: #cc0000;

TEXT-DECORATION:underline;

}

A:link {

COLOR: #0066cc;

TEXT-DECORATION:underline;

}

A:visited {

COLOR: #336699;

TEXT-DECORATION:underline;

}

A:visited:hover {

COLOR: #cc0000;

TEXT-DECORATION:underline;

}

.ContentBox {

border:1px solid #999999;

padding:15px;

}

.debug, .small {

FONT-SIZE: 10px;

}

.MainContent {

VERTICAL-ALIGN: top;

WIDTH: 100%;

PADDING: 10PX;

}

.red {

COLOR: #cc0000;

}

.white {

COLOR: #ffffff;

}

.blue {

COLOR: #6699cc;

}

–>

</STYLE>

This page may or may not be visible in the page source.
If you would like to stick to straight HTML code, you can use the LINK tag as follows:

<LINK REL=stylesheet

HREF=”includes/style.css” TYPE=”text/css”>

This way, the CSS code never appears in the page source, and an advantage this method provides that you do not need a server that runs ASP in order to include this as a separate file, so the code is completely portable – regardless of server platform. In my experience using the LINK tag, I have on rare occasion run into problems with the way that Netscape 4.x browsers render the web page: by partially displaying the style sheet code at the top of the page, and then laying the rest out normally. This is one of the bugs encountered occasionally with Netscape Navigator 4 when rendering CSS. If you’re using an ASP-enabled server, you can make a quick fix to this challenge by creating an Embedded style sheet on each page. An easy way to implement this is by using an #include file tag in the header of your page, like this:

<!– #include file=”includes/style.css” –>

Using this method, the CSS code becomes embedded in the header of the HTML code and is seen in the source, but does not bug out in Netscape. In my opinion, it really dosen’t matter how you decide to include the style sheet – just as long that the page appears normally in both browsers. Speaking of, I strongly recommend that developers continually monitor the output of the source code they are writing in BOTH Microsoft Internet Explorer 4 and Netscape Navigator 4.x. That way design bugs are caught in real-time, and developers won’t have to worry about potentially ruining a whole set of code (as well as hours of work,) due to code errors that can be as simple as a missing semicolon. Remember that safe development is smart development – so take some free advice: keep both browsers open as you write your code.

Popularity: 3%