Web Design
How do I include one file in another?
Which should I use, &entityname; or &#number; ?
Should I use lower case or upper case for tags?
For what screen size should I write?
Why does my page display fine in browser X but incorrectly or not at all in browser Y?
Why does the browser show my plain HTML source?
How do I freeze the URL displayed in a visitor's browser?
How do I put links along the left side of my page?

Section 3: Web Design

3.1. How do I include one file in another?

HTML itself offers no way to seamlessly incorporate the content of one file into another.

True dynamic inclusion of one HTML document (even in a different "charset") into another is offered by the OBJECT element, but due to shortcomings of browser versions in current use, it seems unwise to rely on this yet for essential content. The same can be said for IFRAME.

Two popular ways of including the contents of one file seamlessly into another for the WWW are preprocessing and server-side inclusion.

Preprocessing techniques include the C preprocessor and other generic text manipulation methods, and several HTML-specific processors. There is a nice annotated list of HTML preprocessors at http://www.idocs.com/wmr/software/html+preprocessors/.

Beware of making your "source code" non-portable. Also, the HTML can only be validated after pre-processing, so the typical cycle "Edit, Check, Upload" becomes "Edit, Preprocess, Check, Upload" (here, "Check" includes whatever steps you use to preview your pages: validation, linting, management walk-through etc.; and "upload" means whatever you do to finally publish your new pages to the web server).

A much more powerful and versatile pre-processing technique is to use an SGML processor (such as the SP package) to generate your HTML; this can be self-validating.

Examples of server-side inclusion are Server Side Includes (SSI, supported by Apache, NCSA, and other web servers), and Microsoft's Active Server Pages (ASP, supported by MS IIS). Processing occurs at the time the documents are actually retrieved. A typical inclusion looks like <!--#include virtual="/urlpath/to/myfile.htm" -->

but be sure to consult your own server's documentation, as the details vary somewhat between implementations. The whole directive gets replaced by the contents of the specified file.

Using server-side inclusion (a potentially powerful tool) merely as a way to insert static files such as standard header/footers has implications for perceived access speed and for server load, and is better avoided on heavily loaded servers. If you use it in this way, consider making the result cacheable (e.g., via " XBitHack full" on Apache; setting properties of the "Response" object in ASP). Details are beyond the scope of this FAQ but you may find this useful: http://www.mnot.net/cache_docs/

Proper HTML validation of server-side inclusion is only possible after server-side processing is done (e.g. by using an on-line validator that retrieves the document from the server).

Finally, note that if the included file contains arbitrary plain text, then some provision must be made to convert the characters "&" and "<" (in the plain text file) to the entities "&amp;" and "&lt;" (in the HTML document).

3.2. Which should I use, &entityname; or &#number; ?

In HTML, characters can be represented in three ways:

  1. a properly coded character, in the encoding specified by the "charset" attribute of the "Content-type:" header;
  2. a character entity (&entityname;), from the appropriate HTML specification (HTML 2.0/3.2, HTML 4, etc.);
  3. a numeric character reference (&#number;) that specifies the Unicode reference of the desired character. We recommend using decimal references; hexadecimal references are less widely supported.

In theory these representations are equally valid. In practice, authoring convenience and limited support by browsers complicate the issue.

HTTP being a guaranteed "8-bit clean" protocol, you can safely send out 8-bit or multibyte coded characters, in the various codings that are supported by browsers.

A. HTML 2.0/3.2 (Latin-1)

By now there seems no convincing reason to choose &entityname; versus &#number;, so use whichever is convenient.

If you can confidently handle 8-bit-coded characters this is fine too, probably preferred for writing heavily-accented languages. Take care if authoring on non-ISO-8859-based platforms such as Mac, Psion, IBM mainframes etc., that your upload technique delivers a correctly coded document to the server. Using &-representations avoids such problems.

B. A single repertoire other than Latin-1

In such codings as ISO-8859-7 Greek, koi8-r Russian Cyrillic, and Chinese, Japanese and Korean (CJK) codings, use of coded characters is the most widely supported and used technique.

Although not covered by HTML 3.2, browsers have supported this quite widely for some time now; it is a valid option within the HTML 4 specifications--use a validator such as the WDG's online HTML Validator at URL:http://www.htmlhelp.com/tools/validator/ which supports HTML 4 and understands different character encodings.

Browser support for coded characters may depend on configuration and font resources. In some cases, additional programs called "helpers" or "add-ins" supply virtual fonts to browsers.

"Add-in" programs have in the past been used to support numeric references to 15-bit or 16-bit code protocols such as Chinese Big5 or Chinese GB2312.

In theory you should be able to include not only coded characters but also Unicode numeric character references, but browser support is generally poor. Numeric references to the "charset-specified" encoding may appear to produce the desired characters on some browsers, but this is wrong behavior and should not be used. Character entities are also problematical, aside from the HTML-significant characters <, & etc.

C. Internationalization per HTML 4

Recent versions of the popular browsers have support for some of these features, but at time of writing it seems unwise to rely on this when authoring for a general audience. If you'd like to explore the options, you can find comprehensive background documentation and some practical suggestions at

3.3. Should I use lower case or upper case for tags?

Tags are case insensitive, so it doesn't matter. This is just a matter of style. (You may have noticed that this FAQ is not absolutely consistent in capitalization.) Many people prefer upper case, as it makes the tags "stand out" better amongst the text.

Attribute names can also be upper or lower case, as you prefer. But some attribute values are case sensitive. For example, <OL TYPE=A> and <OL type=A> are the same, but <OL TYPE=a> is different from both of them. (For clearer communication, it's worth getting the terminology right. In this example, OL is the element, TYPE is the attribute name, and A and a are the attribute values. The tag is <OL TYPE=A>.)

Entity names like   are sometimes incorrectly referred to as tags. They are all case sensitive. For example, &Eacute; and &eacute; are two different and valid entities; &NBSP; is invalid.

Note that XHTML 1.0 (a reformulation of HTML 4.01 as an XML 1.0 application) requires element and attribute names to be in lower case.

3.4. For what screen size should I write?

HTML does not depend on screen size. Normally, the text will be wrapped by the browser when the end of its display area is encountered. (Note that graphical browsers are often used with windows that are smaller than the full area of the screen.)

Preformatted lines (text within <PRE> elements) should only ever exceed 70 characters if the nature of the content makes it unavoidable. Longer lines will cause ugly line breaks on text-mode browsers, and will force horizontal scrolling on graphical browsers. Readers strongly dislike horizontal scrolling, except where they can realize that the nature of the content made it inevitable.

Images cannot be wrapped, so you have to be careful with them. It seems that 400 or 500 pixels is a reasonable width; anything above 600 will mean a certain percentage of users will have to scroll to see the rightmost bit. This percentage increases with your image width. Keep in mind that not everyone runs his browser at full screen!

(WebTV users have no ability to scroll horizontally, so anything beyond 544 pixels will be compressed by their browser. Some other devices may be even more limited.)

The use of tables for layout, especially when fixed-width cells are used, is the most usual single factor that prevents pages from adapting to various window widths. This is explained in detail at URL: http://www.dantobias.com/webtips/tables.html.

3.5. Why does my page display fine in browser X but incorrectly or not at all in browser Y?

There are several possibilities.

First, you may have some incorrect HTML. Browsers vary in their ability to guess what you meant. For instance, Netscape is much more fussy about tables than MS Internet Explorer, so a page with incorrect tables may look fine in MSIE but not display at all in Netscape. See the answer to "How can I check for errors?" for tips on finding your HTML errors. (In fact, even correct nested tables may not display correctly in Netscape. See the answer to "Can I nest tables within tables?" for what you can do about that.)

Second, you may have valid HTML that different browsers interpret differently. For instance, it is not clear from the spec what should be done with a string of &nbsp; characters. Some browsers will collapse them for rendering as a single space; others will render one space per &nbsp;.

Third, your server may be sending incorrect MIME types for some of your files. Internet Explorer incorrectly ignores server-provided MIME types, so it sometimes "does the right thing" when the server is misconfigured. Other browsers correctly heed the server-provided MIME types, so they will reveal server misconfigurations.

Other possibilities are a bug in one or the other browser, or different user option settings.

See also the answers to "Why are my hyperlinks coming out all wrong or not loading?" and "Why are my images coming out all wrong or not loading?"

3.6. Why does the browser show my plain HTML source?

If Microsoft Internet Explorer displays your document normally, but other browsers display your plain HTML source, then most likely your web server is sending the document with the MIME type "text/plain". Your web server needs to be configured to send that filename with the MIME type "text/html". See the answer to "Why did my link to a ... file download a bunch of characters instead?" for more details.

If the code is being displayed in all browsers, then there is an error in the HTML source. Double-check all HTML to ensure that all tags and attributes have been closed correctly. The error is usually just above the line where the code is displaying.

3.7. How do I freeze the URL displayed in a visitor's browser?

This is a "feature" of using frames: The browser displays the URL of the frameset document, rather than that of the framed documents. (See the answer to the question "How do I specify a specific combination of frames instead of the default document?").

However, this behavior can be circumvented easily by the user. Many browsers allow the user to open links in their own windows, to bookmark the document in a specific frame (rather than the frameset document), or to bookmark links. Thus, there is no reliable way to stop a user from getting the URL of a specific document.

Furthermore, preventing users from bookmarking specific documents can only antagonize them. A bookmark or link that doesn't find the desired document is useless, and probably will be ignored or deleted.

3.8. How do I put links along the left side of my page?

A common way to do this is to use a two-column table with your links in the left column and your content in the right column. This is often combined with a background image that creates a colored strip on the left behind the links. The background image can tile vertically, but to avoid horizontal tiling the image should be extremely wide (e.g., 1600 pixels).

A variation of this technique (which minimizes some of the problems with using tables for layout) uses a single-cell table with ALIGN="left". Only the links go inside the table, which floats to the left. The document's content wraps to fill the space remaining to the right of and below the table.

Layout tables can be avoided entirely by using CSS. The navigation links and the page's main content are placed inside separate DIV elements, and then CSS is used to position these DIV elements relative to each other. The style sheet can use a smaller background image that repeats vertically and is aligned along the left, for example:

body { color: black; background: white url(foo.gif) repeat-y left }



More information about Cascading Style Sheets can be found at: http://www.htmlhelp.com/reference/css/

Finally, a navigation strip on the left can be implemented with frames. However, frames introduce problems that are best avoided if possible.

See the answer to the question, "How do I include one file in another?" for suggestions that will help you maintain common content like navigation links across all the documents at your site.