This list of Frequently Asked Questions is maintained by the WDG and was last updated on August 9, 1999. It may be found at the following URLs:
The next Q&A addresses the more general issue of representing arbitrary characters in HTML documents.
Working with 8-bit characters can also be successful in many practical situations: Unix and MS-Windows (using Latin-1), and also Macs (with some reservations).
The available characters are those in ISO-8859-1, listed at <URL:http://www.htmlhelp.com/reference/charset/>. On the Web, these are the only characters widely supported. In particular, characters 128 through 159 as used in MS-Windows are not part of the ISO-8859-1 code set and will not be displayed as Windows users expect. This includes the em dash, en dash, curly quotes, bullet, and trademark symbol; neither the actual character nor &#nnn; is correct. (See the last paragraph of this answer for more about those characters.)
On platforms whose own character code isn't ISO-8859-1, such as MS DOS, Macs, there may be problems: you'd have to use text transfer methods that convert between the platform's own code and ISO-8859-1 (e.g Fetch for the Mac), or convert separately (e.g GNU recode). Using 7-bit ASCII with entities avoids those problems, and this FAQ is too small to cover other possibilities in detail. Mac users - see the notes at the above URL.
If you run a web server (httpd) on a platform whose own character code isn't ISO-8859-1, such as a Mac, or IBM mainframe, it's the job of the server to convert text documents into ISO-8859-1 code when sending them to the network.
If you want to use characters outside of the ISO-8859-1 repertoire, you must use HTML 4.0 rather than HTML 3.2. See the HTML 4.0 Recommendation at <URL:http://www.w3.org/TR/REC-html40/> and the Babel site at <URL:http://babel.alis.com:8080/> for more details. Another useful resource for internationalization issues is at <URL:http://ppewww.ph.gla.ac.uk/%7Eflavell/charset/>.
Be careful when your attribute value includes double quotes, for instance when you want ALT text like "the "King of Comedy" takes a bow" for an image. Humans can parse that to know where the quoted material ends, but browsers can't. You have to code the attribute value specially so that the first interior quote doesn't terminate the value prematurely. There are two main techniques:
Note that XHTML 1.0 (a reformulation of HTML 4.0 as an XML 1.0 application) requires attribute values to be quoted.
An HTML comment begins with "<!--", ends with "-->" and does not contain "--" or ">" anywhere in the comment.See <URL:http://www.htmlhelp.com/reference/wilbur/misc/comment.html> for a more complete discussion.
While checking for errors in the HTML, it is also a good idea to check for hypertext links which are no longer valid. There are several link checkers available for various platforms which will follow all links on a site and return a list of the ones which are non-functioning.
You can find a list of validators and link checkers at <URL:http://www.htmlhelp.com/links/validators.htm>. Especially recommended is the use of an SGML-based validator such as the WDG HTML Validator <URL:http://www.htmlhelp.com/tools/validator/> or W3C HTML Validation Service <URL:http://validator.w3.org/>.
See <URL:http://www.htmlhelp.com/tools/validator/doctype.html> for information on choosing an appropriate DOCTYPE declaration.
Note that the public identifier section of the DOCTYPE declaration is case sensitive. Some versions of Netscape Composer are known to insert the lower-case "-//w3c//dtd html 4.0 transitional//en", rather than the correct mixed-case "-//W3C//DTD HTML 4.0 Transitional//EN".
There are several companies and individuals who offer free web space. This usually ranges from 100KB up to 1MB, and again there are often limitations on its use. They may also require a link to their home page from your pages. The following page has pointers to several lists of free web space providers: <URL:http://www.yahoo.com/Business_and_Economy/Companies/Internet_Services/Web_Services/Free_Web_Pages/>.
There are also many web space providers (aka presence providers) who will sell you space on their servers. Prices will range from as little as $1 per month, up to $100 per month or more, depending upon your needs. Non-virtual Web space is typically the cheapest, offering a URL like: http://www.some-provider.com/yourname/ For a little more, plus the cost of registering a domain name, you can get virtual web space, which will allow you to have a URL like http://www.yourname.com/.
If you have some permanent connection to the Internet, perhaps via leased line from your ISP then you could install an httpd and operate your own Web server. There are several Web servers available for almost all platforms.
If you just wish to share information with other local users, or people on a LAN or WAN, you could just place your HTML files on the LAN for everyone to access, or alternatively if your LAN supports TCP/IP then install a Web server on your computer.
<META NAME="keywords" CONTENT="keyword keyword keyword keyword">
<META NAME="description" CONTENT="description of your site">
Both may contain up to 1022 characters, but no markup other than entities. If you use a keyword too often in the <META NAME="keywords"> tag, the indexing program may ignore your keywords list altogether. At this writing, "too often" means "more than 7 times" to some popular engines, but that may change in the future as indexing programs are changed to defend against "cheaters."
Search Engine Watch at <URL:http://searchenginewatch.com/> is a Web site dedicated to search engines and strategies for Web page authors.
If you can't set up a redirect, there are other possibilities. These are inferior because they tell the search engines that there's still a page at the old location, not that the page has moved to a new location. But if it's impossible for you to configure redirection at your server, here are two alternatives:
For example, if your server is Apache, see <URL:http://www.apache.org/docs/misc/FAQ.html#user-authentication>.
The Expires header is understood by virtually all caches. The cached document will be retrieved again automatically once it has expired. The Expires header must contain an HTTP date, which must be Greenwich Mean Time (GMT), not local time.
HTTP 1.1 introduced the Cache-Control header, which provides more flexibility for telling caches how to handle the document. For more information, see the HTTP 1.1 draft (see <http://www.w3.org/Protocols/>).
The Pragma header is generally ineffective because its meaning is not standardized and few caches honor it. Using <META HTTP-EQUIV=...> elements in HTML documents is also generally ineffective; some browsers may honor such markup, but other caches ignore it completely.
Further discussion can be found at <http://www.mnot.net/cache_docs/>.
Keep in mind not all browsers identify themselves correctly. Microsoft Internet Explorer, for example, claims to be "Mozilla" to get at Netscape enhanced documents.
And of course, if a cache proxy keeps the Netscape enhanced document, someone with another browser will also get this document if he goes through the cache.
For these reasons and others, it is not a good idea to play the browser
guessing game.
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.
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.
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 <, & etc.
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 characters. Some browsers will collapse them for rendering as a single space; others will render one space per .
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?"
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.
If you request a directory URL without the trailing slash, the browser will actually ask for a FILE with that name. This file doesn't exist on the server, so the server sends back a message saying that the browser should ask for the directory. It uses a redirection message for this. The browser then sends another request, this time for the directory, and finally gets what was asked for in the first place. This wastes time and network resources.
When you write a document, all directory URLs should end with a slash. Since you already know you are linking to a directory, why force the user to make that second request, when it could have been done using only one?
And by the way, it is NOT the browser which appends the slash. The browser cannot know if what you are asking for is a file or directory, not even when the final part of the URL does not have an extension. http://www.somewhere.com/src/something/README is a perfectly valid URL, has no extension in the final part, yet refers to a file and not a directory.
The only apparent exception is when you refer to an URL with just a hostname. Since it is obvious that when you use http://www.htmlhelp.com you actually want the main index "/" from our server, you do not have to include the / in this case. It is regarded as good style to do so, however.
For a full discussion of the proper form of URLs, see RFC 1738 at <URL:http://www.cis.ohio-state.edu/htbin/rfc/rfc1738.html> and, for relative URLs, RFC 1808 at <URL:http://www.cis.ohio-state.edu/htbin/rfc/rfc1808.html>.
<H2><A NAME="section2">Section 2: Beyond Introductions</A></H2>
Second, link to the named anchor. The URL of the named anchor is the URL of the document, with "#" and the name of the anchor appended. For example, elsewhere in the same document you could use:
<A HREF="#section2">go to Section 2</A>
Similarly, in another document you could use:
<A HREF="thesis.html#section2">go to Section 2 of my thesis</A>
<A TARGET="foobar" HREF=...> opens a new window named "foobar", provided that a window or frame by that name does not already exist.
Note that links that open new windows can be annoying to your readers if there is not a good reason (from the reader's perspective) for them.
<FORM ACTION="http://url.you.want.to.go.to/" METHOD=GET>
<INPUT TYPE=submit VALUE="Text on button" NAME=foo>
</FORM>
If you want to line up buttons next to each other, you will have to put them in a one-row table, with each button in a separate cell.
Note that search engines might not find the target document unless there is a normal link somewhere else on the page.
A go-to-other-page button can also be coded in JavaScript, but the above is standard HTML and works for more readers.
A JavaScript could use "history.back()" to do this, but this only works in Netscape 2 or higher and MSIE 3 or higher, and even then only if the user has not disabled JavaScript.
For a more detailed explanation, please see Abigail's "Simulating the back button" at <URL:http://www.foad.org/%7Eabigail/HTML/Misc/back_button.html>.
Send me email at
<A HREF="mailto:me@mydomain.com">me@mydomain.com</A>.
If you really need a subject, you can do it by providing a form on your page, which submits data to a CGI program that emails the form data to you with your desired subject line. However, the form must have an input field for the visitor's email address, and you must hope that the visitor enters it correctly.
Here are some other ways to transmit subject-type information:
<A HREF=...><IMG ...></A>
The configuration details of server-side image maps vary from server to server. Refer to your server documentation for details.
Client-side image maps are implemented with HTML. The MAP element defines an individual image map and the AREA element defines specific linked areas within that image map. The USEMAP attribute of the IMG element associates an image map with a specific image. A detailed explanation (with examples) is available at <http://www.htmlhelp.com/reference/html40/special/map.html>. A tutorial is available at <http://ppewww.ph.gla.ac.uk/~flavell/www/imgmaptut.html>.
If you want to prevent links on your page being underlined when your visitors see them, there's no way in HTML to accomplish this. You can suggest this presentation using style sheets by defining
a:link, a:visited, a:active {text-decoration: none}
a:link {color: blue; background: white}
a:visited {color: purple; background: white}
a:active {color: red; background: white}
a.foo:link {color: yellow; background: black}
a.foo:visited {color: white; background: black}
a.foo:active {color: red; background: black}
Then use CLASS="foo" to identify the links of the second color
in your HTML, like this:
<A CLASS="foo" HREF=...>...</A>
This especially happens if you use comment tags to "comment out" text with HTML tags. (See the answer to "How can I include comments in HTML?") Although the correct syntax is <!-- --> (without "--" occurring anywhere inside the comment), some browsers will think the comment ends at the first ">" they see.
Validators will show you any syntax errors in your markup, but checkers such as Weblint and HTMLchek can show you where you are liable to provoke known browser bugs. See also the answer to "How can I check for errors?"
You can encode any character in a URL as % plus the two-digit hex value of the character. (Hex digits A-F can be in upper or lower case.) According to the spec, only alphanumerics and the special characters $-_.,+!*'() need not be encoded.
You should encode all other characters when they occur in a URL, except when they're used for their reserved purposes. For example, if you wanted to pass the value "Jack&Jill" to a CGI script, you would need to encode the "&" character as "%26", which might give you a URL like the following: http://www.foo.com/foo.cgi?rhyme=Jack%26Jill&audience=child. Note that the "?" and other "&" character in this URL are not encoded since they're used for their reserved purposes.
See section 2.2 of RFC 1738 at <URL:http://www.w3.org/Addressing/rfc1738.txt> for the full story.
<a href="../files/foo.zip">Download Foo Now! (100kb ZIP)</a>
It is possible that the server might need to be configured for some different file types. (See the next Q&A.)
| Content Type | Description |
|---|---|
| Application/msword | Microsoft Word Document |
| application/octet-stream | Unclassified binary data (often used for compressed file or executable) |
| application/pdf | PDF Document |
| application/wordperfect6.0 | WordPerfect 6.0 Document |
| application/zip | ZIP archive |
| audio/x-wav | WAV audio format |
| audio/midi | MIDI audio format |
| audio/x-pn-realaudio | RealAudio |
| image/gif | GIF image format |
| image/jpeg | JPEG image format |
| image/png | PNG image format |
| text/html | HTML document |
| text/plain | Plain text |
| video/mpeg | MPEG video format |
| video/quicktime | QuickTime video format |
| video/x-msvideo | AVI video format |
Another method of ensuring that your file is properly sent to the client is to compress it into a standard compression format. Virtually all servers are set to handle the .zip extension and it is widely recognized by users.
Some servers (NCSA, Apache, and others) can be configured to support user-configured content types. Details are server dependent, so consult your server admin or documentation.
Note that 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.
<A HREF=...>
<IMG SRC=...>
</A>
will have white space to the left and right of the image. Since many browsers display anchors with colored underscores by default, they will show the spaces to the left and right of the image with colored underscores.
Solution: don't leave any white space between the anchor tags and the IMG tag. If the line gets too long, break it inside the tag rather than outside it, like this:
<A HREF=...><IMG
SRC=...></A>
Style checkers such as Weblint will call attention to this problem in
your HTML source.
<EMBED SRC="your_sound_file" HIDDEN=true AUTOSTART=true>
<NOEMBED><BGSOUND SRC="your_sound_file"></NOEMBED>
For more on the EMBED element, see <URL:http://developer.netscape.com/docs/manuals/htmlguid/tags14.htm#1286379>. See <URL:http://msdn.microsoft.com/developer/sdk/inetsdk/help/dhtml/references/html/BGSOUND.htm> for more information on BGSOUND. Note that these elements are proprietary and not in any HTML standard. (The HTML standard way of doing this is not well supported.)
Be aware that some users find it annoying for music to automatically start playing. They may not have the volume set properly on their speakers, or they may be listening to something else. As a courtesy to your users, you may prefer to offer the sound file as a link:
<A HREF="your_sound_file">Listen to my sound! (5 kB MIDI)</A>
Lynx users can use "lynx -dump http://..." on the command line to print to file and append a list of referenced URLs as footnotes. If you want the output file without the footnotes, use the "p" command to "print" to a text file.
Some HTML authoring tools have an option to strip all HTML as well. Two programs of note are
<P ALIGN=center><IMG SRC="custom-line.gif" ALT="--------------------"></P>
For an experimental but somewhat more graceful approach, read about CSS1 and the Decorative HR at <URL:http://ppewww.ph.gla.ac.uk/%7Eflavell/www/hrstyle.html>.
Why do you want one? If you believe that it will tell you how many times your documents have been accessed, you are mistaken. No counter can keep track of accesses from browser caches or proxy caches. Some counters depend on image-loading to increment; such counters ignore accesses from text-mode browsers, or browsers with image-loading off, or from users who interrupted the transfer. Some counters even require access to a remote site, which may be down or overloaded, causing a delay in displaying your documents.
Most web servers log accesses to documents stored on the server machine. These logs may be processed to gain information about the *relative* number of accesses over an extended period. There is no reason to display this number to your viewers, since they have no reference point to relate this number to. Not all service providers allow access to server logs, but many have scripts that will output information about accesses to a given user's documents. Consult your sysadmin or service provider for details.
Counter services and information are available from Yahoo's list of counters: http://www.yahoo.com/Computers/World_Wide_Web/Programming/Access_Counts/
Log analysis tools and scripts are at http://www.yahoo.com/Business_and_Economy/Companies/Computers/Software/Internet/World_Wide_Web/Log_Analysis_Tools/
<URL:http://www.markwelch.com/bannerad/baf_counter.htm> is another good source for counter information.
If you plan on putting the current date or time on your pages, using a CGI, JavaScript or VBScript, take an extra breath and consider that it will take resources, add time to the loading of the page, and prevent good caching. If you find that you really have a need to use it, for instance to inform readers of the up-times of an FTP server, then by all means do so. If, on the other hand, your only reason is 'it looks cool!' - then reconsider.
This script has two big problems. One, usually it uses the decrement operator (c--) at some point. The "--" sequence in a comment actually closes it on some browsers, so your code may "leak" on those browsers. The same goes for ">".
Second, keep in mind that many people consider this even worse than <BLINK>, and that it also suppresses the status information which normally appears there. It prevents people from knowing where a link goes to.
Perhaps what you really want is justified text, in which the left and right edges are both aligned so that all lines are the same length. (This is sometimes incorrectly called "right justify".) There's no way to justify text in HTML 3.2, but it can be done in a CSS1 style sheet with "text-align: justify". (Before you do that, a caveat: though justified text may look pretty, human factors analysis shows that ragged right is actually easier to read and understand.)
For images, you can use <IMG ALIGN=right SRC="..." ALT="..."> before the running text. The image will float at the right margin, and the running text will flow around it. Remember to use <BR CLEAR=right> or <BR CLEAR=all> to mark the end of the text that is to be affected in this way.
The FONT element can also be used to suggest a specific font. Use of the FONT element brings numerous usability and accessibility problems, see: http://www.mcsr.olemiss.edu/%7Emudws/font.html
More information about the FONT element can be found at: http://www.htmlhelp.com/reference/html40/special/font.html
Either way, authors run the risk that a reader's system has a font by the same name but which is significantly different. (e.g., "Chicago" can be a nice text font, or a display font with letters formed by "bullet holes", or a dingbat font with building images for creating skylines).
Also, authors are limited to choosing a font (or a group of similar fonts) that are commonly available on many systems. If a reader does not have the font installed on their system, they will see a default font. Some browsers may use a less legible substitute font than their normal default font in cases where "the specified font wasn't found".
P { text-indent: 5% }
See <URL:http://www.htmlhelp.com/reference/css/> for more information on style sheets.
/* Entire document */
BODY { margin-left: 20% }
/* Part of a document with CLASS="foo" */
.foo { margin-left: 15% }
See <URL:http://www.htmlhelp.com/reference/css/>
for more information on style sheets.
In general, page breaks are not appropriate on the Web since what makes a nice page break for you with your font and font size may be a poor page break for me with my font and font size.
If you need to produce a nicely formatted printed copy of your HTML documents, you might also consider using special purpose tools rather than your browser's Print function. For example, html2ps generates nicely formatted PostScript output from HTML documents, and HTML Scissor uses special HTML comments for suggesting page breaks.
body { color: black; background: white url(foo.gif) fixed }
Note that the fixed property used in the above style sheet is supported by Internet Explorer 3+, Netscape Navigator 5+, and other browsers. In contrast, the proprietary BGPROPERTIES=fixed attribute is supported only by Internet Explorer 3+.
body { color: black; background: white url(foo.gif) no-repeat }
The only reliable solution is to use a CGI (or other server-side) program to process your forms and mail the results to you. If you can run CGI programs on your server, see the list of prewritten scripts at <URL:http://www.cgi-resources.com/Programs_and_Scripts/>. If you can't run CGI programs on your own server, see the list of remotely hosted form-to-email services at <URL:http://www.cgi-resources.com/Programs_and_Scripts/Remotely_Hosted/Form_Processing/>.
Most browsers will also send the x and y coordinates of the location where the user clicked on the image to the server. They are available as "foo.x=000&foo.y=000" in the CGI input.
You will need to give your Submit buttons a Name attribute, and, optionally, a Value attribute. In order to determine which button was used, you will want to use distinctive Names, or Values, or both. Browsers will display the Value, in addition to sending it to the server, so choose something that's meaningful to the user.
Example:
<INPUT TYPE=SUBMIT NAME=join VALUE="I want to join now">
-or-
<INPUT TYPE=SUBMIT NAME=info VALUE="Please send full details">
If you're unsure what results you're going to get when you submit your form, NCSA has a standard script which you can use. Code this, for example (assuming method "post"):
<form method="post" action="http://hoohoo.ncsa.uiuc.edu/htbin-post/post-query">
and then go through the motions of submitting your form. The NCSA server decodes the form input, and displays the result to you.
File upload is handled by the CGI.pm Perl5 library available from <URL:http://stein.cshl.org/WWW/software/CGI/cgi_docs.html>. The most recent versions of the cgi-lib.pl library also support file upload.
These things are necessary for Web-based uploads:
<form method="POST" enctype="multipart/form-data" action="fup.cgi">
File to upload: <input type=file name=upfile><br>
Notes about the file: <input type=text name=note><br>
<input type=submit value=Press> to upload the file!
</form>
See <http://www.hut.fi/u/jkorpela/forms/navmenu.html>, which explains how to create pull-down menus, as well as some better navigation alternatives.
<FRAMESET ROWS="*,3*"> <FRAME NAME="navigation" SRC="navigation.html"> <FRAME NAME="content" SRC="content.html"> <NOFRAMES><BODY> <!-- Alternative non-framed version --> </BODY></NOFRAMES> </FRAMESET>Then, in the document with the link, use the TARGET attribute to specify which frame should be used to display the link. (The value of the TARGET attribute should match the value of the target frame's NAME attribute.) You can specify the target frame for each link individually (e.g., <A TARGET="content" HREF=...>), or you can use <BASE TARGET=...> to set a default target frame for every link in the document.
In HTML 4.0, the TARGET attribute value is case-insensitive, so that abc and ABC both refer to the same frame/window, and _top and _TOP both have the same meaning. However, most browsers treat the TARGET attribute value as case-sensitive and do not recognize ABC as being the same as abc, or _TOP as having the special meaning of _top.
The HTML-based technique can link to a new frameset document with TARGET="_top" (replacing the entire frameset), but there is an alternative if the frames to be updated are part of a nested frameset. In the initial frameset document, use a secondary frameset document to define the nested frameset. For example:
<FRAMESET COLS="*,3*"> <FRAME SRC="contents.html" NAME="Contents"> <FRAME SRC="frameset2.html" NAME="Display"> </FRAMESET>A link can now use TARGET="Display" to replace simultaneously all the frames defined by frameset2.html.
The JavaScript-based solution uses the onClick attribute of the link to perform the secondary update. For example:
<A HREF="URL1" TARGET=Frame1 onClick="top.Frame2.location='URL2';">Update frames</A>The link will update Frame1 with URL1 normally. If the reader's browser supports JavaScript (and has it enabled), then Frame2 will also be updated (with URL2).
In many current browsers, it is not possible to display a frame in the full browser window, at least not very easily. The reader would need to copy the URL of the desired frame and then request that URL manually.
I would recommend that authors who want to offer readers this option add a link to the document itself in the document, with the TARGET attribute set to _top so the document displays in the full window if the link is followed.
If the reader's browser has JavaScript support enabled, the following script will restore the frameset:
<SCRIPT TYPE="text/javascript">
<!--
if (parent.location.href == self.location.href) {
if (window.location.replace)
window.location.replace('frameset.html');
else
// causes problems with back button, but works
window.location.href = 'frameset.html';
}
// -->
</SCRIPT>
A more universal approach is a "restore frames" link:
<A HREF="frameset.html" TARGET="_top">Restore Frames</A>
Note that in either case, you must have a separate frameset document for every content document. If you link to the default frameset document, then your reader will get the default content document, rather than the content document he/she was trying to access. These frameset documents should be generated automatically, to avoid the tedium and inaccuracy of creating them by hand.
Note that you can work around the problem with bookmarking frameset states by linking to these separate frameset documents using TARGET="_top", rather than linking to the individual content documents.
To avoid "framing" other people's documents, you must add TARGET="_top" to all links that lead to documents outside your intended scope.
Unfortunately, there is no reliable way to specify that a particular document should be displayed in the full browser window, rather than in the current frame. If you can configure your server to send the proprietary header Window-Target: _top in the HTTP response, then Netscape browsers will display your document in the full browser window. However, other browsers ignore this header, and it doesn't work to use <META HTTP-EQUIV="Window-target" CONTENT="_top"> in the document itself to mimic the HTTP response.
Another workaround is to use <BASE TARGET="_top"> in the document, but this only specifies the default target frame for links in the current document, not for the document itself.
If the reader's browser has JavaScript enabled, the following script will automatically remove any existing framesets:
<SCRIPT TYPE="text/javascript"> <!-- if (top.frames.length!=0) top.location=self.document.location; // --> </SCRIPT>An alternative script is
<SCRIPT TYPE="text/javascript">
<!--
function breakOut() {
if (self != top)
window.open("my URL","_top","");
}
// -->
</SCRIPT>
</HEAD>
<BODY onLoad="breakOut()">
Furthermore, frames focus on layout rather than on information structure, and many authors of framed sites neglect to provide useful alternative content in the <NOFRAMES> element. Both of these factors cause accessibility problems for browsers that differ significantly from the author's expectations and for search engines.
For further discussion, see <URL:http://www.htmlhelp.com/design/frames/whatswrong.html>