Usage Tips

This site's design is only visible in a graphical browser that supports web standards, but its content is accessible to any browser or Internet device. (Why I do this.)

What's all this talk of design about? This site looks as plain as they come. My friend said there were different colored links, explanations for acronyms and stuff, and that you could change the text size if you wanted to, but I don't see any of it.
Learn how to get the most out of my site in this document.

This document ended up a lot longer that I meant it to be, but I still recommend that you read through it if you've got the time. If you just want to find out why there are different colors on some links, and why there's some weird dotted line beneath some words, take the short cut to the typographical conventions and come back to read the rest another day (yeah, right).

I have used terms like screen and clicking a lot in this document, which doesn't make much sense if you're blind or have some kind of handicap that prevents you from using a mouse (or if you're using a text-based browser). Since I don't have any personal experience from synthetic speech browsers or special input devices, I don't know how those work, but I assume that you will be able to translate those terms into whatever action is used in your software.

Requirements

In order for you to get the most out of your visits (note how I optimistically used plural there) to my web site, there are a few minimum requirements placed on the hardware and software you use to do so. Things are supposed to be accessible in any web browser on any output medium (except that hyperlinks are somewhat difficult to follow on a hardcopy terminal…), but the design will be lost in a non-compliant browser. Since I put a lot of work into that, I would really like you to see it and, hopefully, like it. If you're wondering why I don't fully support every conceivable browser and version, make sure to read the motivation below.

If you don't know whether or not your browser is compliant, see the browser test document to find out.

Browser

I use some fairly modern features in my design, and I rely totally on established web standards published by the W3C. There are lots of advantages to this, but there is, of course, a downside to it as well: even the latest versions of current (November 2002) web browsers barely support those standards. Although my primary goals have been focusing on standards compliance, I've also incorporated some measures of realism and tried to avoid some of the stuff that doesn't even work in my own browsers.

If we concentrate on the most widespread graphical browsers, these are the minimum versions you need for this site:

Minimum Browser Versions
Browser Version
Microsoft Internet Explorer 5.5
Mozilla 1.0
Netscape 6.0
Opera 5.0

Note that I have only tried IE5.5/Win and O5.12/Win myself; the other recommendations are based on the respective browser specifications. Also note that those version numbers refer to the Windows versions. I know almost nothing about browser versions for Mac, Linux, etc. If you do, I'd appreciate if you would enlighten me.

In order to cope with my documents, the browser will need to support the following web standards: XHTML 1.0 (HTML 4.01) and CSS 2 for virtually everything; DOM 1 and ECMA-262 for dynamic content; and XML and XSL 1.0 for photo galleries. Phew!

Client-side scripting must be enabled in your browser, or you will miss out on lots of cool features (like the menu and the quick links). Also, the conversion utilities won't work unless client-side scripting is enabled.

Cookies should be accepted by your browser to make the style sheet switcher (see changing text size below) work automatically. If that worries you, see the privacy policy below. It's okay… really… trust me…

Reporting Problems

I've compiled a list of bugs and quirks that I've found with the browsers with which I've tested every document. It's pretty technical, but it might be worthwhile to peruse it anyway, especially if you encounter any problems. If you find other bugs or problems, please let me know. E-mail me and describe the problem. Please include information about which operating system and what browser you're using, including the version number. Your browser identifies itself as:

(Note that Opera's browser have a setting for spoofing e.g. Internet Explorer.)

Display

This heading is somewhat misleading, since you don't really have to have a display per se to access my site.

I think it's a fair assumption, though, that a vast majority (that sounds pretentious, doesn't it?) of those who visit the site are using a graphical web browser from one of the major companies. The design probably looks best on a color monitor with a resolution of 1,024×768 pixels. That's my guess, because that's what I've used when I designed the lot. If my intentions work out the way they're supposed to, the design should adapt quite well to larger displays and reasonably well to smaller ones. I wouldn't recommend trying anything smaller than 640×480 pixels, though.

A monochrome monitor shouldn't pose any real problems. You'll probably find it difficult to tell the difference between internal and external links (see link types below), but that's no disaster (yes, I know it's due to poor design, but it's a choice I've made). Besides, the link titles should provide hints on what type of link it is, provided that your browser supports them, of course.

I haven't spent too much time worrying about text browsers like Lynx, or about handheld devices such as PDAs, but like with old browsers, all design will definitely be lost. The content should be accessible, however, although I haven't had a chance to verify it myself.

I did make a feeble effort to provide some support for reading browsers and Braille terminals, but since I have no personal experience with either one, I don't know how well I succeeded. Feedback would be nice. Please remember that I'm new at this, so I don't expect even a "single-A" rating according to the WAI guidelines at this time.

Changing Text Size

The web site's basic design uses a fixed text size, which unfortunately means that it cannot be changed by the browser. The text is pretty small, mainly because I happen to like it that way. I do realize, however, that this poses serious problems for people with poor eye-sight. To remedy the situation, I provide two style sheets ("normal text" and "large text") and a script-based switcher.

Browser Compliance

Certain browsers are reported to have very nice support for "alternate style sheets," as this technique is called. They will provide menu items where you can easily select one style sheet or the other.

Other browsers do not, however, so I included a simple style sheet switcher for those. The only problem with that is that the switcher requires JavaScript to be supported and enabled, and it also requires the browser to support DOM level 1. IE5.5/Win does support DOM 1, but O5.12/Win does not, although—unfortunately—it pretends to, so my script believes that everything's fine. On the other hand, Opera's browser has a nice feature called text zoom, which provides almost the same functionality as the "large text" style sheet (it will also zoom images, while the switcher will not).

Cookies

For the style sheet switcher to be really useful, it needs to "remember" which text size you've selected as you navigate to other documents on the site. It should also remember your settings the next time you visit the site. To accomplish that, I need to use "cookies". See the privacy policy below if you don't know what cookies are, or if you know all too well what they are.

The short version is that you need to allow your browser to accept cookies from my site in order to make the switcher work automatically. If you don't, you will have to select the "large text" style sheet each time you visit a document, which will become a bit tedious after awhile.

Choosing a Text Size

If your browser fully supports alternate style sheets, you may select "Normal text" or "Large text" from the browser's menu, or some similar means. The other option (the only option if there is no such menu) is to use the two "buttons" straddling the top edge of the content section (just below the title banner).

Here's the surprising news of the day: if you select the "large text" style sheet, there's no guarantee that the text size will be increased. It may even become smaller! I'm not talking about browsers like Opera here, where the buttons won't work at all, but about DOM 1-compliant browsers like IE5.5/Win. How can this be? The base text size in the "large text" style sheet is set to be "medium." That sounds clever, doesn't it? Bear with me, though. This means that the text size is set to be whatever you have defined as your preferred text size. That's not the important issue, though. The important thing about this is that you can now change the text size from within your browser (if it has support for that).

So, how do you do that? In IE5.5/Win, there's a sub-menu in the View menu, where you can select different text sizes. If you have a wheel mouse, you can also hold down the Ctrl key and scroll the wheel to make the text larger or smaller. (The latter approach also works with Opera's text zoom feature.)

This section describes how you can use various simple ways of navigating within and between documents on this site.

Browser Support

There may be browsers that use certain information within each document to provide their own menu of related and alternate documents. The ones I've specified are: start document, table of contents, previous document, next document, alternate language (Swedish), and alternate media (printable). Not all of those are specified for every document, of course—only those that are relevant. Exactly how those links are used depends on which browser you're using. Neither IE5.5/Win nor O5.12/Win has any support for this feature. See the description of breadcrumbs below for further information about the concepts of "previous" and "next" documents.

At the right-hand side of the document title banner at the top of each document, you will see a number of links separated by a " » " sign. This denotes the "path" through the document hierarchy, from the start document and down to the one you're reading (the last one is not a link, naturally). A path like this one is commonly referred to as breadcrumbs, because you can use them to find your way back through the hierarchy in much the same was as Hansel and Gretel did by spreading out breadcrumbs in the fairy tale.

The same type of breadcrumbs can be found in a document footer at the end of the content section. In the footer, there can also be a few other links, separated by a " | " rather than a " » " sign. The possible alternatives for these links are: Top, which takes you to the top of the current document; or Prev and/or Next, which take you to the previous or next document, respectively, in a series of related documents.

The Menu

In a standards-compliant browser, there will be a menu at the right-hand side of the content section. The menu itself consists of a number of blueish links, which should be fairly self-explanatory. If not, there are link titles attached to them, so if your browser knows what to do with those, you'll see a brief description of where the link will take you. IE5.5/Win shows this in a tool tip. O5.12/Win also shows a tool tip, but it also displays the link title in the status field just below the menu bar and icons in the browser.

The links in the menu will take you to all the different subsections on the site. There is also a link to the site map, which you can use to quickly jump to a specific document. If JavaScript is not supported or enabled, the site map is the only alternative you have for navigating to the subsections. Finally, there are links for sending me an e-mail (if your e-mail application and web browser are properly configured), for reading or signing by guestbook, and for getting to the start document of the Swedish version of this web site.

At the bottom of the menu area is the current "version number" of the site, along with a copyright notice. The latter includes yet another link for contacting me via e-mail.

Long documents—like this one—with a number of sections usually have quick links at the top of the content section. Those enable you to quickly jump to a section further down. Those quick links look something like this Example.

Dispersed at convenient intervals through those long documents are also similar quick links labeled Top, which will take you up to the top of the document, e.g. if you want to access the menu (IE), the breadcrumbs in the title banner, or the section quick links at the top of the content section.

Additional Tips

Image Links

Something of a nuisance on some web sites is the frequent use of images as links. I'm not only talking about those who create GIF images of text, just because they want to use a certain font, or because they don't understand what CSS is meant for. I'm talking about various photographs that, when you click on them, take you to another document. The problem is that there is usually very little hint that you're supposed to do that, especially if they've removed that ugly border that most browsers add around an image used in a link.

Don't worry, you won't find dumb things like that on my site, except… The photo galleries, where there are "thumbnail" images that you can click on to view a larger version of the same photograph. That's common enough that most people get it without being told, but I've told them just in case. There are also clickable icons in a few places, but those should also be fairly straightforward. Besides, there are always text links adjacent to those icons.

New Window

Sometimes you want to open a link in a separate window, either because you want to view that document along with the one containing the link, or because you know that there is no easy way of getting back from that document. The latter is especially true for external links (see link types below).

Microsoft Internet Explorer and Opera's web browser both allow you to do this very easily by holding down the Shift key while you click on the link. Others provide this feature in a pop-up menu if you right-click on the link.

Typographical Conventions

In an attempt to follow at least some established typographical conventions, I've used a few special characters every now and then in my documents. Many of those cannot be input directly from the keyboard. The HTML standard specifies two ways of inserting this kind of characters in a document: named character entities and numeric codes. I have used the named character entities for certain language-specific letters, because those have been around for so long that any browser should recognize them. For other symbols I've used the numeric codes instead, because the support for named entities for those is not as widespread. Yes, I know I've said that I should focus on standards and not give a damn about non-compliant browsers, but in this case I'm still following the standard while trying to prevent you from having to see things like "–" throughout the text. Of course, there's still a risk that you'll be seeing "–" instead, if your browser isn't quite up to speed, but that can't be helped. You should upgrade, anyway.

One typographical convention that I have not embraced is the use of curly quotes (“…”) and apostrophes (’). It makes the markup almost unreadable, and in a browser that doesn't understand Unicode, the resulting text will be almost unreadable, too. Likewise, I've opted to use a standard straight single quote (') and double quote (") instead of the recommended "′" and "″" for feet and inches, due to the lack of support for the latter.

If you see things like "æ" or "•" in my documents, your browser is hopelessly outdated.

Link Types

Since I personally prefer to open links to other web sites in a separate window (see additional tips above), I decided to provide some information about the links in my documents, in case you are like me in this respect. There are three different categories of links:

  1. Links to other web sites (external link) or other documents that do not belong to the "core" of my site.
  2. Links to other documents on my web site (internal link).
  3. Links to other parts of the same document (local link).

It is considered to be bad design to use nothing but color to convey information, but in this case the information is in no way critical, so I did it anyway. I also know that many people say that you should never suppress the underlining of links, or that you should always display visited links in another color, but I don't care. Too much underlining makes the text hard to read, and I just hate all those purple "visited" links in documents without a style sheet.

Helpful Text

If you write about Jeeps or web design it seems inevitable that your text is positively littered with abbreviations and acronyms. Certain terms or concepts may also be unknown to some readers, but fortunately HTML provides ways to keep the text short (by using abbreviations) and still convey their meaning to those who aren't aware of them. If only the companies who make web browsers would provide support for those features everything would be right with the world, but alas…

HTML provides markup for abbreviations (e.g. HTML) and acronyms (e.g. DOM). It also provides a means to offer explanatory text to a span of words. Now, if your browser is fully standards-compliant, there should be three parts that are underlined with a dotted line in this paragraph: HTML, DOM, and "a span of words".

If you position the mouse cursor above those underlined words, the cursor should change into a "help" cursor (usually a question mark). The meaning of the underlined part should then become visible in some way. IE5.5/Win does this through a tool tip. So does O5.12/Win, but it also shows the meaning in the status field above the display area.

IE5.5/Win doesn't understand the concept of abbreviations, for some reason, although it supports acronyms and titled spans. O5.12/Win understands all of them, but will not change the cursor.

The End

After the last word in a document, you will see a small "bullet" (•). This is just an indication that you've reached the end of the text. I wouldn't want you to sit by your computer for hours on end waitning for the rest of the document to download, when in fact there is nothing more…

Privacy Policy

A privacy policy does seem a bit pretentious for a non-commercial amateur's site like this, doesn't it? I decided to put it in when I began to use cookies (for the style sheet switcher), so that those of you who are really paranoid could find out what I'm trying to do to your precious computer.

What are cookies, then? A cookie is a small text file that a web document, via your browser, can request your computer to store. It is usually used for keeping track of information between multiple documents, such as preferences. As with anything that's nice and useful, there are always people who discover ways of abusing them. It is possible, for instance, to embed executable code in a cookie so that it may cause harm to your computer. Other malign (IMO) uses involve cookies for keeping track of which web sites you've visited. Most browsers allow you to choose whether or not to accept cookies. Try setting it to "ask first," then surf around to a number of commercial sites, and you'll see that these things are quite common. Cookies are usually stored in a specific directory somewhere, but different browsers have different names and locations for them. Browsers often have a menu item or similar for "clearing cookies," i.e. removing them altogether.

So why do I insist on using cookies, and why should you accept them? This has to do with the style sheet switcher I implemented (see changing text size above), which allows you to choose between "normal text" and "large text," and enables me to add more style sheets for other purposes in the future. To make this function useful, you should only have to select your preferred style sheet once (I prefer to use the term "style sheet" rather than "text size," because the differences don't have to be limited to text size). When you navigate to other documents on my site, that style sheet should remain in effect. If you come back to my site a week later, your preferred style sheet should still be in effect.

In order to achieve this, I need some means of storing information about your preferences. I can't do it on the server (my web host doesn't allow that, and space is limited), so I must do it on the client—your computer. Enter cookies. If I can store a cookie on your computer, where the cookie contains the name of the style sheet you selected, this works out nicely. Each time you visit one of my documents, it will read this cookie and set your preferred style sheet as the active one. If I didn't do this, or if you've elected not to accept cookies, you will have to make that choice every time you visit one of my documents. Note, however, that this doesn't matter if you prefer the "normal text" style sheet, because that's the default.

So what does this have to do with your privacy? This: I solemnly promise that I won't include any kind of executable code in my cookies, and that I will not use those cookies (or any other means) to "spy" on you. The only thing I'll store and read is information about your preferences regarding my site, which currently involves nothing but the name of your preferred style sheet.

Of course, if you choose to accept cookies, you expose yourself to the risks I mentioned above if you visit other sites than this one. That's something that I have no control over, though. Now you know what it's all about, and can make an educated choice in this matter.

Why Do I Do It Like This?

If you are using an older browser you may have encountered a message at the top of a document mentioning something about "web standards." This section will describe what that means, and why you saw the message in the first place. If you're not interested in my reasons for doing things my way, you can skip the background.

Background

To begin with, there are five different ways of approaching the concept of designing a web site:

  1. No design: This follows the original intentions of the World Wide Web, by concentrating on the content and leaving the presentation issues to the web browsers.
  2. Ignorance: Probably the most common approach for amateur web sites, using some fancy GUI design tool and creating the design by pointing and clicking on features that the author doesn't even understand how they work. As long as it looks good…
  3. Showing off: Where the author wants to show the world that he or she really knows about the nuts and bolts of all the available web technologies. Focusing almost exclusively on technology, content doesn't matter, because the purpose is not to convey information but to impress the reader—or, rather, viewer.
  4. Pleasing everyone: Common for commercial sites that need to attract customers from all walks of life, regardless of which web browser they may be using. Sites designed with this approach tend to focus more on presentation than on content, because an attractive packaging will sell anything.
  5. Doing it "right": Relying on established W3C standards, making sure that everything at least works in theory. This approach doesn't give a rat's derrière about how various browsers cope with the site, as long as the author gets to feel self-righteous about doing the right thing.

My first attempts to publish this site, I must admit, fell mostly in category II, although I didn't even use a fancy design tool. I just made something that looked all right in the browser I was using and didn't reflect too much on how it would look or work in other browsers. The next attempt was more in category IV, with more than a few elements of category III thrown in for good measure. Lack of insight on my part still caused problems for many readers. This time I'm leaning more towards category V, but with some measure of realism. See the section about the site's history for further information.

When Tim Berners-Lee invented the World Wide Web, his vision was in category I. The purpose of HTML was to provide structure to documents. It should point out headings and paragraphs and such, but it shouldn't worry about exactly how those headings and paragraphs appeared in the user agent (browser). At that time, browsers were text-based, like Lynx, so there wasn't much you could do in the way of design anyway. People who adhere to this point of view are commonly called structuralists, and they abhor any attempt of the author to influence the presentation.

When NCSA Mosaic was introduced in 1993, things began to change. This was a graphical browser, and very soon people wanted to use this new medium not only for conveying information, but also for presenting it in an appealing fashion. When newspapers started publishing on the web, their graphic arts designers wanted the same amount of typographical control over the new medium as they had had over the old one. Vile constructs such as the 1-pixel spacer GIF appeared, and structural markup like tables was suddenly used more for layout purposes than for actual tabular data. Browser companies like Netscape and Microsoft added their own markup tags to the HTML language in an attempt to satisfy the new need for layout control, and the original vision of what the web and HTML were about got lost among the font tags and table cell background colors. This kind of people are commonly called presentationalists.

While structuralists raged about mixing style and content, and presentationalists raged about the lack of layout control, things slowly but surely got out of hand. Proprietary markup that worked in one browser would be completely lost in another—even between versions from the same company. The designers in category IV were very busy indeed, because they had to write hundreds of lines of script code to make their design appear identically in all browsers. For each new browser version, those scripts had to be updated, and if you forgot to update just one small document somewhere…

I know I'm raving on here, but I want you to understand the background of my decision to move towards full standards compliance. The W3C finally got its act together and started weeding out layout control tags from the HTML language and replacing them with style sheets. Structuralists became happier when style and content were no longer mixed up, and presentationalists became happy when the style sheets enabled them to have better control over their layout than ever before. With an important organization like W3C backing things up, there should be a fair chance that those standards will eventually prevail.

There was one small problem, though: older browsers have little or no support for these new technologies. W3C had enough foresight to address this, though. We can now write web documents that will look nice in a compliant browser and whose content will still be accessible to older browsers, even though the design is lost. While this might seem somewhat unkind to users with old browsers, I think it's the right thing to do. As long as we have to provide support for the eccentricities of old browsers, we get to spend more time on maintenance than on what's really important: the information we wish to publish. After all, that's why we bother creating web sites, right?

With few exceptions, there are no good reasons to stick with really old browsers. I used to frown upon notices on web documents about how they required this or that version of browser (I still do if they require a specific brand of browser), but I'm beginning to see the wisdom in this. It's like with cars: the sooner we get rid of old rust-buckets and replace them with modern, fuel-efficient cars with catalytic converters, the better for the environment. There are exceptions, of course. As a few enthusiasts want to collect old classic cars, some companies are stuck with certain browser versions because they've—unwisely—invested large amounts of money in software that won't work with newer versions. That's fine—let them. As long as they don't complain about having to buy special additives because the gas station only offers unleaded gasoline, or about how the design looks weird on a modern web document.

By using nothing that isn't defined in W3C's standards, my intentions are that—sooner or later—all (or at least most) browsers should be able to present my documents the way I've meant them to appear. I'm trying to be future compatible, rather than backward compatible, mainly because it seems to be a lot smarter.

Upgrading Your Old Browser

I'm not saying that we should shut non-compliant browsers out, only that we shouldn't make too much of an effort to cater to them. When enough web sites are only available in the dull browser-default style, those who haven't upgraded their browser from sheer laziness might get their act together and do it. The Web Standards Project (WaSP) is trying to encourage us to adhere to the standards, and they even offer a place where you can conventiently upgrade your browser to a modern version.

If you use an old browser, you will se a message referring to the WaSP's browser upgrade initiative, and to this motivation, at the top of every document on this site (except the pure XML documents, which old browsers won't know what to do with anyway). If you are using a more modern browser, this message will not be displayed. A bug in IE5.5/Win makes it appear under certain circumstances, but those are rare on this site.

Summarizing, this is the deal: you can elect to keep an old browser—the content will still be accessible, but you'll miss out on the design—or you can upgrade and join the 21st century. I'm not going to spend any time trying to make it look good in an old browser, but if you only care about the content, you will still be able to use my web site. •