Some Caveats with Using Frames

This article was originally posted at evolt.org.

While frames are not evil by default, there are many issues that must be considered before they are implemented on a site. Many sites on the internet appear to be unfamiliar with these issues, and use frames haphazardly, contributing to the overall inaccessibility of information online.

Bookmarks

In current browsers, if a user bookmarks a page, the browser actually only bookmarks the parent frameset. When that user later calls up that bookmark, he/she will get the home page or equivalent. Until browsers can actually bookmark frame-state (bookmarks the page exactly as you see it, by bookmarking all the pages in all the frames), one of the most reliable methods of making a user come back to your site now works against your site. If that user had spent hours wandering through your site trying to find a specific page, that user will become very upset very quickly when he/she realizes that he/she has to retrace his/her path through the site when that user calls up the bookmark.

It should be noted that some browsers, like Navigator 3.0 on the Macintosh will bookmark the selected frame. What this means is that users can accidentally bookmark a navigation frame, since that might be where they last clicked, or they may bookmark a blank frame, or any other frame in your layout. If they bookmark a content frame, then you run in to the problems I cite below about users who come to a specific page from a search engine, as well as the interface design issues.

Links

Linking to other sites within a frameset can pose some legal problems, even if you accidentally left out the target=”_new” in the <href> tag. If your site is branding another site as its own, simply by placing it within one of your frames, that site may order you to stop. Precedents include brand dilution and lost revenue among their arguments. Some related articles:

Links to internal pages can be problematic if you do not specify a target frame in every link. There are too many sites on the internet where a click to ‘Home’ in the navigation frame reloads that same frame in a sub-frame, causing users to see double navigation frames and less real-estate for content. This is a glaringly obvious error to all users, and will definitely not earn points with them.

Security

Some of you may remember problems with frame-spoofing (a web site inserting content into a frame that appears to be from another site), before the major browser vendors released patches. If you aren’t absolutely sure your users have these patches, then you may be opening them and your site up to this issue. In brief, if I link to an e-commerce site from my page, say Amazon.com from some book links, it would be possible for me to insert my own content into a frameset that is branded as Amazon’s, allowing me to post pages that request your credit card information and post directly back to my server instead of Amazon’s.

Independent of this, if you plan to use secure keys (you had darn well better) for your e-commerce applications, then you should know that neither Navigator nor Internet Explorer will display a secure icon in their browser if one of the frames is not secure, nor should they. This means that you now have to reload a new document for each frame with an https (a secured version of the Hypertext Transfer Protocol that utilizes encrypted keys) connection.

Frame Naming

In addition to the problems that can occur when linking within a site, keeping track of frame names and targets can be problematic should you ever change anything on your site. The more frames you have, the more complex the site becomes. If your site is designed to update all frames with every page, then you are now looking at an exponentially larger number of pages that need to be tracked then on a non-framed site, all with links that must be verified.

How many of you name your main frame ‘main‘? I have actually stumbled across sites that incorrectly load another site into a frame named ‘main‘, while the new site also tries to load content into a frame called ‘main.’ Not a real issue, but a curious one at the very least.

Search Engines

Many search engine spiders can only index the parent frameset. As a result, your page may get poor ranking in search engines. If your <noframes> tags contain meaningless text, or nothing at all, then most search engines stop there. For a more detailed overview of how to cope with frames with search engines, Search Engine Watch has a good section on what to expect.

If, however, a link to your site exists within a search engine, it most likely points to a page outside of a frameset. If you have any users coming in to individual content pages like this, you may have lost all your branding/identity, as well as all hopes of navigation for that user. There is JavaScript solution that loads the current page into a frameset, but you have to be sure you load the correct content page, and not just the homepage.

Interface Design

Frames promote poor interface design. If you have all your navigation in its own frame, how do you account for users who come from other places? Keep in mind the example above, search engines can bring a user right into the guts of your site. It is easy to forget that people can make their way in to the HTML page of a frame, and when they do, how do you plan to allow them to get to your home page? Or how do you indicate to the user that it is your site? These are all questions that should be answered before the design is even begun since supporting them requires some trade-offs in the overall site layout.

Most navigation frames do not indicate the current page. In the case of images as navigation elements, the “button” doesn’t stay activated after it is clicked. Most sites are capable of offering an image rollover, as well as a new image for an onClick event, but not many are capable of writing the JavaScript to keep the button activated once the user rolls over another. The same tends to be true with text links, since a visited link color only indicates that the user was at that page sometime in the past, but doesn’t definitively say if the user is still there. As a result, you cannot rely on the navigation frame as a visual cue for a user’s location within the site at any time as a well-designed standard navigation scheme may do. If, however, you think you have gotten around this problem by loading a new frame each time with different images, then you are ignoring the value of using frames in the first place — the ability to not have to keep downloading the same data over and over.

As you might expect, Jakob Nielson has an article on frames, but it is from back in late 1996 when Navigator 2 was still in most site’s logs, and Navigator still had the issue with the ‘back’ button taking a user completely out of a frameset. Either way, many of his points still stand today, 2 or 3 browser versions later. Some of these points include issues with the lack of value in the URL in the address/location bar as an indication of the user’s location within a site, or the problems with trying to print a framed page. The Web Design Group has a similar but more focused article.

Accessibility

There are still browsers out there that do not use frames, browsers that are brand new and make a conscious decision to not offer that traditional support. Some of these are browsers for the blind, or other handicapped users. If your audience possibly includes any of these users, be prepared for them to have serious trouble traversing the site. As an example of how problematic this may be, if you are a user of Microsoft FrontPage 3.0, then you can see that the <noframes> tag by default has the text, “This page uses frames, but your browser doesn’t support them.” This is not exactly polite, or user-friendly. It doesn’t even offer a link to a main frame page, nor does it automatically include the contents of that main frame within the <noframes> tag.

The U.S. government has signed a law requiring all government web sites (as well as vendors of the government) to be completely accessible to all users by Aug. 7, 2000, including the blind. While this may seem unrelated, frames are now a prime target for such regulation. Currently, only U.S. government sites are affected, but there is reason to believe that the law may also apply to not-for-profits who receive government funding. Since there have been no cases involving this law, there is no precedent as of yet, but I am also not qualified to give legal advice so you should check on your own:

This is a little off the frames path, but to further understand how browsers intended for blind audiences work, see The Royal National Institute for the Blind’s article Hints For Designing Accessible Websites.

Design

Support in the current frames-capable browsers is generally good, but there are still extra issues you have to become familiar with, especially if precise frame alignment is important. Netscape Navigator and Microsoft Internet Explorer do not handle frames exactly like one another. If you have ever tried to line images up across frames, you have encountered one of these differences, namely that Navigator sometimes chokes on such precise alignment. That doesn’t even take into account other browsers, versions, platforms, and their caveats. You can beat these issues, you just have to do that much more testing.

Your content is immediately restricted to a pixel size in at least one frame should you decide to force one frame to be a consistent size at any resolution. If you use percentages for all the frames, then the frames spread out on higher resolution monitors, or shrink to the point where nothing is visible if you haven’t accounted for low-res users or those who don’t surf full-screen (don’t forget those browser toolbars and how much space they take up). If you are concerned about what resolution you should target, consider reading my article 640 x 480 Isn’t Dead Yet.

Other Options

Most of the advantages of a frame (updating one navigation bar, for instance, for the entire site) can be accomplished through even the most basic server-side include. If you have this kind of access on your server, then it is something you should seriously consider as an alternative.

Consider a strong search and replace function to allow you to quickly share HTML between many documents. Some applications even allow you to have ‘virtual’ include files that are added into your HTML when you are ready to move it to the server. At the very least, re-use your images across as many pages as possible instead of downloading new ones since they are already in the browser’s cache at that point.

Read the Web Design Group’s Frames FAQ and the Guide to frames usage to help ensure you are accounting for the caveats above by knowing how to code for them. If you want to go above and beyond that, consider reading the Web Content Accessibility Guidelines 1.0 from the W3C. It offers help on ensuring that your framed pages are still accessible to as many users as possible.

Absolute positioning with CSS is a great standards-based solution if you want to ditch frames altogether. However, be aware of your audience. Frames are currently more widely supported than CSS, and you may decide that you will not reach enough of your audience using CSS.

Advertisements

640 x 480 Isn’t Dead Just Yet

This article was originally posted at evolt.org.

I’ve always kept a little list going of reasons why I still design for monitors and windows set to 640×480, and a list of reasons why I don’t want to design for 640×480 anymore. My reasons for accommodating 640×480 users are still rock-steady in my mind, while the reasons against still don’t cut it.

Compiled below is my list of reasons, with caveats, that I maintain for reference whenever I find that client who wants to design only for his or her monitor, forgetting about the wide variety of users out there. I should also qualify this by stating that the real problem with designing outside of the 640×480 box isn’t really the 480 height, since most users are accustomed to scrolling down, but the width. Many people never notice the scrollbar on the bottom and those that do resent having to scroll left to right to left to right, etc, just to read your content or navigate your site.

Readability

If you need to use more than 600 pixels for a line of text, you need be aware of readability issues. Keeping lines of text around 30-70 characters offers the best readability for the widest variety of users. This holds true on the web as well as in print, where hundreds of years of printed text has taught professionals that very same lesson.

Go beyond that, and readability begins to suffer. Now, obviously many users may have their fonts set to varying sizes, but usually these different sizes still cause the viewable text to fall into the broad range of 30-70 characters. Avoid the opposite – setting the fonts of your site to painfully small at 640×480 to get all your information on screen at 640×480.

This is about quality, not quantity. If you tailor your design so the smallest fonts a user will reasonably select get 70 characters per line, and the largest fonts they might select get 30 characters per line, you are right on target. And don’t worry about throwing an occasional image into your content (resulting in, say, rows of 20 character-per-line copy), because that design element helps break up the content for the reader, giving their eye somewhere to rest. Keep in mind the reading styles of people on the web, and their desire to get to information quickly. Unless this broad swath of text is the actual content for which a user has searched, there is probably too much text.

Some readers may be familiar with Jakob Nielson and his Alertbox articles. Some readers may think he is full of it (after all, it’s not like his own site is a poster boy for usability), but the articles cited below have been referenced time and again and have withstood more than 2 years of challenges. I think these three articles cover the usability issues I’ve pointed out above rather nicely in case you should want more detail.

Images

If you are scaling your images up to take advantage of all the space available in a larger-than-640×480 window, your images are most likely too large. Similar images of much smaller sizes, for smaller resolutions, are much smaller in file size as well. Larger images may be too much for a user to download, and may lead to serious congestion and problems displaying other images on the page.

Another interesting, though somewhat out-of-date with regard to future technology trends, Jakob Nielson article is The Need for Speed (March 1, 1997). It covers some of the issues you need to consider when you ask a user to download anything, including any and every page on your site.

While not always true, generally when people are given more space in which to design, they will fill it up, abandoning white space for more imagery and copy. Restricting that space can help you create smaller and faster pages, resulting in a better user experience. If it is a special case, like detailed product specifications, give the user a thumbnail view, with the option to download a larger file of specified file size. Also, consider other data formats besides just imagery.

Printing

If your site is an information repository, or even if it is frequented by only a select group of customers, many people have a tendency to print pages out. Just look around your office at the stacks of articles printed from CNN. Whenever possible, people will print out the information to read in a more comfortable and natural fashion. Remember, how you use the site may not be the same way other people use it, so be careful assuming that since you don’t need to print it, no one else would either.

A 600px site still fits rather nicely on an 8.5″ sheet of paper in portrait. Consider a 72 pixels-per-inch monitor with a 640 pixel wide browser window full of text and images, with say 50 pixels allotted to white space, scrollbars, and window frames. When you do the math, you can see that 590 pixels at 72ppi comes out to 8.2 inches, assuring that the printout and the web site may be identical.

Anything larger results in scaling or cropping of your pages, something you may not wish to have happen if it breaks your site identity or causes tables or images to span pages. This also means that, if your site is designed for it, you don’t need to offer separate printable pages, which require a set of separate templates, database calls, or even a series of hard-coded HTML files.

Design

There are some basic statements I will make that, while they aren’t fact by their very nature, they are still valid points, and ones I give out to clients and co-workers. You shouldn’t need all that space. If you need a larger canvas just to fit your white space, then your design is too big. If you need a larger canvas just to show your content, your content is too big and you may need to scale it down. The information overload alone could render the site unusable without some spectacular interface design. Keep in mind people’s attention spans on the web are short.

Compatibility

Some folks just don’t know that the factory default of 640×480 can be switched, a default that still exists on many computers today, especially low-end business computers. At least you can ensure that those users can still use your site, that you haven’t alienated any of them, or confused them by hiding content or navigation off the side of the page. While many users are starting to come online with palmtop computers, set-top boxes, and even surfing cell phones, you can be ready when the technology for those devices finally brings them in to the 640×480 world as well, which with current trends, may not be that far off.

Statistics

You’ve made it this far, now here’s some data to back up my arguments. Let’s take the 10th GVU WWW User Survey from October 1998 (the most recent one as of this writing). This is a sampling of web users and, in this specific case, their monitor resolutions. The numbers are as follow:

640×480 11.6%
800×600: 30.7%
1024×768: 27.7%
1152×900: 4.2%
1280×1024: 8.7%
Other: 3.0%
Don’t Know: 14.0%

At what resolution shall we assume the Don’t Know crowd is running? Let’s apply the overall percentages for all other categories to the Don’t Know crowd, giving us at least another 1% of users at 640×480. That means that 1 out of very 9 users is running at 640×480 resolution. If we went so far as to assume that the entire Don’t Know crowd is running at 640×480, then we would be looking at 1 out of every 4 users at 640×480 resolution.

However, as I said, this is not a truly random sampling. This study is skewed by experienced users, as suggested by the fact that 37% of the respondents claimed to be on the internet for 4-6 years. So let’s take a look at users at 640×480 and that don’t know based on the number of years of experience they have on the internet, applying the same calculation as above to come up with a rough number:

< 1 Year at 640×480: 17.9% } 24.6%
< 1 Year that don’t know: 37.5%
1-3 Years at 640×480: 13.7% } 16.5%
1-3 Years that don’t know: 20.3%
> 4 Years at 640×480: 9.6% } 10.3%
> 4 Years that don’t know: 7.3%

Now in what category do your users fall? The GVU survey also breaks the statistics down by ‘Skill Level,’ ‘Age Group,’ ‘Gender,’ and ‘Location.’ If you know your users are all experienced, veteran, male, American users, then perhaps this commentary isn’t for you. However, for everyone else, this is a matter of know your audience.

Another place to grab some statistics is at TheCounter.com, a free tracking service for web sites. TheCounter.com gets its data by placing an image on a site, and tracking each browser that requests that image. For the month of June 1999 (Tue Jun 1 00:01:03 1999 – Wed Jun 30 23:59:01 1999), with 321,729,388 visitors, their statistics read like this:

800×600: 53%
1024×768: 22%
640×480: 15%
Unknown: 2%
1152×864: 2%
1280×1024: 2%
1600×1200: 0%

There are many other sources through which you may sift to find information, but these two should have given you a basic idea of what you will discover.

Anecdotal

Who here surfs at full screen anyway?

Give the User Control Over Your Fonts.

This article was originally posted at evolt.org.

There’s nothing quite like getting your text just right with all your CSS attributes in place, and sitting back knowing that you finally have some typographic control over your pages.

It’s just too bad that’s not the case for your users. A user may come to your site and see text so large they can’t see more than three lines at a time, or so small they can’t even see your text.

“But wait,” you say, “I was careful to test it on Ed’s machine, and Sally’s, and even mine — in two browsers at that. What could possibly be wrong?” Well, even though the CSS specification supports many different relative attributes, none of them seem to work on any of the current browsers.

Correct rendering of the ‘em‘ is all I ask for, it’s such a simple concept: base 1em on the size of the default text as the user has it configured on his or her system, usually 12 point. Ideally, you ensure that the user has complete control over the sizing of text, making it much easier for your reader to read. But this is an ideal situation, not a real-world one and even if you get it to work, you may not realize that .5em is too small on every system but your own. You can see a great article on how to try to use the ‘em‘ at WebReview.com.

So it doesn’t work, nor do any of the other relative sizing units — at least not consistently across browsers and platforms. Instead you may find you are using points, or pixels, or something else to set your font sizes, and you try to accommodate all your viewers by making it the most ‘average’ size you can.

But it doesn’t have to be that way; you don’t have to completely wrest control from your users. Instead, empower them again, give them the ability to control what they see, let them, not you, decide that smaller text is better.

I’m a big proponent of server-side solutions whenever possible, it takes some strain off the browser, and ensures a consistent experience for all your users since nobody has to wait for clunky JavaScript to parse on their old P75 or Centris 610 with 16MB of RAM (way too little if you run any of today’s bloated browsers or OSes). So, given that disclaimer, I’m going to offer a solution to the problem using Active Server Pages, which results in plain ol’ HTML when passed to the browser. My code will not work with Apache, or ColdFusion, or any other server-side technology, but the capability to do it is in all of them, so at least follow the ideas as I go.

Let’s start with a real-world example. If you surf over to any of the pages at my personal gallery in a 4.x browser, http://roselli.org/adrian/ (please pardon the plug), you will see in the navbar a pair of buttons. By default, one should read ‘Enlarge Text‘ and the other should read ‘Shrink Text.’ Clicking one of these buttons will reload the current page with a link to a different style sheet (I use the <link> tag in the head to call my style sheets, but you can still use this tutorial if you embed your styles right in the document). It also presents a ‘Normal Size‘ button in place of the button on which you just clicked (provided you just clicked one, of course).

Let me run down what happens when you first come to the site (provided I haven’t changed anything, and it’s working correctly):

  1. Your browser requests a page and sends its name and version number over in the HTTP header.
  2. By requesting the HTTP_USER_AGENT, I can determine if your browser is capable of displaying CSS information.
  3. I set a cookie on your browser indicating that you are CSS-capable, then I set a cookie telling me that the font size I will be using for now is the default.
  4. When the page is served, some server-side script has determined if it should even send you the buttons to resize the text based on the CSS cookie I set.
  5. If it is set, you get to see two buttons, one to enlarge, one to shrink the text.
  6. The URL in the <a href> tag has a variable appended to the end of the filename of the current script (web page), that variable tells the script whether you’ve chosen to enlarge or shrink the text when you click one of the buttons.
  7. The page reloads, reading the variable from the URL, which triggers script that loads the alternate style sheet.

While this doesn’t cover all the bases, it does kill quite a lot of birds with one stone (pardon the metaphor mixing). It is also only a CSS solution, although it wouldn’t be too hard to make it apply to the <font> tags as well for your pre-CSS users. No matter what (CSS-capable) browser you are using, if you come to the page and the text is too small, kick it up a bit. If it’s still too small, well, don’t read the text, just look at the pretty pictures. Or you can use what you find in here to create more than three text size options.

So, on to the code.

First, you need to write up your cookie-setting script so you can call it from within every page on your site. Save the file as ‘cookies.asp‘ and consider putting it in a subdirectory where you store all your include files (perhaps ‘includes/‘, and make sure you’ve disabled directory browsing and have put a ‘default.asp‘ with a response.redirect command to send the user to somewhere else less dangerous in your site). Try using the following ASP script, which only checks for Navigator or Internet Explorer versions 4.x. I’ve purposely left it restricted to these two for the purpose of this tutorial, so that it has a better chance of fitting on the page. By the way, I’m not a cookie maven, so if you have suggestions, please let me know.

<%

'## Code by Adrian Roselli from http://roselli.org
'## Provided free for evolt.org and its members.
'## No catches, just give me credit.
'## This browser detection only detects IE4.x and NN4.x, please modify it as you see fit to get the 5.x and alternate manufacturer CSS-capable browsers.
'## Last change July 10, 1999

'########################
'## Browser Determination

'## Get the browser name and version number
UserAgent = Request.ServerVariables("HTTP_USER_AGENT")

'## If the cookie Browser has no value, then perform the following
IF Request.Cookies("Browser") = "" then

	'## Check the UserAgent string to see if it contains Mozilla or MSIE, and then to see if it has 4. in the version number
	if (instr(1,UserAgent,"Mozilla",1) > 0 OR instr(1,UserAgent,"MSIE",1) > 0) AND instr(1,UserAgent,"4.",1) > 0 THEN

		'## Adds 1 month onto todays date so the cookie will expire 1 month from now
		NewerDate = DateAdd("m", 1, FormatDateTime(Now,vbGeneralDate))

		'## Sets a cookie so that the browser is marked as CSS-capable
		Response.Cookies("Browser") = "CSS"
		Response.Cookies("Browser").expires = cdate(NewerDate)
	end if
END IF

'################
'## Set Text Size

'## If the URL does not have a ?size=value appended to it (meaning the user clicked one of the links), then perform the following
IF NOT Request("Size") = "" THEN

	'## If the user clicked to enlarge, then set the cookie to large
	IF Request("Size") = "Large" THEN
		Response.Cookies("TextSize") = "Large"
		Response.Cookies("TextSize").expires = #10/10/2000#

	'## If the user clicked to normalize, then set the cookie to large
	ELSEIF Request("Size") = "Normal" THEN
		Response.Cookies("TextSize") = "Normal"
		Response.Cookies("TextSize").expires = #10/10/2000#

	'## If the user clicked to shrink, then set the cookie to small
	ELSEIF Request("Size") = "Small" THEN
		Response.Cookies("TextSize") = "Small"
		Response.Cookies("TextSize").expires = #10/10/2000#

	END IF

'## Otherwise, check the cookie, and if it also has a blank value, set it to normal
ELSEIF Request.Cookies("TextSize") = "" THEN
	Response.Cookies("TextSize") = "Normal"
	Response.Cookies("TextSize").expires = #10/10/2000#
END IF

'##########################
'## Get Current Script Name

'## Sets ScriptName equal to whatever the current script name is
ScriptName = Request.ServerVariables("SCRIPT_NAME")

%>

Now you need to include this file in your script (web page). To accomplish this and to ensure any time you need to update your script you can do so with little trouble, we will include it in all pages on the site. We will assume that your scripts (web pages) are in a different directory at the same level as your ‘includes/‘ directory. Insert this line of code at the top of each of your scripts, above the <HTML> tag:

<!--#include virtual | file = "../includes/cookie.asp"-->

Now you need to create your resize links. Create another text file and name it ‘CSSResize.asp‘. Paste the following script into the text file (making sure it also exists in the ‘includes/‘ directory). Note, I tend to name my include files with an ‘.asp‘ extension since ‘.inc‘ and ‘.txt‘ get sent to the browser as plain text, allowing users to see your script if they know the path to the file; however, using an ‘.asp‘ extension causes the server to try to parse the file, resulting in an error page, which is much better than displaying all your hard-work (copied code).

<%
'## Code by Adrian Roselli from http://roselli.org
'## Provided free for evolt.org and its members.
'## No catches, just give me credit.
'## Make sure you supply your own images, rollovers, whatever.  These are just suggestions, especially since text links are not always attractive.
'## Last change July 10, 1999

'## Request the cookie Browser and see if it is a CSS-capable browser, based on your previous work.
'## This ensures that you do not display the buttons if the browser cannot use them.
IF Request.Cookies("Browser") = "CSS" THEN
%>

<%
	'## If the text isn't already set to large, offer the option.
	IF NOT Request.Cookies("TextSize") = "Large" THEN
%>
        	<a href="<% = ScriptName %>?size=Large">Enlarge Text</a><br>
<% 	END IF %>
<%
	'## If the text isn't already set to normal, or is not set, offer the option.
 	IF NOT Request.Cookies("TextSize") = "Normal" OR Request.Cookies("TextSize") = "" THEN
%>
        	<a href="<% = ScriptName %>?size=Normal">Return Text to Normal</a><br>
<% 	END IF %>
<% 
	'## If the text isn't already set to small, offer the option.
	IF NOT Request.Cookies("TextSize") = "Small" THEN
%>
        	<a href="<% = ScriptName %>?size=Small">Shrink Text</a><br>
<% 	END IF %>

<%
'## Display this text if the browser is not CSS capable - you could also just leave it blank.
ELSE
%>
	<i>Sorry, you can't see this because I've determined your browser can't do CSS.</i>
<%
END IF 
%>

Now you can see that when a user clicks one of the links, it reloads the current script (web page) with the size appended to the end of the URL. It does this because <% = ScriptName %> writes the URL of the current page into the <a href> before it is sent to the browser. The script (web page), upon reloading, reads the variable from the URL and uses that to set the cookie in the user’s browser, allowing him or her to maintain his or her preference the next time he or she comes back without any further input. But you will still provide the option to change it at any time by offering the other links.

Now, to put the resize links in your script (web page), just insert the following line in your page where you want the links to appear:

<!--#include virtual | file ="../includes/CSSResize.asp"-->

We are now on to the last step, including the updated CSS in the document. The next step you are going to take is create a new text file called ‘CSS.asp‘ in the ‘includes/‘ directory and paste in the following script:

<%
'## Code by Adrian Roselli from http://roselli.org
'## Provided free for evolt.org and its members.
'## No catches, just give me credit.
'## Make sure you point to the right style sheets, silly.
'## Last change July 10, 1999

	'## Iterate through the size options, with a default if there are no matches.
	IF Request.Cookies("TextSize") = "Large" THEN
%>
<LINK  REL="stylesheet" TYPE="text/css" HREF="../includes/large.css" NAME="master">
<% 
	ELSEIF Request.Cookies("TextSize") = "Small" THEN
%>
<LINK  REL="stylesheet" TYPE="text/css" HREF="../includes/small.css" NAME="master">
<%
	ELSE
%>
<LINK  REL="stylesheet" TYPE="text/css" HREF="../includes/normal.css" NAME="master">
<%
	END IF
%>

Or, if you prefer to include all of your styles within each page, then you can use the following script. Don’t worry, the server will only send the chunk of CSS that you specify with your IF statments.

<style type="text/css">

<!--
<%
'## Code by Adrian Roselli from http://roselli.org
'## Provided free for evolt.org and its members.
'## No catches, just give me credit.
'## Make sure you include all your styles, instead of just this one, silly.
'## Last change July 10, 1999

	'## Iterate through the size options, with a default if there are no matches.
	IF Request.Cookies("TextSize") = "Large" THEN
%>
.text        {    font : 12pt Arial, Helvetica, serif ;
		  color : #cccc99 ;
                  line-height : 16pt }
<% 
	ELSEIF Request.Cookies("TextSize") = "Small" THEN
%>
.text        {    font : 8pt Arial, Helvetica, serif ;
		  color : #cccc99 ;
                  line-height : 16pt }
<%
	ELSE
%>
.text        {    font : 10pt Arial, Helvetica, serif ;
		  color : #cccc99 ;
                  line-height : 16pt }
<%
	END IF
%>
-->

</style>

Somewhere within the <head> </head> tags of your script (web page), add the following:

<!--#include virtual | file ="../includes/CSS.asp"-->

Congratulations, if I wrote the script correctly, then you should be ready to experiment on your own servers. For double-checking purposes, the final code on your page may resemble this:

<!--#include virtual | file ="../includes/cookie.asp">

<html>
<head>
<title>Soylent Green</title>

<!--#include virtual | file ="../includes/CSS.asp"-->

</head>

<body bgcolor="#003333" text="#cccc99" link="#cc9933" vlink="#999999" alink="#ff0000">

<font face="arial,helvetica,sans serif" size="2" class="text">

This is some standard body text.  It will change size of you click a link below.
<br><br>

<!--#include virtual | file ="../includes/CSSResize.asp"-->

</font>

</body>
</html>

<!–
I have posted a sample page made up of the code found in this tutorial. If you do not have access to an ASP-capable server, then you may want to take a look at how it should function.

–>

There are many more options available to you here. Perhaps you want more than 3 styles, maybe you want 6. Perhaps you want the styles to change depending on where your user is surfing — for instance, pages of just text get a larger stylesheet, but pages with images and only caption text may have smaller stylesheets. You can also use the same code to re-write your <font> tags throughout the site, simply be defining them as variables in an included file and calling that variable throughout the site. You can even load larger or smaller navigation images for your site by using a series of image files in addition to the CSS.

Obviously, many of these suggestions go beyond what you may need to do for your users, but at the very least, giving the user control over the fonts on your site could go a long way to keeping them as repeat users. And at the same time, you may sleep better knowing that you are working toward making the web a friendlier place for both the eagle-eyed and the lazy-eyed.

If anybody would like to submit script that performs these same functions for other server/platform combinations (eg. ColdFusion), please feel free to let me know, and I’ll try to update the article.