The Web Design Group

Web Authoring FAQ: Web Design


This list of Frequently Asked Questions is maintained by the WDG and was last updated on November 29, 1999. It may be found at the following URLs:

If you would like to contribute to this FAQ, please send mail to <darin@htmlhelp.com>. All contributors will be listed at the bottom of the FAQ.

3. Web Design

  1. How do I include one file in another?
  2. Which should I use, &entityname; or &#number; ?
  3. Should I use lower case or upper case for tags?
  4. For what screen size should I write?
  5. Why does my page display fine in browser X but incorrectly or not at all in browser Y?
  6. Why does the browser show my plain HTML source?
  7. How do I freeze the URL displayed in a visitor's browser?
  8. How do I make a table which looks good on non-supporting browsers?
  9. Can I nest tables within tables?
  10. How do I center a table?
  11. Can I use percentage values for <TD WIDTH=...>?

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. But beware of making your "source code" non-portable.

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" (Apache, NCSA and some other web servers) and "ASP"; 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.pobox.com/~mnot/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.

[Table of Contents]

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.0 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.0 specification--use a validator such as the WDG HTML Validator at http://www.htmlhelp.com/tools/validator/ which supports HTML 4.0 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 &lt;, &amp; etc.

C. Internationalization per HTML 4.0

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

[Table of Contents]

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 &nbsp; are sometimes incorrectly referred to as tags. They are all case sensitive. For example, &Eacute; and &amp;eacute; are two different and valid entities; &NBSP; is invalid.

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

[Table of Contents]

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 realise 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.)

[Table of Contents]

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 "Can I nest tables within tables?" below 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?"

[Table of Contents]

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 only download a bunch of characters instead?" for more details.

[Table of Contents]

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.

[Table of Contents]

3.8. How do I make a table which looks good on non-supporting browsers?

See Alan Flavell's document on tables for a good discussion at <URL:http://ppewww.ph.gla.ac.uk/%7Eflavell/www/tablejob.html>.

[Table of Contents]

3.9. Can I nest tables within tables?

Yes, a table can be embedded inside a cell in another table. Here's a simple example:


    <table>
    <tr>
        <td>this is the first cell of the outer table</td>
        <td>this is the second cell of the outer table,
            with the inner table embedded in it<br>
        <table>
            <tr>
            <td>this is the first cell of the inner table</td>
            <td>this is the second cell of the inner table</td>
            </tr>
        </table>
        </td>
    </tr>
    </table>

The main caveat about nested tables is that Netscape has problems with them if you don't close your TD and TR tags meticulously. You're best advised to include every </TD> and </TR>, even though the HTML spec doesn't require them; otherwise Netscape users may not be able to view your page.

[Table of Contents]

3.10. How do I center a table?

The "correct" way of doing it is <TABLE ALIGN=CENTER>, but this doesn't work in several popular browsers. Put <CENTER>; around the entire table for these browsers.

This causes some problems with browsers that do support CENTER but not tables, such as Lynx. In these browsers, the contents of the cells are now displayed centered, which is not what is intended. To avoid this, you can put the cell's contents in <P ALIGN=left> or <DIV ALIGN=left> depending on the amount of text in the cell.

[Table of Contents]

3.11. Can I use percentage values for <TD WIDTH=...>?

The HTML 3.2 and HTML 4.0 specifications allow only integer values (representing a number of pixels) for the WIDTH attribute of the TD element. However, the HTML 4.0 DTD allows percentage (and other non-integer) values, so an HTML validator will not complain about <TD WIDTH="xx%">.

It should be noted that Netscape and Microsoft's browsers interpret percentage values for <TD WIDTH=...> differently. However, their interpretations (and those of other table-aware browsers) happen to match when combined with <TABLE WIDTH="100%">. In such situations, percentage values can be used relatively safely, even though they are prohibited by the public specifications.

[Table of Contents]


For additions or omissions to this FAQ, please contact <darin@htmlhelp.com>.

All information contained herein was originally compiled by members of the Web Design Group, principally Arnoud "Galactus" Engelfriet, John Pozadzides, and Darin McGrew.

Additional input has been provided by Boris Ammerlaan, Lori Atwater, Alex Bell, Stan Brown, Roger Carbol, Alex Chapman, Jan Roland Eriksson, Jon Erlandson, Mark Evans, Alan Flavell, Lucie Gelinas, Bjoern Hoehrmann, Tina Marie Holmboe, Peter Jones, Nick Kew, Jukka Korpela, Simon Lee, Nick Lilavois, Neal McBurnett, Glen McDonald, Dan McGarry, Ken O'Brien, Timothy Prodin, Steve Pugh, Liam Quinn, Colin Reynolds, Kai Schätzl, Doug Sheppard, Sue Sims, Toby Speight, Warren Steel, Ian Storms, Peter Thomson, Daniel Tobias, and Diane Wilson.

Thanks everyone!


Home, Reference, FAQs, Tools, Design, Feature Article, BBS, Links

Copyright © 1996-1999. Web Design Group All rights reserved.