Web Page Design Considerations for Amateurs

So you'd like to have a web presence of your own, but a blog won't do? You've got plain ol' information to get across? So off it goes into the minefield of web design. On this page I'll try to explain how useful modern web authoring techniques and ideas can be for both writers and visitors, and what kinds of pitfalls should be avoided. (Further reading is both encouraged and necessary.)

1. What's important for a web page?
2. General considerations
3. Markup
4. Notes on CSS
5. Scripting languages and misc.

What's important for a web page?

First off, you should have something to tell, preferably something that might be of interest to a visitor.

Then, you might say, it should also look nice. In fact many people start out with "WYSIWYG"-type editors, which depending on software and user knowledge may produce results between OK and downright horrible. WYSIWYG does not exist on the web, period! Pixel-by-pixel designs have been attempted frequently, of course, but they break far too easily. You do not want to have a page become unreadable just because the (ill-sighted) visitor has chosen a minimum font size larger than the one you specified.

A smart web page should not work against a visitor, but give support in finding information!

Central issues are accessibility, usability, graceful degradation and scaling.

Accessibility means that content should not be "hidden", if avoidable. Popular accessibility hurdles are framesets (best avoided anyway) and flash objects, but also text being written by Javascript. Generally good accessibility means that information should be present "in the clear" in the (X)HTML file. Content that is not accessible will not be indexed by search engines. Now guess how most pages out there are found - bingo.

Usability is not restricted to web pages, but applies to user interfaces in general. One should, for example, better stick to standard ways of navigation, not clutter the interface too much (something that sometimes one even finds with web design gurus) and choose sensible colors and font families that ensure good readability. Restricting the maximum width of paragraphs to about 70 characters may also be worth considering.
Scaling also belongs here - the design should scale well for different browser window and font sizes. It may not always look identical, but it should never break horribly. (OK, getting an image 640px wide onto your average mobile phone display will be a bit of a problem, but you get the idea.) In addition, font sizes should scale with the user's default size and thus be specified in units like em or % (not pt - except in a print stylesheet obviously -, and not px because not all browsers can scale this); this similarly applies to positioning (an area where one can mess up really well, even more so when including CSS floats).

Graceful degradation means that even when not using a modern full-featured web browser, all important functions should still work. If the browser can do little more than HTML 3.2 (no CSS, no Javascript/ECMAscript, no nothing), the page may look like in the early days of the web - but it will still be usable and the basic document structure will remain visible.

General considerations

One principle that is as elegant as it is useful is separation of content and layout, or content first. This basically means that you can happily write your main document first, with all the paragraphs and headings and lists and stuff (HTML offers quite a bunch of interesting elements for content markup), and then care about how it's supposed to look by referring to an external stylesheet (frequently you'll reuse one that you've written in the past). If you use one stylesheet for all documents, then changing that single file will alter display in all of them equally. Neat, huh?
Now in practice you'll want to apply a class here or wrap things in a DIV there (just look at this page's source code), but the basic principle still applies, and you could even view this as an extension of content if done consistently across documents (a new page template with the standard stuff is quite handy).

Your main documents will be written in HTML or possibly XHTML, styling rules will typically be found as CSS.
This CSS tutorial looks like a pretty good one to start with; sadly most HTML tutorials still are not as clean as I'd like, e.g. they still include proprietary elements and may not even mention the doctype declaration. If in doubt, stick to the W3C specification for HTML 4.01 Strict, use all lowercase tags, enclose values in quotation marks and use the HTML validator.

Markup (HTML/XHTML)

HTML vs. XHTML

HTML had traditionally been based upon the markup language SGML. XHTML brings the power of XML into the HTML world, e.g. by allowing inclusion of MathML. In addition, there are some differences in parsing due to this, e.g. every tag now has to closed explicitly, attribute values always have to be "enclosed" in quotation marks (no bad practice for HTML anyway) and the default charset is UTF-8. Also, the X(HT)ML browser may, under certain circumstances, refuse parsing altogether if the document is not well-formed (something allowed for XML). Now XHTML only really comes into its own with the matching content type of application/xhtml+xml instead of text/html - and that thoroughly breaks graceful degradation (even IE/Windows can't handle it). So unless you've got a fancy web server that knows which content type to choose depending on user agent, you might as well stick to plain ol' HTML 4.01 (Strict) for now. It's not high-tech, but it works (mostly). Meanwhile the development of HTML has been resumed in parallel with XHTML2.

Content considerations

In terms of doctype declaration, I would choose one that triggers standards-compliant mode on common browsers (e.g. Gecko-based ones and Opera).

If your web server does not specify a default content type with correct charset or if you want to be sure, use the corresponding META tag. Frequently, the correct charset will be iso-8859-1.

I would also specify the language on the HTML element, i.e. lang="en" in this case.

A meaningful page title should always be present.

Use semantically rich markup. If something is a heading, then use the appropriate H1 ... H6 element. If something smells like a list, then use a list. If it's just a paragraph, then use a paragraph. For emphasis, EM or even STRONG may be useful, and for a glossary there's a dedicated definition list with elements for terms and definitions. Even for abbreviations and acronyms, dedicated elements exist (but look up browser support). Preformatted text goes into the PRE element.
DIV is used for grouping only, it has no inherent meaning.
Should you stumble across FONT, B, U or I, you can ignore these relics.

Include some navigational aids (e.g. breadcrumb navigation) so that visitors can quickly move through pages. (For multi-part documents in particular, the venerable LINK element may also be useful. It's good for a lot more than just including stylesheets - look it up.) When using a kind of menu for navigation, make sure that it is obvious which of the listed pages is currently displayed, e.g. by making the link inactive.

Avoid using "mystery meat navigation", meaning navigation by unlabeled obscure symbols - clearly state what things link to. This equally applies to "normal" links - permanently using "xxx is <a href="..."gt;here</a>" is really bad style and makes an automatically compiled list of links just about useless.

Always give images a sensible ALT text. The alt attribute of the IMG element specifies a short replacement text (up to 80 characters) to be displayed if the image itself for some reason can't. The text should be chosen accordingly - up to alt="", i.e. an empty string, for purely decorative images. (Looking at things in a text browser can be highly instructive.) If you want to include a more lengthy description, the universal title attribute (frequently also displayed as a pop-up) is likely to be the better place, or in extreme cases you might even want to use longdesc to specify the location of a textual equivalent. In any case, better don't include any line breaks in strings.

When using FORMs, there are ways to improve accessibility and usability. Look these up when needed. (Some of these techniques are used on my contact page, in both HTML and the applying CSS.)

When specifying link targets, I have decided not to do away with the old trick of using empty anchors like this: <a name="target"></a> since using ids instead would break navigation on older browsers like Netscape 4, i.e. no graceful degradation, and that's just not worth it.

Be sure to validate your pages. Silly mistakes like using the wrong end tag do happen once in a while.

Notes on CSS

CSS is a chapter for itself. Cascading stylesheets as per CSS 2.1 are a powerful means of formatting documents, even depending on output media type if you wish (which makes sense since the same content might be viewed on a screen, printed on paper or read by a voice browser). Various pseudo-classes even allow "interactive" behavior. Should you happen to be unusually creative, you can also offer multiple alternative stylesheets.

Nowadays you can expect fairly decent CSS2 support. Nonetheless, one should watch out for specific browser bugs or implementation omissions and better not use some of the more advanced selectors for critical things, for example. quirksmode.org is a good reference for "what works where" type questions.

Be careful in which size units you employ. While px is useful for things like images or decorative borders (where scaling might produce unsightly results or doesn't make that much sense), the units of choice for text and things related should be relative ones like em, % or even ex so that text appears sensibly sized when compared to the visitor's standard font size. I would avoid text sizes of less than about 0.8em or 80% of the standard font size, since a minimum font size may be specified. Similarly, I'd stick to 1em for standard text. (The argument that one should choose a somewhat smaller size to prevent text from looking unusually large is not unjustified but ultimately silly - what's the point of a standard font size if it's not given the chance of being treated as such?) pt only makes sense in a print stylesheet.

Anything that contains large amounts of text should use a sans-serif font when displayed on screen, while in print a nice serif font can be beneficial. It may also be useful to limit content width to roundabout 70 characters (ca. 40em) as overly long lines are harder to read; similarly, an increased line-height is easier on the eyes.

Multi-column or other more advanced page layouts aren't unpopular, but they have their problems:

Probably the oldest way of doing multi-column layouts was using a "blind table", i.e. a table with no borders of any kind being visible. This works in anything that can display tables (a sensible order should be chosen in case it's interpreted cell-by-cell only, which may happen with non-graphical browsers) and is generally quite robust when it comes to font size and width scaling, also because cells aren't independent and thus a tradeoff between individual columns' widths is possible. In addition, this allows columns with synchronized heights. The big minus is that this technique heavily violates the principle of separation of markup and layout, since a table is supposed to contain, well, tabular data.
Almost equally old are FRAMEs - but you really shouldn't bother with that kind of old junk anymore. (If you want to "recycle" certain sections, there are editors allowing includes.)
A common CSS based solution takes various block-level elements (frequently DIVs) and arranges them using the position: absolute. It is fairly easy to mess up here - positioning in px in particular is not unlikely to cause the result to break horribly upon font size increase, either due to content overlapping each other (in case of overflow: visible, which is the default) or due to content being truncated (if overflow: hidden has been set); in less severe cases you may see scroll bars (with overflow: auto). Even when positioned in em, the various elements still don't know of each other, or where their containing element ends for that matter. This also means that achieving the same height on two "columns" of varying content is highly problematic. This technique is typically used for navigation bars and such.
Another CSS based solution uses floats, which are a little tricky to understand. What's nice about them is that if you have multiple floats lined up next to each other, part of them can wrap around into the next line if the element they're contained in isn't wide enough. (Implementing an intentional "line break", however, is not entirely trivial.) Again, floats know very little of each other and thus neither a space tradeoff nor synchronizing heights is possible.
A CSS2-level solution makes use of the display property, the options table, table-row and table-cell in particular. This unfortunately is not supported on Internet Explorer, and even some browsers that do may require "row" and "table" parent elements, potentially leading to increased DIV soup.
If you always wanted to be on the bleeding edge, this might be the option for you: CSS3 will feature multi-column layout, and Gecko-based browsers already support part of this now (still renamed to avoid breaking things in the future).

Some nice effects are possible with background-attachment: fixed, but beware: This may make scrolling uncomfortably slow and laggy on less powerful computers (such as mine).

Personally, I'm using 3 workarounds for buggy browsers in my stylesheet:

@media screen, projection { not only selects the media type, but also keeps Netscape 4 from interpreting the stuff inside this rule. (It also does not follow the @import rule that includes the print stylesheet.) Netscape 4 makes a decent HTML 3.2 browser, but CSS wise it's both buggy and antiquated and one is well advised to keep the stylesheet option off. (I used it for my mail archive for many years since the mail client wasn't half bad, but just recently retired it in favor of Seamonkey.)
* {;} /* opera 3.62 parse fix */ does what it says, since this old version of Opera, one of the first decent CSS1 browsers and arguably the best for Windows 3.1x (save for Javascript), also is a little confused by the former (CSS2-level) rule. It obviously does nothing for other browsers.
body { font-size: 100.01%; } is a workaround for a bug of Internet Explorer (at least 5 and 6) / Windows; I forgot the specifics.

Scripting languages and such

One can do a whole lot with (X)HTML and CSS alone - in fact, that's all this page uses. Now for all kinds of fun (or not so fun) stuff, scripting languages like Javascript / ECMAscript are quite useful. When using these, keep an eye on accessibility and usability (e.g. when an input form is being used or things pop up). Same applies if you want to include Java applets or Flash animations. (And please, no background music - this is a good way of aggravating visitors.)