This document answers questions asked frequently by web authors. While its focus is on HTML-related questions, this FAQ also answers some questions related to CSS, HTTP, JavaScript, server configuration, etc.
This document is maintained by Darin McGrew <darin@htmlhelp.com> of the Web Design Group, and is posted regularly to the newsgroup comp.infosystems.www.authoring.html. It was last updated on April 26, 2007.
Copyright © 1996-2007 by the Web Design Group. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/).
This information is offered in good faith and in the hope that it may be useful, but it is not guaranteed to be correct, up to date, or suitable for any particular purpose. The author accepts no liability in respect of this information or its use.
The official home of this document on the Web is:
A Dutch translation of this document is available at:
A French translation of this document is available at:
NOTE: If you want to mirror the FAQ on your WWW site on a publicly-visible server, please make sure you keep it up-to-date.
Other known sources are:
send usenet/news.answers/www/authoring-faq
in the body of your message
If you would like to contribute to this FAQ, please send mail to <darin@htmlhelp.com>. All contributors will be listed in the credits.
Please do not ask me questions via email. Please post questions to an appropriate public forum, where they will be read (and possibly answered/discussed) by many people with more expertise than me. Think carefully before posting; you'll get more useful answers if you post clear, complete questions.
If you think something already in the FAQ needs clarifying, or if you would like to offer a concise, well-written answer to a frequently asked question that is not yet in the FAQ, then feel free to send me email.
All information contained in this FAQ was originally compiled by members of the Web Design Group, principally Arnoud "Galactus" Engelfriet, John Pozadzides, and Darin McGrew. The Dutch translation of this FAQ was prepared by Rijk van Geijtenbeek. The French translation of this FAQ was prepared by Cédrik Rousseau.
Additional input has been provided by Boris Ammerlaan, Martin Atkins, Lori Atwater, Alex Bell, Robert Breeser, Stan Brown, Roger Carbol, Alex Chapman, Jim Dabell, Warden Dave, Curtis Dyer, Jan Roland Eriksson, Jon Erlandson, Mark Evans, Peter Evans, Joe Faulds, Vladimir P. Filipovic, Alan Flavell, Peter Flynn, Phillip Freck, Rijk van Geijtenbeek, Lucie Gelinas, Bjoern Hoehrmann, Tina Marie Holmboe, Cliff Howard, Bruce Huntington, Thomas Jespersen, Peter Jones, Nick Kew, Jukka Korpela, Simon Lee, Jim Ley, Nick Lilavois, Kelly Martin, Neal McBurnett, Glen McDonald, Dan McGarry, Brendan Murray, Ken O'Brien, Stephen Poley, Timothy Prodin, Steve Pugh, Liam Quinn, Colin Reynolds, Kai Schätzl, Randal L. Schwartz, Doug Sheppard, Sue Sims, Henri Sivonen, Toby Speight, Warren Steel, John Stockton, Ian Storms, Gérard Talbot, Peter Thomson, Daniel Tobias, Frederiek van Beckum, Diane Wilson, and no doubt others I've forgotten to credit.
Thanks everyone! Your comments, criticisms, and suggestions have considerably improved this FAQ.
The World Wide Web is "the universe of network-accessible information (available through your computer, phone, television, or networked refrigerator...)." The World Wide Web began as a networked information project at CERN.
HyperText Markup Language is a simple markup language used to create platform-independent hypertext documents on the World Wide Web. Most hypertext documents on the web are written in HTML.
The latest W3C recommendation is XHTML 1.0, which is a reformulation of HTML 4.01 as an XML 1.0 application. HTML 4.01 is an update with minor corrections to HTML 4.0. HTML 4 extends HTML 3.2 to include support for frames, internationalization, style sheets, advanced tables, and more. The new markup introduced by HTML 4 is not well supported by current browsers, but much of it can be used safely in non-supporting browsers.
Cascading Style Sheets are a standards-based mechanism for suggesting presentational style (e.g., fonts, colors, layout) for HTML documents. CSS is flexible and cross-platform, and is designed to preserve the accessibility of the document's structural content (even when all or part of the author's style sheet is ignored). A single style sheet can be used by multiple documents to suggest a common cohesive style, which is more efficient than using repetitive presentational markup in each individual document.
Standard Generalized Markup Language is a language used to define the syntax of markup languages. HTML is an SGML application (a markup language defined in SGML).
Extensible Markup Language is another language used to define the syntax of markup languages. XML is a subset of SGML, and is designed to represent arbitrary structured data in a text format. XSL is a stylesheet language for styling XML documents.
Extensible HyperText Markup Language reproduces, subsets, and extends HTML, reformulated as an XML application. XHTML 1.0 is identical to HTML 4.01, except for the syntax requirements imposed by XML. XHTML Basic is a minimal subset of XHTML for Web clients with limited capabilities. XHTML 1.1 is a reformulation of XHTML 1.0 Strict using XHTML Modules.
Server-Side Includes allow various directives (e.g., to include the content of another file) to be embedded within web documents. The web server processes SSI directives each time a document that uses SSI is retreived. Documents that use SSI are often identified with a .shtml filename extension, but there is no "SHTML" language as such. Implementation details vary among web servers; consult your server documentation for details.
Common Gateway Interface is a standard interface between external programs and web servers. Unlike static HTML documents, CGI programs can produce dynamic information based on form data submitted by the user, on information in a database, or on any other data available to the program.
Note that while many CGI programs are written in Perl, CGI programs can be written in other languages as well (including C, C++, Python, Visual Basic, and various Unix shells).
PHP: Hypertext Preprocessor is a general-purpose cross-platform scripting language. PHP is often used for embedded server-side scripts in dynamic web pages.
JavaScript is a cross-platform, interpretted, object-oriented language originally designed for client-side web scripting. The elements of web pages can be manipulated via JavaScript as objects specified by the Document Object Model (DOM). This enables dynamic effects like image roll-overs and interactive effects like pages that change in response to user input without being reloaded from the server.
LiveScript was Netscape's initial pre-release name for JavaScript. JScript is Microsoft's implementation of the language. ECMAScript is a standardized version based upon Netscape's JavaScript and Microsoft's JScript.
Everyone has a different preference for which tool works best for them. Keep in mind that typically the less HTML the tool requires you to know, the worse the output of the HTML. In other words, you can always do it better by hand if you take the time to learn a little HTML.
Within the HTML example, first replace the "&" character with "&" everywhere it occurs. Then replace the "<" character with "<" and the ">" character with ">" in the same way.
Note that it may be appropriate to use the CODE and/or PRE elements when displaying HTML examples. Also, the next Q&A addresses the more general issue of representing arbitrary characters in HTML documents.
The previous Q&A addressed the special case of the less-than ('<'), greater-than ('>'), and ampersand ('&') characters. In general, the safest way to write HTML is in US-ASCII (ANSI X3.4, a 7-bit code), expressing characters from the upper half of the 8-bit code by using HTML entities.
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).
Latin-1 (ISO-8859-1) is intended for English, French, German, Spanish, Portuguese, and various other western European languages. (It is inadequate for many languages of central and eastern Europe and elsewhere, let alone for languages not written in the Roman alphabet.) On the Web, these are the only characters reliably 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. These characters include the em dash, en dash, curly quotes, bullet, and trademark symbol; neither the actual character (the single byte) nor its &#nnn; decimal equivalent is correct in HTML. Also, ISO-8859-1 does not include the Euro currency character. (See the last paragraph of this answer for more about such characters.)
On platforms whose own character code isn't ISO-8859-1, such as MS-DOS and Mac OS, there may be problems: you 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, but this FAQ is too small to cover other possibilities in detail.
If you run a web server (httpd) on a platform whose own character code isn't ISO-8859-1, such as a Mac or an IBM mainframe, then 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 not in ISO-8859-1, you must use HTML 4 or XHTML rather than HTML 3.2, choose an appropriate alternative character set (and for certain character sets, choose the encoding system too), and use one method or other of specifying this.
It is never wrong to quote attribute values, and many people recommend quoting all attribute values even when the quotation marks are technically optional. XHTML 1.0 requires all attribute values to be quoted. Like previous HTML specifications, HTML 4 allows attribute values to remain unquoted in many circumstances (e.g., when the value contains only letters and digits).
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:
Both these methods are correct according to the specification and are supported by current browsers, but both were poorly supported in some earlier browsers. The only truly safe advice is to rewrite the text so that the attribute value need not contain quotes, or to change the interior double quotes to single quotes, like this: ALT="the 'King of Comedy' takes a bow".
Technically, since HTML is an SGML application, HTML uses SGML comment syntax. However, the full syntax is complex, and browsers don't support it in its entirety anyway. Therefore, use the following simplified rule to create HTML comments that both have valid syntax and work in browsers:
An HTML comment begins with "
<!--", ends with "-->", and does not contain "--" or ">" anywhere in the comment.
The following are examples of HTML comments:
<!-- This is a comment. --><!-- This is another comment,
and it continues onto a second line. --><!----> Do not put comments inside tags (i.e., between "<"
and ">") in HTML markup.
The URL structure defines a hierarchy (or relationship) that is similar to the hierarchy of subdirectories (or folders) in the filesystems used by most computer operating systems. The segments of a URL are separated by slash characters ("/"). When navigating the URL hierarchy, the final segment of the URL (i.e., everything after the final slash) is similar to a file in a filesystem. The other segments of the URL are similar to the subdirectories and folders in a filesystem.
A relative URL omits some of the information needed to locate the referenced document. The omitted information is assumed to be the same as for the base document that contains the relative URL. This reduces the length of the URLs needed to refer to related documents, and allows document trees to be accessed via multiple access schemes (e.g., "file", "http", and "ftp") or to be moved without changing any of the embedded URLs in those documents.
Before the browser can use a relative URL, it must resolve the relative URL to produce an absolute URL. If the relative URL begins with a double slash (e.g., //www.htmlhelp.com/faq/html/), then it will inherit only the base URL's scheme. If the relative URL begins with a single slash (e.g., /faq/html/), then it will inherit the base URL's scheme and network location.
If the relative URL does not begin with a slash (e.g., all.html , ./all.html or ../html/), then it has a relative path and is resolved as follows.
Some examples may help make this clear. If the base document is <URL:http://www.htmlhelp.com/faq/html/basics.html>, then
Please note that the browser resolves relative URLs, not the server. The server sees only the resulting absolute URL. Also, relative URLs navigate the URL hierarchy. The relationship (if any) between the URL hierarchy and the server's filesystem hierarchy is irrelevant.
The URL structure defines a hierarchy similar to a filesystem's hierarchy of subdirectories or folders. The segments of a URL are separated by slash characters ("/"). When navigating the URL hierarchy, the final segment of the URL (i.e., everything after the final slash) is similar to a file in a filesystem. The other segments of the URL are similar to the subdirectories and folders in a filesystem.
When resolving relative URLs (see the answer to the previous question), the browser's first step is to strip everything after the last slash in the URL of the current document. If the current document's URL ends with a slash, then the final segment (the "file") of the URL is null. If you remove the final slash, then the final segment of the URL is no longer null; it is whatever follows the final remaining slash in the URL. Removing the slash changes the URL; the modified URL refers to a different document and relative URLs will resolve differently.
For example, the final segment of the URL http://www.htmlhelp.com/faq/html/ is empty; there is nothing after the final slash. In this document, the relative URL all.html resolves to http://www.htmlhelp.com/faq/html/all.html (an existing document). If the final slash is omitted, then the final segment of the modified URL http://www.htmlhelp.com/faq/html is "html". In this (nonexistent) document, the relative URL all.html would resolve to http://www.htmlhelp.com/faq/all.html (another nonexistent document).
When they receive a request that is missing its final slash, web servers cannot ignore the missing slash and just send the document anyway. Doing so would break any relative URLs in the document. Normally, servers are configured to send a redirection message when they receive such a request. In response to the redirection message, the browser requests the correct URL, and then the server sends the requested document. (By the way, the browser does not and cannot correct the URL on its own; only the server can determine whether the URL is missing its final slash.)
This error-correction process means that URLs without their final slash will still work. However, this process wastes time and network resources. If you include the final slash when it is appropriate, then browsers won't need to send a second request to the server.
The exception is when you refer to a URL with just a hostname (e.g., http://www.htmlhelp.com). In this case, the browser will assume that you want the main index ("/") from the server, and you do not have to include the final slash. However, many regard it as good style to include it anyway.
HTML validators check HTML documents against a formal definition of HTML syntax and then output a list of errors. Validation is important to give the best chance of correctness on unknown browsers (both existing browsers that you haven't seen and future browsers that haven't been written yet).
HTML checkers (linters) are also useful. These programs check documents for specific problems, including some caused by invalid markup and others caused by common browser bugs. Checkers may pass some invalid documents, and they may fail some valid ones.
All validators are functionally equivalent; while their reporting styles may vary, they will find the same errors given identical input. Different checkers are programmed to look for different problems, so their reports will vary significantly from each other. Also, some programs that are called validators (e.g. the "CSE HTML Validator") are really linters/checkers. They are still useful, but they should not be confused with real HTML validators.
When checking a site for errors for the first time, it is often useful to identify common problems that occur repeatedly in your markup. Fix these problems everywhere they occur (with an automated process if possible), and then go back to identify and fix the remaining problems.
Link checkers follow all the links on a site and report which ones are no longer functioning. CSS checkers report problems with CSS style sheets.
According to HTML standards, each HTML document begins with a DOCTYPE declaration that specifies which version of HTML the document uses. Originally, the DOCTYPE declaration was used only by SGML-based tools like HTML validators, which needed to determine which version of HTML a document used (or claimed to use).
Today, many browsers use the document's DOCTYPE declaration to determine whether to use a stricter, more standards-oriented layout mode, or to use a "quirks" layout mode that attempts to emulate older, buggy browsers.
Many ISPs offer web space to their customers. Disk space and bandwidth will be limited, and there may be other restrictions; for example, many do not allow commercial use of this space.
There are companies and individuals offering "free" web space. Most are supported by advertising displayed on authors' web pages. There are often restrictions, as with hosting provided by ISPs to their customers.
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 US$1 per month, up to US$100 per month or more, depending upon your needs. Non-virtual Web space is typically the cheapest, offering a URL like: http://www.webhost.example/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.example/.
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.
The Internet Corporation for Assigned Names and Numbers (ICANN) maintains a list of accredited registrars . Any of the companies on this list can register a domain name for you.
Check the Terms of Service (TOS) agreement for your hosting service. It almost certainly prohibits interfering with the advertisements they add to your web pages. If you use some trick to block their advertisements on your own, then your hosting service may delete your account for violating its TOS.
However, there may be other options. Some hosting services will remove the advertisements if you pay a small monthly fee. Others will remove their default pop-up advertisements if you add static banners yourself.
There is no single technique, but a number of factors can help.
<TITLE>, use meaningful headings
(<H1>, <H2>, and so on), and provide
meaningful ALT text for images.
<META NAME="keywords" CONTENT="..."> tags that appear in
the <HEAD> part of your documents.
However, META keywords have been used to trick search engines, so many will
ignore your keywords list if you repeat a given keyword too often.
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 trickery.
<META NAME="description" CONTENT="..."> tag in the
<HEAD> part of your documents,
then some search engines will use the content of this tag as your site's
description when displaying search results.
This won't affect your ranking in searches, but it can help search engine
users understand what your site offers when a search does find your site.
The CONTENT attribute of the META keywords and description tags may contain up to 1022 characters, but no markup other than entities.
You might want to preview your site with a text-only browser like Lynx, to get an idea of how your site appears to search engines.
Finally, note that some search engines ignore sites hosted by well-known free hosting services. Other search engines index only a certain number of documents per server, so while early customers of free hosting services may be indexed, later customers may be ignored.
The Robots Exclusion Protocol allows Web site administrators to specify parts of their sites that robots should not visit by providing a /robots.txt document.
The Robots META tag allows HTML authors to specify whether robots should index a document, and whether robots should harvest additional URLs from a document. The Robots META tag requires no server administration.
The most reliable way is to configure the server to send out a redirection instruction when the old URL is requested. Then the browser will automatically get the new URL. This is the fastest and most efficient way, and is the only way described here that can convince indexing robots to phase out the old URL. For configuration details consult your server admin or documentation (with NCSA or Apache servers, use a Redirect statement in .htaccess).
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:
<meta http-equiv="Refresh" content="[x]; URL=[newURL]">
Password protection is done through HTTP authentication. The configuration details vary from server to server, so you should read the authentication section of your server documentation. Contact your server administrator if you need help with this.
JavaScript password scripts provide only a facade of security. At a fundamental level, they work in one of two ways. Some scripts convert the password into a URL, which keeps the document secret by limiting the number of people who know its URL. Some scripts check the password and then go to a specific URL, which protects the document only from those who don't view the JavaScript source to get the URL of the document. Neither mechanism is really secure.
Browsers cache web documents; they store local copies of documents to speed up repeated references to documents that haven't changed. Also, many browsers are configured to use public proxy caches, which serve many users (e.g., all customers of an ISP, or all employees behind a corporate firewall). To effectively control how your documents are cached you must configure your server to send appropriate HTTP headers.
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.
The configuration details vary from server to server, so check your server documentation.
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.
You cannot interfere with the browser's right-click options with HTML. Sometimes, JavaScript can do this, however:
You can't. URLs are fundamental to navigation on the WWW. The URL is necessary for the browser to be able to retrieve your document. It is impossible to hide the URL of a resource from the browser.
With that said, it is possible to somewhat obscure URLs via a misfeature of frames.
Many browsers identify themselves when they request a document. A CGI script will have this information available in the HTTP_USER_AGENT environment variable, and it can use that to send out a version of the document which is optimized for that browser.
Keep in mind not all browsers identify themselves correctly. For example, Microsoft Internet Explorer identifies itself as Netscape Navigator, and many other browsers identify themselves as Microsoft Internet Explorer.
And of course, if a cache proxy keeps a version intended for one brower, someone with another browser may get that version, rather than the version intended for the other browser.
For these reasons and others, it is not a good idea to play the browser guessing game.
You can't. Although each request for a document is usually logged with the name or address of the remote host, the actual username is almost never logged as well. This is mostly because of performance reasons, as it would require that the server uses the ident protocol to see who is on the other end. This takes time. And if a cache proxy is doing the request, you don't get anything sensible.
But just stop to think for a minute... would you really want every single site you visit to know your email address? Imagine the loads of automated thank you's you would be receiving. If you visited 20 sites, you would get at least 20 emails that day, plus no doubt they would send you invitations to return later. It would be a nightmare as well as an invasion of privacy!
In Netscape 2.0, it was possible to automatically submit a form with a mailto as action, using JavaScript. This would send email to the document's owner, with the address the visitor configured in the From line. Of course, that can be "mickey.mouse@disney.com". This was fixed by Netscape 2.01.
The most reliable way is to put up a form, asking the visitor to fill in his email address. To increase the chances that visitors will actually do it, offer them something useful in return.
If no browser displays your custom 404 Not Found messages, then your server probably is not configured properly.
If only Internet Explorer ignores your custom 404 Not Found messages, then you've been caught by its "friendly" HTTP error messages. When a special HTTP response (e.g., a 404 Not Found response) is shorter than 512 bytes, Internet Explorer substitutes its own message for the one delivered by the server. As a user of Internet Explorer, you can disable this feature in the "Advanced" options panel. As a web author, your only recourse is to make your 404 Not Found message longer.
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. A preprocessor converts its source into a plain HTML document that you publish on your server. In contrast, documents that use server-side inclusion are processed every time the document is retrieved from the server.
Preprocessing techniques include the C preprocessor and other generic text manipulation methods, and several HTML-specific processors.
Beware of making your "source code" non-portable. Also, the HTML can only be validated after preprocessing, 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 preprocessing 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" -->However, 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).
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).
Another approach is to create a database-backed site, as described in Philip and Alex's Guide to Web Publishing. A simple change to the database template instantly changes the whole site.
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 "&" and "<" (in the HTML document).
Browsers don't allow web authors to download and run arbitrary programs on the client system, because that would be an unacceptable security risk. Users would be unable to visit untrusted web sites safely.
You can link to an executable program file, allowing users to download it. Users could then choose to run the program, assuming that it runs on their operating systems, and that they are not concerned about software viruses.
If you want to run the program on your web server, then check your server documentation for configuration details for server-side programs.
When client-side scripting (e.g., JavaScript) is enabled on the client system (browser), it can be used to perform computations and to manipulate the data on and appearance of a web page.
If you want to launch a specialized viewer for a particular kind of file, say Adobe Acrobat Reader when the visitor follows a link to a PDF file, then that should be handled automatically by the visitor's browser, assuming that it is configured correctly. You need only configure your server to send the file with the correct MIME type.
In HTML, characters can be represented in three ways:
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.
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.
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 HTML Validator or the W3C HTML Validation Service 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.
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.
In HTML, element and attribute names in tags are case insensitive, so it doesn't matter. The choice is just a matter of style and personal preference. (You may have noticed that this FAQ is not absolutely consistent in capitalization.) Many people prefer upper case, which makes the tags "stand out" more amongst the text, and makes it easier to find element or attribute names using an editor's search function. Others prefer lower case, which makes the tags "stand out" less amongst the text, and which is required by XHTML.
Note that 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 either 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 or a is the attribute value.
The tag is <OL TYPE="A">.)
Entity names like are sometimes incorrectly
referred to as tags.
They are all case sensitive.
For example,
É and é are two different
and valid entities, and while is a valid entity,
&NBSP; is invalid.
Note that XHTML requires all element and attribute names to be in lower case.
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 600 pixels is a reasonable width; anything wider will mean a certain fraction of users will have to scroll to see the rightmost bit. This fraction increases with your image width. (Keep in mind that not everyone uses full-screen browser windows!)
MSN TV (formerly WebTV) users have no ability to scroll horizontally, so anything beyond 544 pixels will be compressed by their browser. Other devices (especially portable devices) are 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.
There are several possibilities.
First, you may have incorrect HTML or CSS syntax. Browsers vary in their ability to guess what you meant, and different browsers recover differently from syntax errors.
Second, you may have valid HTML and CSS that different browsers interpret differently. For example, the CSS specifications allow conforming browsers to ignore certain properties and property values. Also, it is not clear from the specifications 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. This includes external style sheets, which should be sent as "text/css".
Fourth, you have have encountered a browser bug.
For example, many common browsers handle CSS better when HTML documents
include optional closing tags like </p>,
</li>, and
</td>.
Another possibility is different user option settings in the browsers.
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". Often, using the filename extension ".html" or ".htm" is all that is necessary.
If you are seeing this behavior while viewing your HTML documents on your local Windows filesystem, then your text editor may have added a ".txt" filename extension automatically. You should rename filename.html.txt to filename.html so that Windows will treat the file as an HTML document.
This is a "feature" of using frames: The browser displays the URL of the frameset document, rather than that of the framed documents.
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.
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. Here is an example:
<table align="left">
<tr><td><!-- links go here --></td></tr>
</table>
<!-- content goes here -->
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 }
Finally, a navigation strip on the left can be implemented with frames. However, frames introduce problems that are best avoided if possible.
If you want others to view your web page with specific colors, the most appropriate way is to suggest the colors with a style sheet. Cascading Style Sheets use the color and background-color properties to specify text and background colors. To avoid conflicts between the reader's default colors and those suggested by the author, these two properties should always be used together.
With HTML, you can suggest colors with the TEXT, LINK, VLINK (visited link), ALINK (active link), and BGCOLOR (background color) attributes of the BODY element.
Note that these attributes are deprecated by HTML 4. Also, if one of these attributes is used, then all of them should be used to ensure that the reader's default colors do not interfere with those suggested by the author. Here is an example:
<body bgcolor="#ffffff" text="#000000" link="#0000ff"
vlink="#800080" alink="#000080">
Authors should not rely on the specified colors since browsers allow their users to override document-specified colors.
The most appropriate way is to use suitable structural markup, and to suggest the desired color with a style sheet. If you want to specify a color for only certain cases of an element, then you can use a class to specify which cases are special. The following CSS example specifies that emphasized text with the class "special" should be green (on a white background):
em.special { color: green; background: white; }
When displayed according to this CSS ruleset, the emphasized text in the following HTML example will be displayed in green:
normal text <em class="special">emphasized text</em>
normal text
With HTML, the FONT element can also be used to suggest colors. Note that the FONT element is deprecated by HTML 4. Also, use of the FONT element brings numerous usability and accessibility problems.
In Internet Explorer 5.5, Microsoft introduced proprietary CSS properties for scrollbar colors. Since then, other browsers (e.g., KDE Konqueror, Opera) have added support for these properties. These properties are: scrollbar-3dlight-color, scrollbar-arrow-color, scrollbar-base-color, scrollbar-darkshadow-color, scrollbar-face-color, scrollbar-highlight-color, and scrollbar-shadow-color.
If you want others to view your web page with a specific font, the most appropriate way is to suggest the font rendering with a style sheet. Cascading Style Sheets use the font-family property to specify font faces.
With HTML, the BASEFONT element can be used to suggest specific fonts for the entire document.
With HTML, the FONT element can also be used to suggest specific fonts. The FONT element must be repeated inside every block-level element, since it can contain only inline (text-level) elements. Use of the FONT element brings numerous usability and accessibility problems.
Whether specifying fonts with CSS or with HTML, authors run the risk that a reader's system has a font by the same name but which is significantly different. For example, "Chicago" can be a nice text font, a display font with letters formed by "bullet holes", or a novelty font containing images of city buildings (for creating skylines).
Also, authors must either use fonts (or groups of similar fonts) that are commonly available on many systems, or provide dynamic fonts for their readers. Readers who do not have the specified font(s) installed, or who do not download the dynamic fonts provided by the author, will see a default font. Some browsers may use a less legible substitute font than their normal default font in cases where author-specified fonts are not found.
Internet Explorer supports embedded fonts with Microsoft's Web Embedding Fonts Tool (WEFT).
Use an anchor element. The HREF attribute specifies the URL of the document that you want to link to. The following example links the text "Web Authoring FAQ" to <URL:http://www.htmlhelp.com/faq/html/>:
<A HREF="http://www.htmlhelp.com/faq/html/">Web Authoring
FAQ</A>
First, label the destination of the link.
The old way to label the destination of the link was with an anchor
using the NAME attribute.
For example:
<h2><a name="section2">Section 2: Beyond
Introductions</a></h2>
The modern way to label the destination of the link is with an ID
attribute.
For example:
<h2 id="section2">Section 2: Beyond
Introductions</h2>
Second, link to the labeled destination.
The URL is the URL of the document, with "#" and the value of the NAME
or ID attribute appended.
Continuing the above examples, 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="_blank" href=...> opens a new, unnamed
window.
<a target="example" href=...> opens a new window named
"example", provided that a window or frame by that name does not already
exist.
Note that the TARGET attribute is not part of HTML 4 Strict. In HTML 4 Strict, new windows can be created only with JavaScript. (See next Q&A.) Also, 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.
With HTML, there is no way to control the size (or window decoration, or
other features) of a new window.
However, in JavaScript you can specify such details when using the
window.open() function.
Start with a normal HTML link (possibly one that opens in a new window as described in the answer to the previous question). Then use the ONCLICK attribute to open a window with the desired appearance for those readers with JavaScript supported and enabled. The following example specifies a window named "popup" that is 300 pixels by 150 pixels.
<a href="example.html" target="popup"
onclick="window.open('example.html', 'popup', 'width=300,height=150');
return false">View Foo</a>
Used in this manner, JavaScript can specify a new window with the desired appearance, without blocking access when JavaScript is unsupported/disabled.
In addition to the parameters height and
width (which take a pixel count as a value), the third
argument to the window.open() can include the following
booloean parameters (which take "yes" or "no" as
a value):
directories, location, menubar, resizable, scrollbars, status, and toolbar.
These boolean parameters control the presence of the corresponding window
decorations in the resulting window.
Once the file is uploaded to the server, you need only use an anchor reference tag to link to it. An example would be:
<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.)
You can't do any of these things reliably, because the Web doesn't work that way.
When the browser requests a document (hypertext, image, audio, multimedia, etc.), the server tells the browser what type of file it is. The server should be configured to identify a document's media type properly.
The browser then decides what to do with it. Different browsers are able to and are configured to display different types of documents themselves. Browsers are usually configured to handle other file types by using appropriate helper applications or by offering to save the document to the filesystem.
RFC 2183 describes the Content-disposition header, which can be used to suggest how the browser should handle documents. The value "inline" suggests that the document should be displayed automatically, and the value "attachment" suggests that the user should be prompted before the document is displayed (or saved). Note that this mechanism has significant security implications, which are described in the RFC.
Most browsers allow users to download to disk if they want to. If the file must be saved to disk, if there is absolutely no other way to handle it, then the MIME type could be "application/octet-stream". However, this essentially says, "I can't or won't tell you what this is." Furthermore, the MIME type "application/octet-stream" provokes incorrect behavior in MSIE's HTTP implementation. A better alternative would be a custom MIME type like "application/x-some-explanation", which avoids these problems.
This is best done with a small form:
<FORM ACTION="[URL]" METHOD=GET>
<INPUT TYPE=submit VALUE="Text on button">
</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.
You cannot do this with HTML. Going "back" means going to the previous location in your history. You could create a link to the URL specifed in the HTTP Referer header (available in the HTTP_REFERER environment variable in CGI programs), but that creates a link forward to a new location in your history. Even then, the information in the Referer header can be wrong. Some browsers incorrectly send the Referer header when the user enters a URL manually or uses a bookmark. Some never send the Referer header (which is optional).
You could use JavaScript's history.back() to create a back
button (or link).
Naturally, this only works when JavaScript is supported and enabled.
Also, it is worth noting that the only navigation tool used more frequently than the "back" function is the hyperlink. Your readers almost certainly know how to use their browsers' "back" function. Users who don't know how to use basic functions of their browsers will only be confused when various pages imitate those functions in different ways.
You cannot do this with HTML.
However, Internet Explorer 4+ supports the
window.external.AddFavorite() method, a proprietary extension
to JavaScript that opens an "Add to Favorites" dialog.
The following example avoids creating a non-functional button for those
with other browsers, or for those with JavaScript disabled:
<script type="text/javascript">
function addf() {
window.external.AddFavorite('http://www.htmlhelp.com/',
'Web Design Group'); }
if (window.external &&
typeof window.external.AddFavorite != 'undefined'){
document.write('<input type="button" ' +
'onclick="addf()" value="Bookmark WDG">'); }
</script>It is worth noting that readers who know how to use bookmarks almost certainly know how to bookmark your site independently. Likewise, the few readers who don't know how to bookmark your site probably won't know how to use bookmarks that you create for them. Users who don't know how to use basic functions of their browsers will only be confused when various pages imitate those functions in different ways.
You cannot do this with HTML.
However, some browsers support the JavaScript window.print()
method, which opens a "Print" dialog.
The following example avoids creating a non-functional button for those
with other browsers, or for those with JavaScript disabled:
<script type="text/javascript">
if (window.print) {
document.write('<input type="button" onclick="window.print()"'+
' value="Print This Page">'); }
</script>It is worth noting that readers who have printers almost certainly know how to use their browsers' print function. Users who don't know how to use basic functions of their browsers will only be confused when various pages imitate those functions in different ways.
You cannot do this with HTML. However, the JavaScript method window.close() will close a window. The following example avoids creating a non-functional button for those with JavaScript disabled:
<script type="text/javascript">
if(self.close) {
document.write('<input type="button" onclick="self.close()"'+
' value="Close This Window">'); }
</script>It is worth noting that your readers are probably familiar with their systems' standard mechanisms for closing windows. Users who don't know how to use basic functions of their browsers will only be confused when various pages imitate those functions in different ways.
Use a mailto link, for example
Send me email at
<A HREF="mailto:me@mydomain.com">me@mydomain.com</A>.
Note that any email address that you publish on the WWW like this will probably start receiving unsolicited commercial email (UCE, junk email). It's a good idea to protect your real email address (e.g., by filtering incoming email, or by using a separate address only for mailto links).
You can't, not in any reliable way. The methods that are frequently posted are not effective on all combinations of browser and email software (not even on all common combinations), and many of them have an important drawback: when they fail, the email will be lost.
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="mailto:user@site" title="Your Subject">.
Most browsers will ignore the TITLE attribute, but some minor
browsers will use it as a subject for the email message. All browsers will
send the mail.
<a href="mailto:user@site?subject=Your%20Subject">,
which puts "Your Subject" (the space is encoded as "%20") in
the "Subject" header field of the email message in most current browsers.
Note however that you will lose mail from users of older browsers, so you
should consider whether the pre-filled subject is worth lost mail.
If you want to turn off link underlining when you're looking at pages in your browser, check your browser's configuration options. For example, in Mozilla Firefox see Tools > Options... > Fonts & Colors... for the Underline links option, in Opera see Tools > Preferences... > Web pages for the Underline normal links and Underline visited links options, and in MSIE 6 see Tools > Internet Options > Advanced > Browsing for the Underline links option.
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}
You can suggest this presentation in a style sheet. First, specify colors for normal links, like this:
a:link {color: blue; background: white}
a:visited {color: purple; background: white}
a:active {color: red; background: white}Next, identify the links that you want to have different colors. You can use the CLASS attribute in your HTML, like this:
<a class="example1" href="[URL]">[link text]</a>
Then, in your style sheet, use a selector for links with this CLASS attribute, like this:
a.example1:link {color: yellow; background: black}
a.example1:visited {color: white; background: black}
a.example1:active {color: red; background: black}Alternatively, you can identify an element that contains the links that you want to have different colors, like this:
<div class="example2">...
<a href="[URL]">[link text]</a>...
<a href="[URL]">[link text]</a>...
<a href="[URL]">[link text]</a>...
</div>
Then, in your style sheet, use a selector for links in this containing element, like this:
.example2 a:link {color: yellow; background: black}
.example2 a:visited {color: white; background: black}
.example2 a:active {color: red; background: black}In your style sheet, use the hover pseudo-class to specify
a different appearance for links when the cursor is over them.
Specify the hover pseudo-class after the link and
visited pseudo-classes.
For example:
A:link { color: blue ; background: white }
A:visited { color: purple ; background: white }
A:hover { color: red ; background: white }
Your markup may include HTML syntax errors that affect links. For example, there may not be quotes around attribute values that require quotes, or there may be a missing closing quote at the end of the HREF attribute value.
Perfectly valid markup may trigger common browser bugs. For example, even though a ">" character is valid inside (quoted) attribute values, several older browsers will think the tag ends there, so the rest of the tag's attributes are displayed as normal text. Likewise, ">" characters inside comments can trigger similar browser bugs.
As another example, older versions of Netscape Navigator are known to have problems with links to named anchors when the anchors are within a table that uses the ALIGN attribute.
It is also possible that your URLs are incorrect. For example, your web authoring software may have used file URLs (e.g., file:C:\path\file.html). If so, then you should replace them with relative URLs (e.g., file.html) or http URLs (e.g., http://example.com/path/file.html).
HTML validators will find syntax errors in your markup. HTML checkers/linters can find some syntax errors and valid markup that is known to trigger some common browser bugs. Link checkers can find links to incorrect URLs.
Is there a space, #, ?, or other special character in the path or filename? Spaces are not legal in URLs. If you encode the space by replacing it with %20, your link will work.
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 specification, only alphanumerics and the special characters -_.!*'() never need to 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.
However, when this URL is used as an attribute value in an HTML
document, the "&" character must be encoded as "&", like the
following:
<a href="http://www.foo.com/foo.cgi?rhyme=Jack%26Jill&audience=child">
If you are trying to link to a particular type of file and it is not returning your desired response, chances are that the server needs to have the type configured. Talk to your system administrator about getting them to add the content type. Here is a list of common types that may need configuring:
| 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/vnd.ms-excel | Microsoft Excel spreadsheet |
| 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/css | CSS style sheet |
| 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.
Use an IMG element. The SRC attribute specifies the location of the image. The ALT attribute provides alternate text for those not loading images. For example:
<img src="logo.gif" alt="ACME Products">
Here is a simple rule of thumb:
Lots of colors? Use JPEG. Solid colors and sharp lines? Use GIF or PNG.
Different image formats compress the image data differently, and have different strengths and weaknesses. The JPEG format is good for images where colors blend smoothly from one to another. Photographs are good examples, because they usually have many subtle shadows and variations of color.
The GIF and PNG formats are good for images that have relatively few colors and no gradations. Most small web graphics fall into this category. These formats will compress these images well, and any lettering, lines, and edges in the images will remain sharp.
PNG transparency is much richer than GIF transparency, allowing partial transparency and other interesting effects. However, Internet Explorer for Windows (even version 6) doesn't support anything more than GIF-style transparency.
Note that AOL's cache proxy servers convert images to their highly compressed ART image format (*.art) files, and by default, AOL browsers are configured to use these small, low-quality versions rather than the originals.
Just use the image as the link content, like this:
<a href=...><img src=... alt=...></a>
A thumbnail image is just a copy of the full-sized image that has been modified to reduce the size of the file. It is linked to the full-sized image with a normal link:
<a href="full-sized.jpg"><img src="thumbnail.jpg" alt=...></a>
There are several techniques for reducing the size of the file for the thumbnail image, including
You will need graphics software to create thumbnail images. Freeware graphics utilities will perform all of these functions.
Thumbnail images can use multiple techniques simultaneously. For example, Jakob Nielsen advocates "Relevance-Enhanced Image Reduction", which combines resampling/resizing and cropping.
Use an image map. Client-side image maps don't require server-side processing, so response time is faster. Server-side image maps hide the link definitions from the browser, and can act as a backup for client-side image maps for the few very old browsers that support server-side image maps but not client-side image maps.
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.
In your HTML, you can specify the BORDER attribute for
the image:
<a href=...><img src=...
alt=... border="0"></a>
Or in your CSS, you can specify the border property for linked images:
a img { border: none ; }
However, note that removing the border that indicates an image is a link makes it harder for users to distinguish quickly and easily which images on a web page are clickable.
This is the result of including "white space" (spaces and newlines) before or after an IMG inside an anchor. For example:
<a href=...>
<img src=...>
</a>
may 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.
If your images are inside a table, be sure to set the BORDER, CELLSPACING, and CELLPADDING attributes to 0.
Extra space between images is often created by whitespace around
the <IMG> tag in the markup.
It is safe to use newlines inside a tag (between attributes), but not
between two tags.
For example, replace this:
<td ...>
<img src=... alt=...>
<img src=... alt=...>
</td>
with this:
<td ...><img src=... alt=...><img src=... alt=...></td>
According to the latest specifications, the two should be equivalent. However, common browsers do not comply with the specifications in this situation.
Finally, extra space between images can appear in documents that trigger the "standards" rendering mode of Gecko-based browsers like Mozilla and Firefox.
There are a number of possibilities:
<img src="example3.jpg alt=...>
<img alt="2 + 2 > 3" src="example4.png">
file:///c:/path/example5.gif).
If so, then you should replace them with
relative URLs
(e.g., example5.gif)
or http URLs
(e.g., http://server.example/path/example5.gif).
Check out the following resources:
There are two basic approaches. The most cache-friendly method is to use a normal IMG tag that refers to a CGI script that randomly redirects the browser to one of several images.
The second method is to generate the HTML dynamically using a mechanism like Server Side Includes (SSI) or CGI. This method is less cache-friendly, but it does allow the surrounding markup (e.g., HEIGHT and WIDTH attributes, or the URLs for linked/image-mapped images) to vary with the image. If your server supports SSI, the details can be found in your server documentation.
No. Character entities (©, &#nnn; and such) are permitted, though.
You can use <img align="right"> to float an image to
the right.
(Use align="left" to float it to the left.)
Any content that follows the <img> tag will
flow around the image.
Use <br clear="right"> or <br
clear="all"> to mark the end of the text that is to flow around the
image, as shown in this example:
The image in this example will float to the right.
<img align="right" src=... alt=...>
This text will wrap to fill the available space to the left of (and if the
text is long enough, below) the image.
<br clear="right">
This text will appear below the image,
even if there is additional room to its left.
The CSS float property can also be used.
With CSS, you can suggest a background image (and a background color, for those not using your image) with the background property. Here is an example:
body {
background: white url(example.gif) ;
color: black ;
}With HTML, you can suggest a background image with the BACKGROUND attribute of the BODY element. Here is an example:
<body background="imagefile.gif" bgcolor="#ffffff"
text="#000000" link="#0000ff" vlink="#800080"
alink="#000080">
If you specify a background image, you should also specify text, link, and background colors since the reader's default colors may not provide adequate contrast against your background image. The background color may be used by those not using your background image. Authors should not rely on the specified background image since browsers allow their users to disable image loading or to override document-specified backgrounds.
With CSS, you can use the background-attachment property. The background attachment can be included in the shorthand background property, as in this example:
body {
background: white url(example.gif) fixed ;
color: black ;
} Note that this CSS is supported by
Internet Explorer,
Mozilla,
Firefox
Opera,
Safari,
and other browsers.
In contrast, Microsoft's proprietary BGPROPERTIES attribute is
supported only by Internet Explorer.
With CSS, you can use the background-repeat property. The background repeat can be included in the shorthand background property, as in this example:
body {
background: white url(example.gif) no-repeat ;
color: black ;
}There are several methods, none completely satisfactory:
<dl> with <dd> tags with
preceding images (with align and suitable
alt text) and no <dt>;
this won't be as beautiful as a "real" list.
Your best option is likely a centered IMG with a line of "--" characters as ALT text:
<P ALIGN=center><IMG SRC="custom-line.gif"
ALT="--------------------"></P>
A hit counter is a small script or program that increases a number every time a document is accessed from the server.
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.
With server-side includes. Ask your webmaster if this is supported, and what the exact syntax is for your server. But this will display the local time on the server (or GMT/UTC), not the local time for the client. And if the document is cached, the date will of course be incorrect after some time. JavaScript can be used to display the local time for the client, but again, as most people already have one or more clocks on their screen, why display another one?
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 is not an HTML question; it's done with JavaScript. Check any page which has this feature, and copy the script from the source.
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.
The HTML solution is to use the ALIGN="right" attribute on paragraphs, divisions, headings, etc. This will right align your text (ragged left). Note that the ALIGN attribute is deprecated by HTML 4 in most contexts.
The CSS mechanism is to use the text-align: right property in your ruleset. This example right aligns all paragraphs with the class="note" attribute:
p.note {text-align: right}
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".) This presentation can be suggested in HTML with the ALIGN="justify" attribute. This CSS example justifies all paragraphs with the class="adcopy" attribute:
p.adcopy {text-align: justify}
Before you justify text, there are some caveats. Although justified text may look pretty, human factors analysis shows that ragged right is actually easier to read and understand. Furthermore, browser bugs and poor implementations may further reduce the legibility of your text.
Use a style sheet with the following ruleset:
P { text-indent: 5% }
Use a style sheet to set a left margin for the whole document or part of it:
/* Entire document */
BODY { margin-left: 20% }
/* Part of a document with CLASS="foo" */
.foo { margin-left: 15% }
The most appropriate way is to use a style sheet to specify margin and padding properties.
With proprietary HTML extensions, you can set the margins for certain browsers. Internet Explorer 3+ supports the TOPMARGIN and LEFTMARGIN attributes. Internet Explorer 4+ added support for the BOTTOMMARGIN and RIGHTMARGIN attributes. Navigator 4+ supports the MARGINWIDTH and MARGINHEIGHT attributes. Most other browsers ignore these proprietary extensions.
CSS and proprietary HTML can be combined. The following is effective in most browsing situations:
<body marginheight="0" topmargin="0"
marginwidth="0" leftmargin="0"
style="margin:0;padding:0">
Also note that Navigator always leaves room for a scrollbar on the right, but draws the scrollbar only when the document is long enough to require scrolling. If the document does not require scrolling, then this leaves a right "margin" that cannot be removed.
You can use a style sheet to specify page breaks. However, while page-break-before is fairly well supported by current browsers, other page-break properties (and values for page-break-before other than always) are poorly supported.
Be cautious when specifying page breaks on the Web. Differences in printing environments (fonts, font sizes, paper size, printer margins, etc.) will change the ideal locations for page breaks.
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.
This is a feature introduced by Internet Explorer 5.x.
By default, the browser requests a file named "favicon.ico" at the same
base URL as the document being bookmarked.
If it doesn't find this file, then it will try again in the root directory
of your site.
Web authors can specify a different path for the icon file with a
<link> element like this:
<link rel="SHORTCUT ICON" href="/pathname/filename.ico">
The image should be 16 by 16 pixels, in the Windows icon format.
Most browsers support the EMBED element for this, provided that the user has a suitable plug-in for the sound file. You can reach a slightly wider audience if you use BGSOUND as well. To avoid problems with browsers that support both, place the BGSOUND in a NOEMBED container:
<embed src="your_sound_file" hidden=true autostart=true>
<noembed><bgsound src="your_sound_file"></noembed>
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>
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 older versions of
Netscape Navigator have problems with them if you don't explicitly close
your TR, TD, and
TH elements.
To avoid problems, include every </tr>,
</td>, and </th> tag, even
though the HTML specifications don't require them.
Also, older versions of Netscape Navigator have problems with tables that are nested extremely deeply (e.g., tables nested ten deep). To avoid problems, avoid nesting tables more than a few deep. You may be able to use the ROWSPAN and COLSPAN attributes to minimize table nesting.
Finally, be especially sure to validate your markup whenever you use nested tables.
Small forms are sometimes placed within a TD element within a table. This can be a useful for positioning a form relative to other content, but it doesn't help position the form-related elements relative to each other.
To position form-related elements relative to each other, the entire table must be within the form. You cannot start a form in one TH or TD element and end in another. You cannot place the form within the table without placing it inside a TH or TD element. You can put the table inside the form, and then use the table to position the INPUT, TEXTAREA, SELECT, and other form-related elements, as shown in the following example.
<FORM ACTION="[URL]">
<TABLE BORDER="0">
<TR>
<TH>Account:</TH>
<TD><INPUT TYPE="text" NAME="account"></TD>
</TR>
<TR>
<TH>Password:</TH>
<TD><INPUT TYPE="password" NAME="password"></TD>
</TR>
<TR>
<TD> </TD>
<TD><INPUT TYPE="submit" NAME="Log On"></TD>
</TR>
</TABLE>
</FORM>In your HTML, use
<div class="center">
<table>...</table>
</div>In your CSS, use
div.center {
text-align: center;
}
div.center table {
margin-left: auto;
margin-right: auto;
text-align: left;
}You can use <TABLE ALIGN="right"> to float a table to
the right.
(Use ALIGN="left" to float it to the left.)
Any content that follows the closing </TABLE> tag will
flow around the table.
Use <BR CLEAR="right"> or <BR
CLEAR="all"> to mark the end of the text that is to flow around the
table, as shown in this example:
The table in this example will float to the right.
<table align="right">...</table>
This text will wrap to fill the available space to the left of (and if the
text is long enough, below) the table.
<br clear="right">
This text will appear below the table,
even if there is additional room to its left.
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 WIDTH="100%"> use the full browser width?Graphical browsers leave a narrow margin between the edge of the display area and the content.
Also note that Navigator always leaves room for a scrollbar on the right, but draws the scrollbar only when the document is long enough to require scrolling. If the document does not require scrolling, then this leaves a right "margin" that cannot be removed.
This is often caused by invalid HTML syntax. Specifically, it is often caused by loose content within the table (i.e., content that is not inside a TD or TH element). There is no standard way to handle loose content within a table. Some browsers display all loose content before or after the table. When the loose content contains only multiple line breaks or empty paragraphs, then these browsers will display all this empty space before or after the table itself.
The solution is to fix the HTML syntax errors. All content within a table must be within a TD or TH element.
On current browsers, the entire table must be downloaded and the dimensions of everything in the table must to be known before the table can be rendered. That can delay the rendering of your content, especially if your table contains images without HEIGHT or WIDTH attributes.
If any of your table's content is too wide for the available display area, then the table stretches to accomodate the oversized content. The rest of the content then adjusts to fit the oversized table rather than fitting the available display area. This can force your readers to scroll horizontally to read your content, or can cause printed versions to be cropped.
For readers whose displays are narrower than the author anticipated, fixed-width tables cause the same problems as other oversized tables. For readers whose displays are wider than the author anticipated, fixed-width tables cause extremely wide margins, wasting much of the display area. For readers who need larger fonts, fixed-width tables can cause the content to be displayed in short choppy lines of only a few words each.
Many browsers are especially sensitive to invalid syntax when tables are involved. Correct syntax is especially critical. Even with correct syntax, nested tables may not display correctly in older versions of Netscape Navigator.
Some browsers ignore tables, or can be configured to ignore tables. These browsers will ignore any layout you've created with tables. Also, search engines ignore tables. Some search engines use the text at the beginning of a document to summarize it when it appears in search results, and some index only the first n bytes of a document. When tables are used for layout, the beginning of a document often contains many navigation links that appear before than actual content.
Many versions of Navigator have problems linking to named anchors when they are inside a table that uses the ALIGN attribute. These browsers seem to associate the named anchor with the top of the table, rather than with the content of the anchor. You can avoid this problem by not using the ALIGN attribute on your tables.
If you use tables for layout, you can still minimize the related problems with careful markup. Avoid placing wide images, PRE elements with long lines, long URLs, or other wide content inside tables. Rather than a single full-page layout table, use several independent tables. For example, you could use a table to lay out a navigation bar at the top/bottom of the page, and leave the main content completely outside any layout tables.
The basic syntax for a form is:
<FORM ACTION="[URL]">...</FORM>
When the form is submitted, the form data is sent to the URL specified
in the ACTION attribute.
This URL should refer to a server-side (e.g., CGI) program that will
process the form data.
The form itself should contain
<INPUT TYPE="submit" ...> element),
The only reliable mechanism for processing form submissions is with a server-side (e.g., CGI) program. To send form data to yourself via email, you should use a server-side program that processes the form submission and sends the data to your email address.
Some web service providers make standard form-to-email programs available to their customers. Check with your service provider for details.
If you can install CGI programs on your own server, see the answer to the previous question for a list of useful resources.
If you can't run CGI programs on your own server, you can use a remotely hosted form-to-email services. Note that the provider of a remotely hosted service will have access to any data submitted via the service.
Forms that use action="mailto:..." are unreliable.
According to
the HTML specifications,
form behavior is explicitly undefined for mailto URIs (or anything else
other than HTTP URIs).
They may work one way with one software configuration,
may work other ways in other software configurations,
and may fail completely in other software configurations.
Small forms are sometimes placed within a TD element within a table. This can be a useful for positioning a form relative to other content, but it doesn't help position the form-related elements relative to each other.
To position form-related elements relative to each other, the entire table must be within the form. You cannot start a form in one TH or TD element and end in another. You cannot place the form within the table without placing it inside a TH or TD element. You can put the table inside the form, and then use the table to position the INPUT, TEXTAREA, SELECT, and other form-related elements, as shown in the following example.
<form action="[URL]">
<table border="0">
<tr>
<th scope="row">
<label for="account">Account:</label>
</th>
<td>
<input type="text" name="account" id="account">
</td>
</tr>
<tr>
<th scope="row">
<label for="password">Password:</label>
</th>
<td>
<input type="password" name="password" id="password">
</td>
</tr>
<tr>
<td> </td>
<td><input type="submit" name="Log On"></td>
</tr>
</table>
</form>HTML has no mechanism to control this. However, with CSS, you can set the margin-bottom of the form to 0. For example:
<form style="margin-bottom:0;" action=...>
You can also use a CSS style sheet to affect all the forms on a page:
form { margin-bottom: 0 ; }
The short answer is that the form should just have one
<INPUT TYPE=TEXT> and no TEXTAREA, though
it can have other form elements like checkboxes and radio buttons.
You cannot do this with HTML. However, you can include a script after the form that sets the focus to the appropriate field, like this:
<form id="myform" name="myform" action=...>
<input type="text" id="myinput" name="myinput" ...>
</form>
<script type="text/javascript">
document.myform.myinput.focus();
</script> A similar approach uses <body onload=...> to set the
focus, but some browsers seem to process the ONLOAD event before the entire
document (i.e., the part with the form) has been loaded.
Rather than a normal submit button
(<input type="submit" ...>), you can use the
image input type (<input type="image" ...>).
The image input type specifies a graphical submit button that functions
like a server-side image map.
Unlike normal submit buttons (which return a name=value pair), the image input type returns the x-y coordinates of the location where the user clicked on the image. The browser returns the x-y coordinates as name.x=000 and name.y=000 pairs.
For compatability with various non-graphical browsing environments, the VALUE and ALT attributes should be set to the same value as the NAME attribute. For example:
<input type="image" name="Send" alt="Send" value="Send"
src="send-button.gif">
For the reset button, one could use
<button type="reset" ...>, JavaScript, and/or style
sheets, although none of these mechanisms work universally.
Yes. This is part of HTML 2.0 Forms support (some early browsers did not support it, but browser coverage is now excellent).
The submit buttons must have a NAME attribute. The optional VALUE attribute can be used to specify different text for the different submit buttons.
To determine which submit button was used, you need to use different values for the NAME and/or VALUE attributes. Browsers will send to the server the name=value pair of the submit button that was used. Here is an example:
<input type="submit" name="join" value="I want to join now">
<input type="submit" name="info" value="Please send full details">
Note that if you are using image submit buttons, you need to provide different NAME attributes for them too. Also, browser behavior can be inconsistent when the form is submitted without a submit button (e.g., by hitting ENTER).
If you're unsure what results you're going to get when you submit your form, TipJar has a standard script which you can use. Code this, for example (assuming method "post"):
<form method="post"
action="http://www.tipjar.com/cgi-bin/test">
and then go through the motions of submitting your form. The TipJar server decodes the form input, and displays the result to you.
No. A form must have exactly one action. However, the server-side (e.g., CGI) program that processes your form submissions can perform any number of tasks (e.g., updating a database, sending email, logging a transaction) in response to a single form submission.
Have the server-side (e.g., CGI) program that processes the form submission send an error message if the field is not filled in properly. Ideally, this error message should include a copy of the original form with the original (incomplete or incorrect) data filled in as the default values for the form fields. The Perl CGI.pm module provides helpful mechanisms for returning partially completed forms to the user.
In addition, you could use JavaScript in the form's ONSUBMIT attribute to check the form data. If JavaScript support is enabled, then the ONSUBMIT event handler can inform the user of the problem and return false to prevent the form from being submitted.
Note that the server-side program should not rely upon the checking done by the client-side script.
No. The server-side (e.g., CGI) program that processes the form submission must handle duplicate submissions gracefully.
You could generate the form with a server-side (e.g., CGI) program that adds a hidden field with a unique session ID. Then the server-side program that processes the form submission can check the session ID against a list of previously used session IDs. If the session ID has already been used, then an appropriate action can be taken (e.g., reject the submission, or update the previously submitted data).
Ultimately, your server-side program must be smart enough to handle resubmitted data. But you can avoid getting resubmitted data by not expiring the confirmation page from form submissions. Since you want to expire pages quickly when they have transient data, you might want to avoid putting transient data on the confirmation page. You could provide a link to a database query that returns transient data though.
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>
Not all browsers support form-based file upload, so try to give alternatives where possible.
The Perl CGI.pm module supports file upload. The most recent versions of the cgi-lib.pl library also support file upload. Also, if you need to do file upload in conjunction with form-to-email, the Perl package MIME::Lite handles email attachments.
There is no way to do this in HTML only; something else must process the form. JavaScript processing will work only for readers with JavaScript-enabled browsers. CGI and other server-side processing is reliable for human readers, but search engines have problems following any form-based navigation.
Frames allow an author to divide a browser window into multiple (rectangular) regions. Multiple documents can be displayed in a single window, each within its own frame. Graphical browsers allow these frames to be scrolled independently of each other, and links can update the document displayed in one frame without affecting the others.
You can't just "add frames" to an existing document. Rather, you must create a frameset document that defines a particular combination of frames, and then display your content documents inside those frames. The frameset document should also include alternative non-framed content in a NOFRAMES element.
The HTML 4 frames model has significant design flaws that cause usability problems for web users. Frames should be used only with great care.
In the frameset document (the HTML document containing the
<frameset> <frame> tags),
make sure to name the individual frames using the
NAME attribute.
The following example creates a top frame named "navigation" and a bottom
frame named "content":
<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.) For example:
<a target="content" href=...>
To target a form submission, use the TARGET attribute of the FORM element, like this:
<form target="content" action=...>
Note that when forms are processed entirely by JavaScript, the target frame must be specified in the JavaScript. The value of the TARGET attribute is irrelevant.
Normally, the default target frame is the current frame ("_self"). To change the default target for every link/form on the page, use the TARGET attribute of the BASE element, like this:
<base target="content">
If there is no existing frame with the name you used for the
TARGET attribute, then a new browser window will be opened,
and this window will be assigned the name you used.
Furthermore, TARGET="_blank" will open a new, unnamed browser
window.
In HTML 4, 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.
Also, some browsers include a security feature that prevents documents from being hijacked by third-party framesets. In these browsers, if a document's link targets a frame defined by a frameset document that is located on a different server than the document itself, then the link opens in a new window instead.
There are two basic techniques for updating multiple frames with a
single link:
The HTML-based technique links to a new frameset document that specifies
the new combination of frames.
The JavaScript-based solution uses the onClick attribute of
the link to update the additional frame (or frames).
The HTML-based technique can link to a new frameset document with the TARGET="_top" attribute (replacing the entire frameset). However, 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">
<noframes><body>
<!-- Alternative non-framed version -->
</body></noframes>
</frameset> A link can now use the TARGET="Display"
attribute to replace simultaneously all the frames defined by the
frameset2.html document.
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).
If you are the author, this is easy. You only have to add the
TARGET attribute to the link that takes readers to the
intended 'outside' document. Give it the value of _top.
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.
When the sub-documents of a frameset state are accessed directly, they appear without the context of the surrounding frameset.
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.href.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.
"Getting framed" refers to having your documents displayed within
someone else's frameset without your permission.
This can happen accidentally (the frameset author forgot to use
TARGET="_top" when linking to your document) or intentionally
(the frameset author wanted to display your content with his/her own
navigation or banner frames).
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.
One 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) {
if (window.location.href.replace)
top.location.replace(self.location.href);
else
top.location.href=self.document.href;
}
</script>An alternative script is
<script type="text/javascript">
function breakOut() {
if (self != top)
window.open("my URL","_top","");
}
</script>
</HEAD>
<BODY onLoad="breakOut()">This is unfortunately not possible. When you navigate through a site using frames, the URL will not change as the documents in the individual frames change. This means that there is no way to indicate the combination of documents that make up the current state of the frameset.
The author can provide multiple frameset documents, one for
each combination of frame content.
These frameset documents can be generated automatically, perhaps
being created on the fly by a CGI program.
Rather than linking to individual content documents, the author can link to
these separate frameset documents using TARGET="_top".
Thus, the URL of the current frameset document will always specify the
combination of frames being displayed, which allows links, bookmarks, etc.
to function normally.
Removing the border around frames involves both not drawing the frame
borders and eliminating the space between the frames.
The most widely supported way to display borderless frames is
<FRAMESET ... BORDER=0 FRAMEBORDER=0 FRAMESPACING=0>.
Note that these attributes are proprietary and not part of the HTML 4.01 specifications. (HTML 4.01 does define the FRAMEBORDER attribute for the FRAME element, but not for the FRAMESET element.) Also, removing the border around a frame makes it difficult to resize it, as this border is also used in most GUIs to change the size of the frame.
The only way to have a frame with a vertical scrollbar but without a
horizontal scrollbar is to define the frame with
SCROLLING="auto" (the default), and to have content that does
not require horizontal scrolling.
There is no way to specify that a frame should have one scrollbar but not
the other.
Using SCROLLING="yes" will force scrollbars in both directions
(even when they aren't needed), and
using SCROLLING="no" will inhibit all scrollbars (even when
scrolling is necessary to access the frame's content).
There are no other values for the SCROLLING attribute.
The title displayed is the title of the frameset document
rather than the titles of any of the
pages within frames.
To change the title displayed, link to a new frameset document using
TARGET="_top" (replacing the entire frameset).
Older versions of Netscape Navigator seems to convert pixel-based frame dimensions to whole percentages, and to use those percentage-based dimensions when laying out the frames. Thus, frames with pixel-based dimensions will be rendered with a slightly different size than that specified in the frameset document. The rounding error will vary depending on the exact size of the browser window.
Furthermore, Navigator seems to store the percentage-based dimensions internally, rather than the original pixel-based dimensions. Thus, when a window is resized, the frames are redrawn based on the new window size and the old percentage-based dimensions.
There is no way to prevent this behavior. To accomodate it, you should design your site to adapt to variations in the frame dimensions. This is another situation where it is a good idea to accomodate variations in the browser's presentation.
The fundamental problem with the design of frames is that framesets create states in the browser that are not addressable. Once any of the frames within a frameset changes from its default content, there is no longer a way to address the current state of the frameset. It is difficult to bookmark - and impossible to link or index - such a frameset state. It is impossible to reference such a frameset state in other media. When the sub-documents of such a frameset state are accessed directly, they appear without the context of the surrounding frameset. Basic browser functions (e.g., printing, moving forwards/backwards in the browser's history) behave differently with framesets. Also, browsers cannot identify which frame should have focus, which affects scrolling, searching, and the use of keyboard shortcuts in general.
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.
Search engines can link directly to framed content documents, but they cannot link to the combinations of frames for which those content documents were designed. This is the result of a fundamental flaw in the design of frames.
Search engines try to provide their users with links to useful documents. Many framed content documents are difficult to use when accessed directly (outside their intended frameset), so there is little benefit if search engines offer links to them. Therefore, many search engines ignore frames completely and go about indexing more useful (non-framed) documents.
Search engines will index your <NOFRAMES> content,
and any content that is accessible via your <NOFRAMES>
content.
Such content should be useful when accessed directly from a search-engine
link.
All rights reserved.