- Getting Started
- What is ... and where can I learn more
about it?
- Where can I find a list of all the current
HTML tags?
- How can I show HTML examples without them
being interpreted as part of my document?
- How do I get a ... character in my HTML?
- Should I put quotes around attribute values?
- How can I include comments in HTML?
- How can I avoid using the whole URL?
- Should I end my URLs with a slash?
- How can I check for errors?
- What is a DOCTYPE? Which one do I use?
- Web Publishing
- Where can I put my newly created Web
pages?
- How can I get my own domain name?
- How can I block my hosting service's advertisements?
- Where can I announce my site?
- Is there a way to get indexed better
by the search engines?
- How do I prevent my site from being indexed
by search engines?
- How do I redirect someone to my new page?
- How do I password protect my web site?
- How do I stop my page from being cached?
- How do I hide my source?
- How do I hide my URL?
- How do I detect what browser is being
used?
- How do I get my visitors' email addresses?
- Why is my custom 404 message not displayed?
- Web Design
- How do I include one file in another?
- Which should I use, &entityname;
or &#number; ?
- Should I use lower case or upper case for
tags?
- For what screen size should I write?
- Why does my page display fine in
browser X but incorrectly or not at all in browser Y?
- Why does the browser show my plain HTML
source?
- How do I freeze the URL displayed in a
visitor's browser?
- How do I put links along the left side
of my page?
- Hyperlinks
- How do I create a link?
- How do I link to a location in the middle
of an HTML document?
- How do I create a link that opens a new
window?
- How do I create a link that opens
a new window of a specific size?
- How do I create a button which acts like
a link?
- How do I create a back button on my page?
- How do I create a button that automatically
bookmarks my site?
- How do I create a button that prints
my page?
- How do I create a link that sends me
email?
- How do I specify a subject for a mailto
link?
- How do I link an image to something?
- How do I eliminate the blue border around
linked images?
- How do I link different parts of an image
to different things?
- How do I turn off underlining on my
links?
- How can I have two sets of links with
different colors?
- How can I make links change when the cursor
is over them?
- Why are my hyperlinks coming out all
wrong or not loading?
- Why does my link work in Internet
Explorer but not in Netscape?
- Other Media
- How do I let people download a file
from my page?
- Why did my link to a ... file download
a bunch of characters instead?
- How do I force the browser to show/play
a file itself?
- How do I force the browser to download
a file?
- How do I make animated GIFs?
- How can I create a thumbnail image that
is linked to the full-sized image?
- Why am I getting a colored whisker
to the left or right of my image?
- How can I display random images?
- Why are my images coming out all wrong
or not loading?
- How do I prevent people from saving
my images?
- Can I put markup in ALT text?
- How do I get an audio file to play automatically
when someone visits my site?
- How can I strip all the HTML from a document
to get plain text?
- Presentational Effects
- How can I make a custom rule?
- How can I make a list with custom bullets?
- Where can I get a "hit counter"?
- How do I display the current date or time
in my document?
- How do I get scrolling text in the
status bar?
- How do I right align text or images?
- How do I eliminate the space around/between
my images?
- How do I indent the first line in
my paragraphs?
- How do I indent a lot of text?
- How do I eliminate the margins around
my page?
- How do I do a page break?
- How can I specify fonts in my Web pages?
- How can I specify colors?
- How do I change the color of some
text?
- How can I specify background images?
- How do I have a fixed background image?
- How do I have a non-tiled background
image?
- How can I have a custom icon when people
bookmark my site?
- HTML Tables
- How do I make a table which looks
good on non-supporting browsers?
- Can I nest tables within tables?
- How can I use tables to structure forms?
- How do I center a table?
- How do I align a table to the right (or
left)?
- Can I use percentage values for <TD
WIDTH=...>?
- Why doesn't <TABLE WIDTH="100%">
use the full browser width?
- Why is there extra space before or after
my table?
- Are there any problems with using
tables for layout?
- HTML Forms
- How do I use forms?
- How do I get form data emailed to me?
- How can I use tables to structure forms?
- How do I make a form so it can be submitted
by hitting ENTER?
- How do I set the focus to the first form
field?
- How can I make a form with custom buttons?
- Can I have two or more Submit buttons
in the same form?
- Can I have two or more actions in the
same form?
- Can I require that some fields be
filled in?
- How can I allow file uploads to my web
site?
- How can I use forms for pull-down navigation
menus?
- HTML Frames
- What are frames? What is a frameset?
- How do I make a link or form in one
frame update another frame?
- Why do my links open new windows rather
than update an existing frame?
- How do I update two frames at once?
- How do I get out of a frameset?
- How do I make sure my framed documents
are displayed inside their frameset?
- Is there a way to prevent getting framed?
- How do I specify a specific combination
of frames instead of the default document?
- How do I remove the border around
frames?
- How do I make a frame with a vertical
scrollbar but without a horizontal scrollbar?
- How do I change the title of a framed
document?
- Why aren't my frames the exact size I
specified?
- Are there any problems with using
frames?
- Do search engines dislike frames?
HTML
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.
CSS
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.
SGML
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).
XML
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.
XHTML
Extensible HyperText Markup Language is a reformulation
of HTML as an XML application. Because it is an XML application, the
syntax requirements of XHTML are more restrictive than those of HTML.
Otherwise, XHTML 1.0 mirrors the functionality of HTML 4.01.
SSI ("SHTML")
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.
CGI
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.
The current 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.
Recommended materials on HTML 4:
Recommended materials on HTML 3.2:
Some materials on browser-specific versions of 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.
The next Q&A addresses the more general issue of representing
arbitrary characters in HTML documents.
The answer to the previous question addressed
the special case of the less-than ('<'), greater-than ('>'), and
ampersand ('&') characters. In general, the safest way to do HTML
is in (7-bit) US-ASCII, and expressing characters from the upper half
of the 8-bit code by using HTML entities. See the answer to "Which
should I use, &entityname; or &#number; ?"
Working with 8-bit characters can also be successful in many practical
situations: Unix and MS-Windows (using Latin-1), and also Macs (with
some reservations).
The available characters are those in ISO-8859-1, listed at <URL:http://www.htmlhelp.com/reference/charset/>.
On the Web, these are the only characters widely supported. In particular,
characters 128 through 159 as used in MS-Windows are not part of the
ISO-8859-1 code set and will not be displayed as Windows users expect.
This includes the em dash, en dash, curly quotes, bullet, and trademark
symbol; neither the actual character nor &#nnn; is correct. (See
the last paragraph of this answer for more about those characters.)
On platforms whose own character code isn't ISO-8859-1, such as MS
DOS, Macs, there may be problems: you'd have to use text transfer methods
that convert between the platform's own code and ISO-8859-1 (e.g Fetch
for the Mac), or convert separately (e.g GNU recode). Using 7-bit ASCII
with entities avoids those problems, and this FAQ is too small to cover
other possibilities in detail. Mac users - see the notes at the above
URL.
If you run a web server (httpd) on a platform whose own character code
isn't ISO-8859-1, such as a Mac, or IBM mainframe, it's the job of the
server to convert text documents into ISO-8859-1 code when sending them
to the network.
If you want to use characters outside of the ISO-8859-1 repertoire,
you must use HTML 4 rather than HTML 3.2. See the HTML 4.01 Recommendation
at <URL:http://www.w3.org/TR/html4/>
and the Babel site at <URL:http://babel.alis.com:8080/>
for more details. Another useful resource for internationalization issues
is at <URL:http://ppewww.ph.gla.ac.uk/%7Eflavell/charset/>.
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). See <URL:http://www.w3.org/TR/html4/intro/sgmltut.html#attributes>
for the exact rules.
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:
- Escape any quotes inside the value with " so you don't terminate
the value prematurely: ALT="the "King of Comedy" takes
a bow". (" is not part of the formal HTML 3.2 spec, though
most current browsers support it.)
- Use single quotes to enclose the attribute value: ALT='the "King
of Comedy" takes a bow'.
Both these methods are correct according to the spec 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".
A comment declaration starts with "<!", followed by
zero or more comments, followed by ">". A comment starts
and ends with "--", and does not contain any occurrence
of "--" between the beginning and ending pairs. This means
that the following are all legal HTML comments:
<!-- Hello --><!-- Hello -- -- Hello--><!----><!------ Hello --><!>
But some browsers do not support the full syntax, so we recommend you
follow this simple rule to compose valid and accepted comments:
An HTML comment begins with "<!--", ends with "-->"
and does not contain "--" or ">" anywhere
in the comment.
See <URL:http://www.htmlhelp.com/reference/wilbur/misc/comment.html>
for a more complete discussion.
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.
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.
- The browser strips everything after the last slash in the base document's
URL and appends the relative URL to the result.
- Each "." segment is deleted (e.g., ./all.html is the
same as all.html, and ./ refers to the current
"directory" level in the URL hierarchy).
- Each ".." segment moves up one level in the URL hierarchy; the ".."
segment is removed, along with the segment that precedes it (e.g.,
foo/../all.html is the same as all.html, and
../ refers to the parent "directory" level in the URL hierarchy).
Some examples may help make this clear. If the base document is <URL:http://www.htmlhelp.com/faq/html/basics.html>,
then
- all.html and ./all.html
- refer to <URL:http://www.htmlhelp.com/faq/html/all.html>
- ./
- refers to <URL:http://www.htmlhelp.com/faq/html/>
- ../
- refers to <URL:http://www.htmlhelp.com/faq/>
- ../cgifaq.html
- refers to <URL:http://www.htmlhelp.com/faq/cgifaq.html>
- ../../reference/
- refers to <URL:http://www.htmlhelp.com/reference/>
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.
For a full discussion of the proper form of URLs, see <URL:http://www.w3.org/Addressing/>.
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.
For a full discussion of the proper form of URLs, see <URL:http://www.w3.org/Addressing/>.
Various software is available to find errors in your web documents
automatically. HTML validators are programs that 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 linters (checkers) are also useful. These programs check documents
for specific portability problems, including some caused by invalid
markup and others caused by common browser bugs. Linters may pass some
invalid documents, and they may fail some valid ones.
All validators are functionally equivalent; while they may have different
reporting styles, they will find the same errors given identical input.
Different linters 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.
While checking for errors in the HTML, it is also a good idea to check
for hypertext links which are no longer valid. There are several link
checkers available for various platforms which will follow all links
on a site and return a list of the ones which are non-functioning.
You can find a list of validators, linters, and link checkers at <URL:http://www.htmlhelp.com/links/validators.htm>.
Especially recommended is the use of an SGML-based validator such as
the WDG HTML Validator <URL:http://www.htmlhelp.com/tools/validator/>
or W3C HTML Validation Service <URL:http://validator.w3.org/>.
According to HTML standards, each HTML document begins with a DOCTYPE
declaration that specifies which version of HTML the document uses.
The DOCTYPE declaration is useful primarily to SGML-based tools like
HTML validators, which must know which version of HTML to use in checking
the document's syntax. Browsers generally ignore DOCTYPE declarations.
See <URL:http://www.htmlhelp.com/tools/validator/doctype.html>
for information on choosing an appropriate DOCTYPE declaration.
Note that the public identifier section of the DOCTYPE declaration
is case sensitive. Some versions of Netscape Composer are known to insert
the lower-case "-//w3c//dtd html 4.0 transitional//en", rather than
the correct mixed-case "-//W3C//DTD HTML 4.0 Transitional//EN".
Bluedomino.com offers Unlimited Web Hosting and Free CoffeeCup Software
when you sign up.
Check it out at www.bluedomino.com
2.2. How can I get my own domain
name?
See Above (2.1).
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.
- Search engines index the textual content of your site, so use a
meaningful
<TITLE>, use meaningful headings (<H1>,
<H2>, and so on), and provide meaningful
ALT text for images.
- Many search engines ignore frames, so
avoid them, and be sure to provide useful NOFRAMES content if you
do use them.
- Most earch engines ignore image maps, forms, and JavaScript, so
make sure that navigating your site doesn't depend on them. Provide
normal links for site navigation.
- Avoid using META refresh, because many search engines penalize sites
that use it (META refresh has been used to trick search engines).
- The indexing programs of some search engines (including AltaVista
and Infoseek) will also take into account
<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.
- If you include a
<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. Search Engine
Watch at <URL:http://searchenginewatch.com/>
is a Web site dedicated to search engines and strategies for Web page
authors.
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.
See <URL:http://info.webcrawler.com/mak/projects/robots/exclusion.html>.
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:
- Put up a small page with text like "This page has moved to http://new.url/
-- please adjust your bookmarks."
- A Netscape and MSIE solution, which doesn't work on many other browsers
(and screws up the "back" button in Netscape) is:
<META HTTP-EQUIV="Refresh" CONTENT="x; URL=new.URL">
which will load the new URL after x seconds. This should go in the
HEAD of the document. But if you do this, also include a short text
saying "Document moved to new URL so-and-so" for other browsers. (The
screwing-up bit refers to the fact that if you press "Back" after
you have been redirected, you will be taken to the document with the
META refresh. Then the refresh will be activated, and so you'll jump
to the page you just tried to leave.)
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.
For example, if your server is Apache, see <URL:http://www.apache.org/docs/misc/FAQ.html#user-authentication>.
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. For
more information, see the HTTP 1.1 draft (see <URL:http://www.w3.org/Protocols/>).
The configuration details vary from server to server, so check your
server documentation. For example, if your server is Apache, see <URL:http://www.apache.org/docs/mod/mod_expires.html>
for information about setting the Expires header, and <URL:http://www.apache.org/docs/mod/mod_headers.html>
for information about setting other headers.
The Pragma header is generally ineffective because its
meaning is not standardized and few caches honor it. Using <META
HTTP-EQUIV=...> elements in HTML documents is also generally
ineffective; some browsers may honor such markup, but other caches ignore
it completely.
Further discussion can be found at <URL:http://www.mnot.net/cache_docs/>.
You can't. The HTML source is necessary for the browser to display
your document; you must send the complete, unencrypted source to the
browser. Even if a particular browser doesn't have a "View Source" feature,
there are many that do, and someone can always retrieve the document
by hand (using telnet) or from the browser's cache.
There are tricks that make it more difficult for some readers to view
or save your source (e.g., tricking newbies into thinking there's nothing
there by adding dozens of blank lines to the beginning of the document,
or using JavaScript to trap right-button mouse events). However, just
as with tricks that try to protect images from
being saved, these tricks have very limited effectiveness and can
cause various problems for law-abiding users.
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.
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. Microsoft
Internet Explorer, for example, claims to be "Mozilla" to get at Netscape
enhanced documents.
And of course, if a cache proxy keeps the Netscape enhanced document,
someone with another browser will also get this document if he goes
through the cache.
For these reasons and others, it is not a good idea to play the browser
guessing game.
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.
Recent versions of Internet Explorer default to "friendly" HTTP error
messages. When a special HTTP response (e.g., a 404 response) is shorter
than 512 bytes, the browser 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 the error page larger.
HTML itself offers no way to seamlessly incorporate the content
of one file into another.
True dynamic inclusion of one HTML document (even in a different "charset")
into another is offered by the OBJECT
element, but due to shortcomings of browser versions in current use,
it seems unwise to rely on this yet for essential content. The same
can be said for IFRAME.
Two popular ways of including the contents of one file seamlessly into
another for the WWW are preprocessing and server-side
inclusion.
Preprocessing techniques include the C preprocessor
and other generic text manipulation methods, and several HTML-specific
processors. There is a nice annotated list of HTML preprocessors at
<http://www.idocs.com/wmr/software/html+preprocessors/>.
Beware of making your "source code" non-portable. Also, the HTML can
only be validated after pre-processing, so the typical cycle "Edit,
Check, Upload" becomes "Edit, Preprocess, Check, Upload" (here, "Check"
includes whatever steps you use to preview your pages: validation, linting,
management walk-through etc.; and "upload" means whatever you do to
finally publish your new pages to the web server).
A much more powerful and versatile pre-processing technique is to use
an SGML processor (such as the SP
package) to generate your HTML; this can be self-validating.
Examples of server-side inclusion are Server Side Includes (SSI, supported
by Apache, NCSA,
and other web servers), and Microsoft's Active
Server Pages (ASP, supported by MS IIS). Processing occurs
at the time the documents are actually retrieved. A typical inclusion
looks like
<!--#include virtual="/urlpath/to/myfile.htm" -->
but be sure to consult your own server's documentation, as the details
vary somewhat between implementations. The whole directive gets replaced
by the contents of the specified file.
Using server-side inclusion (a potentially powerful tool) merely as
a way to insert static files such as standard header/footers has implications
for perceived access speed and for server load, and is better avoided
on heavily loaded servers. If you use it in this way, consider making
the result cacheable (e.g., via "XBitHack
full" on Apache; setting properties of the "Response" object in ASP).
Details are beyond the scope of this FAQ but you may find this useful:
http://www.mnot.net/cache_docs/
Proper HTML validation of server-side inclusion is only possible after
server-side processing is done (e.g. by using an on-line
validator that retrieves the document from the server).
Finally, note that if the included file contains arbitrary plain text,
then some provision must be made to convert the characters "&" and
"<" (in the plain text file) to the entities "&" and "<"
(in the HTML document).
In HTML, characters can be represented in three ways:
- a properly coded character, in the encoding specified by the "charset"
attribute of the "Content-type:" header;
- a character entity (&entityname;), from the appropriate HTML
specification (HTML 2.0/3.2, HTML 4, etc.);
- a numeric character reference (&#number;) that specifies the
Unicode reference of the desired character. We recommend
using decimal references; hexadecimal references are less widely supported.
In theory these representations are equally valid. In practice, authoring
convenience and limited support by browsers complicate the issue.
HTTP being a guaranteed "8-bit clean" protocol, you can safely send
out 8-bit or multibyte coded characters, in the various codings that
are supported by browsers.
A. HTML 2.0/3.2 (Latin-1)
By now there seems no convincing reason to choose &entityname;
versus &#number;, so use whichever is convenient.
If you can confidently handle 8-bit-coded characters this is fine too,
probably preferred for writing heavily-accented languages. Take care
if authoring on non-ISO-8859-based platforms such as Mac, Psion, IBM
mainframes etc., that your upload technique delivers a correctly coded
document to the server. Using &-representations avoids such problems.
B. A single repertoire other than Latin-1
In such codings as ISO-8859-7 Greek, koi8-r Russian Cyrillic, and Chinese,
Japanese and Korean (CJK) codings, use of coded characters is the most
widely supported and used technique.
Although not covered by HTML 3.2, browsers have supported this quite
widely for some time now; it is a valid option within the HTML 4 specifications--use
a validator such as the WDG's online HTML Validator at <URL:http://www.htmlhelp.com/tools/validator/>
which supports HTML 4 and understands different character encodings.
Browser support for coded characters may depend on configuration and
font resources. In some cases, additional programs called "helpers"
or "add-ins" supply virtual fonts to browsers.
"Add-in" programs have in the past been used to support numeric references
to 15-bit or 16-bit code protocols such as Chinese Big5 or Chinese GB2312.
In theory you should be able to include not only coded characters but
also Unicode numeric character references, but browser support is generally
poor. Numeric references to the "charset-specified" encoding may appear
to produce the desired characters on some browsers, but this is wrong
behavior and should not be used. Character entities are also
problematical, aside from the HTML-significant characters <,
& etc.
C. Internationalization per HTML 4
Recent versions of the popular browsers have support for some of these
features, but at time of writing it seems unwise to rely on this when
authoring for a general audience. If you'd like to explore the options,
you can find comprehensive background documentation and some practical
suggestions at
Tags are case insensitive, so it doesn't matter. This is just a matter
of style. (You may have noticed that this FAQ is not absolutely consistent
in capitalization.) Many people prefer upper case, as it makes the tags
"stand out" better amongst the text.
Attribute names can also be upper or lower case, as you prefer. But
some attribute values are case sensitive. For example, <OL
TYPE=A> and <OL type=A> are the same, but
<OL TYPE=a> is different from both of them. (For
clearer communication, it's worth getting the terminology right. In
this example, OL is the element, TYPE is the
attribute name, and A and a are the attribute
values. The tag is <OL TYPE=A>.)
Entity names like are sometimes incorrectly
referred to as tags. They are all case sensitive. For example, É
and é are two different and valid entities;
&NBSP; is invalid.
Note that XHTML 1.0 (a
reformulation of HTML 4.01 as an XML 1.0 application) requires element
and attribute names to be in lower case.
HTML does not depend on screen size. Normally, the text will be wrapped
by the browser when the end of its display area is encountered. (Note
that graphical browsers are often used with windows that are smaller
than the full area of the screen.)
Preformatted lines (text within <PRE> elements)
should only ever exceed 70 characters if the nature of the content makes
it unavoidable. Longer lines will cause ugly line breaks on text-mode
browsers, and will force horizontal scrolling on graphical browsers.
Readers strongly dislike horizontal scrolling, except where they can
realise that the nature of the content made it inevitable.
Images cannot be wrapped, so you have to be careful with them. It
seems that 400 or 500 pixels is a reasonable width; anything above 600
will mean a certain percentage of users will have to scroll to see the
rightmost bit. This percentage increases with your image width. Keep
in mind that not everyone runs his browser at full screen!
(WebTV users have no ability to scroll horizontally, so anything beyond
544 pixels will be compressed by their browser. Some other devices may
be even more limited.)
The use of tables for layout, especially
when fixed-width cells are used, is the most usual single factor that
prevents pages from adapting to various window widths. This is explained
in detail at <URL:http://www.dantobias.com/webtips/tables.html>.
There are several possibilities.
First, you may have some incorrect HTML. Browsers vary in their ability
to guess what you meant. For instance, Netscape is much more fussy about
tables than MS Internet Explorer, so a page with incorrect tables may
look fine in MSIE but not display at all in Netscape. See the answer
to "How can I check for errors?" for tips
on finding your HTML errors. (In fact, even correct nested tables may
not display correctly in Netscape. See the answer to "Can
I nest tables within tables?" for what you can do about that.)
Second, you may have valid HTML that different browsers interpret differently.
For instance, it is not clear from the spec what should be done with
a string of characters. Some browsers will collapse them
for rendering as a single space; others will render one space per .
Third, your server may be sending incorrect MIME types for some of
your files. Internet Explorer incorrectly ignores server-provided MIME
types, so it sometimes "does the right thing" when the server is misconfigured.
Other browsers correctly heed the server-provided MIME types, so they
will reveal server misconfigurations.
Other possibilities are a bug in one or the other browser, or different
user option settings.
See also the answers to "Why are my hyperlinks
coming out all wrong or not loading?" and "Why
are my images coming out all wrong or not loading?"
If Microsoft Internet Explorer displays your document normally, but
other browsers display your plain HTML source, then most likely your
web server is sending the document with the MIME type "text/plain".
Your web server needs to be configured to send that filename with the
MIME type "text/html". See the answer to "Why
did my link to a ... file download a bunch of characters instead?"
for more details.
This is a "feature" of using frames: The browser displays the URL
of the frameset document, rather than that of the framed documents.
(See the answer to the question "How do I specify
a specific combination of frames instead of the default document?").
However, this behavior can be circumvented easily by the user. Many
browsers allow the user to open links in their own windows, to bookmark
the document in a specific frame (rather than the frameset document),
or to bookmark links. Thus, there is no reliable way to stop a user
from getting the URL of a specific document.
Furthermore, preventing users from bookmarking specific documents
can only antagonize them. A bookmark or link that doesn't find the desired
document is useless, and probably will be ignored or deleted.
A common way to do this is to use a two-column table with your links
in the left column and your content in the right column. This is often
combined with a background image that creates a colored strip on the
left behind the links. The background image can tile vertically, but
to avoid horizontal tiling the image should be extremely wide (e.g.,
1600 pixels).
A variation of this technique (which minimizes some of the problems
with using tables for layout) uses a single-cell table with ALIGN="left".
Only the links go inside the table, which floats to the left. The document's
content wraps to fill the space remaining to the right of and below
the table.
Layout tables can be avoided entirely by using CSS. The navigation
links and the page's main content are placed inside separate DIV
elements, and then CSS is used to position these DIV
elements relative to each other. The style sheet can use a smaller background
image that repeats vertically and is aligned along the left, for example:
body { color: black; background: white url(foo.gif) repeat-y
left }
More information about Cascading Style Sheets can be found at: http://www.htmlhelp.com/reference/css/
Finally, a navigation strip on the left can be implemented with frames.
However, frames introduce problems that
are best avoided if possible.
See the answer to the question, "How do I
include one file in another?" for suggestions that will help you
maintain common content like navigation links across all the documents
at your site.
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>
For more information on links and the anchor element, see: http://www.htmlhelp.com/reference/html40/special/a.html
First, identify the destination of the link with a named anchor (an
anchor that uses the NAME attribute). For example:
<H2><A NAME="section2">Section 2: Beyond Introductions</A></H2>
Second, link to the named anchor. The URL of the named anchor is the
URL of the document, with "#" and the name of the anchor appended. For
example, elsewhere in the same document you could use:
<A HREF="#section2">go to Section 2</A>
Similarly, in another document you could use:
<A HREF="thesis.html#section2">go to Section 2 of my thesis</A>
<A TARGET="_blank" HREF=...> opens a new, unnamed
window.
<A TARGET="foobar" HREF=...> opens a new window
named "foobar", provided that a window or frame by that name does not
already exist.
Note that links that open new windows can be annoying to your readers
if there is not a good reason (from the reader's perspective) for them.
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="foo.html" TARGET="popup" ONCLICK="window.open('foo.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.
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.
For a more detailed explanation, please see Abigail's "Simulating
the back button" at <URL:http://www.foad.org/%7Eabigail/HTML/Misc/back_button.html>.
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.org/',
'Web Design Group'); }
if(document.all) {
document.write('<input type="button" onclick="addf()"'+
' value="Bookmark WDG Site">'); }
//--></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.
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:
- Create email aliases that are used only for certain mailto links,
so you'll know that anything sent to a given alias is in response
to the corresponding Web page(s).
- The mail handlers for many Web browsers include an "X-Url" header
that specifies the URL of the Web page that contained the mailto link.
If you configure your mail reader to display this header, you'll see
which Web page the sender is responding to much of the time.
- Use
<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.
- Use
<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. The details of this RFC can be found at <URL:http://info.internet.isi.edu/in-notes/rfc/files/rfc2368.txt>.
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.
Just use the image as the link content, like this:
<A HREF=...><IMG ...></A>
Use the BORDER="0" attribute in the <IMG>
element. For example:
<A HREF="doc.html"><IMG SRC="doc.gif" ALT="View document."
BORDER="0"></A>
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. A detailed explanation (with examples) is available
at <http://www.htmlhelp.com/reference/html40/special/map.html>.
A tutorial is available at <http://ppewww.ph.gla.ac.uk/~flavell/www/imgmaptut.html>.
If you want to turn off link underlining when you're looking at pages
in your browser, check your browser's configuration options. In Netscape
3, for example, see Options | General Preferences | Appearance; in Netscape
4 it's Edit | Preferences | Appearance | Colors; in Internet Explorer
see View | Options | General.
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 using style sheets. In your style
sheet, define something like this:
a:link {color: blue; background: white}
a:visited {color: purple; background: white}
a:active {color: red; background: white}
a.foo:link {color: yellow; background: black}
a.foo:visited {color: white; background: black}
a.foo:active {color: red; background: black}
Then use CLASS="foo" to identify the links of the second
color in your HTML, like this:
<A CLASS="foo" HREF=...>...</A>
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 }
Most likely you forgot to close a quote at the end of the HREF
attribute. Alternatively, perhaps you used a ">" character somewhere
else inside a tag. Although this is legal, several older browsers will
think the tag ends there, so the rest is displayed as normal text.
This especially happens if you use comment tags to "comment out" text
with HTML tags. (See the answer to "How can
I include comments in HTML?") Although the correct syntax is <!--
--> (without "--" occurring anywhere inside the
comment), some browsers will think the comment ends at the first ">"
they see.
Validators will show you any syntax errors in your markup, but checkers
such as Weblint and HTMLchek can show you where you are liable to provoke
known browser bugs. For example, some 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. See also the answer
to "How can I check for errors?"
Another possibility is that your web authoring software 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://server/path/file.html).
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 spec, 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">
For the technical details, see <URL:http://www.w3.org/Addressing/>
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.)
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 often
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/wordperfect6.0 |
WordPerfect 6.0 Document |
| application/zip |
ZIP archive |
| audio/x-wav |
WAV audio format |
| audio/midi |
MIDI audio format |
| audio/x-pn-realaudio |
RealAudio |
| image/gif |
GIF image format |
| image/jpeg |
JPEG image format |
| image/png |
PNG image format |
| text/html |
HTML document |
| text/plain |
Plain text |
| video/mpeg |
MPEG video format |
| video/quicktime |
QuickTime video format |
| video/x-msvideo |
AVI video format |
Another method of ensuring that your file is properly sent to the client
is to compress it into a standard compression format. Virtually all
servers are set to handle the .zip extension and it is widely recognized
by users.
Some servers (NCSA, Apache, and others) can be configured to support
user-configured content types. Details are server dependent, so consult
your server admin or documentation.
Note that Internet Explorer incorrectly ignores server-provided MIME
types, so it sometimes "does the right thing" when the server is misconfigured.
Other browsers correctly heed the server-provided MIME types, so they
will reveal server misconfigurations.
You can't, 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, as
described in the answer to the previous question.
The browser then decides what to do with it. Different browsers are
able to and configured to display different types of documents themselves.
Browsers are usually configured to handle other file types by using
helper applications or by offering to save the file. There is no way
for a web author to override the way the browser is configured to handle
any given type of file.
You can't, because the Web doesn't work that way.
As explained in the answer to the previous question,
the server is responsible for identifying a document's media type properly,
and the browser is responsible for deciding how to handle the document
(based on its media type). There is no way for a web author to override
the way the browser is configured to handle any given type of file.
Most browsers allow the user 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, the MIME type should be "application/octet-stream".
Check out the following resources:
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
- resampling/resizing the image to create a physically smaller image;
- cropping the image to remove less significant parts of the image;
- reducing the image quality to increase compression ratios; and
- reducing the size of the color palette (e.g., converting to greyscale).
Thumbnail images can use multiple techniques simultaneously. For example,
Jakob Nielsen advocates "Relevance-Enhanced
Image Reduction", which combines resampling/resizing and cropping.
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>
will have white space to the left and right of the image. Since many
browsers display anchors with colored underscores by default, they will
show the spaces to the left and right of the image with colored underscores.
Solution: don't leave any white space between the anchor tags and the
IMG tag. If the line gets too long, break it inside the tag rather than
outside it, like this:
<A HREF=...><IMG
SRC=...></A>
Style checkers such as Weblint will call attention to this problem
in your HTML source.
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. There is an example of such a
CGI script at <URL:http://www.foad.org/%7Eabigail/CGI/random_images.html>.
See the CGI Programming FAQ <URL:http://www.htmlhelp.com/faq/cgifaq.html>
for more information about CGI.
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.
Most likely you forgot to close a quote at the end of the SRC attribute.
Alternatively, perhaps you used a ">" character in an ALT text or
somewhere else inside a tag. Although this is legal, several older browsers
will think the tag ends there, so the rest is displayed as normal text.
This especially happens if you use comment tags to "comment out" text
with HTML tags. (See the answer to "How can
I include comments in HTML?") Although the correct syntax is <!--
--> (without "--" occurring anywhere inside the
comment), some browsers will think the comment ends at the first ">"
they see.
Validators will show you any syntax errors in your markup, but checkers
such as Weblint and HTMLchek can show you where you are liable to provoke
known browser bugs. See also the answer to "How
can I check for errors?"
Here are some other possibilities:
- Your web authoring software may have used file URLs (e.g., file:C:\path\image.gif).
If so, then you should replace them with relative
URLs (e.g., image.gif) or http URLs (e.g., http://server/path/image.gif).
- Your images may be in a format that is not widely supported, like
Microsoft's BMP format or AOL's ART format. Be sure to save your images
in a widely supported format like GIF, JPEG, or PNG. (Note that you
need to convert the image data format; you can't just rename the file.)
You can't. The image file is necessary for the browser to display your
document; you must send it to the browser. Even if a particular browser
doesn't have a "Save Image" feature, there are many that do, and someone
can always retrieve the image file by hand (using telnet) or from the
browser's cache.
There are tricks that make it more difficult for some readers to save
your images. However, just as with tricks that try to hide
HTML source, these tricks cause various problems for law-abiding
users and can't really prevent thieves from saving your images.
No. Character entities (©, &#nnn; and such) are permitted,
though.
If you want to know how to write good ALT texts without markup, please
see Alan Flavell's essay on choosing ALT texts at <URL:http://www.htmlhelp.com/feature/art3.htm>.
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>
For more on the EMBED element, see <URL:http://developer.netscape.com/docs/manuals/htmlguid/tags14.htm#1286379>.
For more on the BGSOUND element, see <URL:http://msdn.microsoft.com/workshop/author/dhtml/reference/objects/bgsound.asp>.
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>
Many browsers have a "Save As..." function that allows you to specify
plain text as the output format. Another approach is to select all the
text, copy it to the clipboard, and paste it into an editor.
The CoffeeCup HTML Editor has an HTML Stripper built in.
Lynx users can use "lynx -dump http://..." on the command line to print
to file and append a list of referenced URLs as footnotes. If you want
the output file without the footnotes, use the "p" command to "print"
to a text file.
Section 6: Presentational Effects
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>
For an experimental but somewhat more graceful approach, read about
CSS1 and the Decorative HR at <URL:http://ppewww.ph.gla.ac.uk/%7Eflavell/www/hrstyle.html>.
There are several methods, none completely satisfactory:
- Use the list-style property of Cascading Style Sheets. This should
be the preferred method of using custom bullets, but unfortunately
it's not widely supported by browsers. However, non-supporting browsers
will see a normal bullet, so using this method today is not a problem.
See <URL:http://www.htmlhelp.com/reference/css/>
for more information on style sheets.
- Use a
<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.
- Use a two-column table, with the bullets in the left column and
the text in the right. Since browsers show nothing before downloading
the entire table, this can be slow with long lists.
- Create the bullet with the indent built in. For example, if you
use a bullet that is 10 pixels across you can make the background
25 pixels (transparent) and put the bullet all the way on the right.
This will create a 15-pixel indent to the left of the bullet. It will
add slightly to the byte size of the graphic but since it is all one
color it won't add much. This method doesn't work well with any list
items that are longer than a line (and remember that you don't know
how long a line will be on the visitor's screen).
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.
Counter services and information are available from Yahoo's list of
counters: http://dir.yahoo.com/Computers_and_Internet/Internet/World_Wide_Web/Programming/Access_Counters/
A discussion of the limitations of web-traffic statistics is at <URL:http://www.cranfield.ac.uk/docs/stats/>
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, not 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.
You can use the ALIGN=right attribute on paragraphs, divisions, and
headers, just as you use ALIGN=center to create centered paragraphs
and such. This will right align your text (ragged left).
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 a CSS1 style sheet with text-align:justify,
or in HTML 4 with the deprecated attribute align="justify".
(Before you do that, a caveat: though justified text may look pretty,
human factors analysis shows that ragged right is actually easier to
read and understand.)
For images, you can use <IMG ALIGN=right SRC="..." ALT="...">
before the running text. The image will float at the right margin, and
the running text will flow around it. Remember to use <BR CLEAR=right>
or <BR CLEAR=all> to mark the end of the text that
is to be affected in this way. For an explanation with nice examples,
see <URL:http://www.awpa.asn.au/html/images.html>.
If your images are inside a table, be sure to set the BORDER,
CELLSPACING, and CELLPADDING
attributes to 0. Also, extra space between images is often created by
whitespace around the <IMG> tag in the markup. 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.
Use a style sheet with the following ruleset:
P { text-indent: 5% }
See <URL:http://www.htmlhelp.com/reference/css/>
for more information on style sheets.
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% }
See <URL:http://www.htmlhelp.com/reference/css/>
for more information on style sheets.
The most appropriate way is to suggest margins with a style sheet.
Cascading Style Sheets use the margin property
to specify margins. More information about Cascading Style Sheets can
be found at: http://www.htmlhelp.com/reference/css/
More information about the CSS margin property
can be found at: http://www.htmlhelp.com/reference/css/box/margin.html
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" vspace="0" marginwidth="0"
leftmargin="0" hspace="0" style="margin:0">
More information is available at <URL:http://mirror.subotnik.net/jkorpela/www/margins.html
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.
Page breaks are offered in Cascading Style Sheets, Level 2, but they
are not well supported by browsers. See <URL:http://www.w3.org/TR/REC-CSS2/page.html#page-breaks>
for information on CSS2 page breaks.
In general, page breaks are not appropriate on the Web since what makes
a nice page break for you with your font and font size may be a poor
page break for me with my font and font size.
If you need to produce a nicely formatted printed copy of your HTML
documents, you might also consider using special purpose tools rather
than your browser's Print function. For example, html2ps generates nicely formatted PostScript
output from HTML documents, and HTML Scissor uses special HTML comments
for suggesting page breaks.
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. More information about Cascading Style
Sheets can be found at: http://www.htmlhelp.com/reference/css/
More information about the CSS font-family
property can be found at: http://www.htmlhelp.com/reference/css/font/font-family.html
With HTML, the BASEFONT element can
be used to suggest specific fonts for the entire document. The BASEFONT
element affects the entire document. More information about the BASEFONT
element can be found at: http://www.htmlhelp.com/reference/html40/special/basefont.html
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, see: http://www.mcsr.olemiss.edu/%7Emudws/font.html
More information about the FONT element can be found at: http://www.htmlhelp.com/reference/html40/special/font.html
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 dingbat font with building
images (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 byt 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.
Netscape and Microsoft have developed competing formats for dynamic
fonts. TrueDoc works on Navigator 4+ and (with a plugin) on Internet
Explorer 4+. OpenType works on Internet Explorer 4+. For more information
about TrueDoc (including the WebFont Maker), see: http://www.truedoc.com/webpages/intro/
For more information about OpenType (including Microsoft's Web Embedding
Fonts Tool (WEFT)), see: http://www.microsoft.com/typography/web/
For practical advise on using fonts on the web, see Todd Fahrner's
"Beyond the FONT tag: Practical HTML text styling" at: <http://style.metrius.com/font_size/livetext.html>
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. More information
about Cascading Style Sheets can be found at: http://www.htmlhelp.com/reference/css/
More information about the CSS color property
can be found at: http://www.htmlhelp.com/reference/css/color-background/color.html
More information about the CSS background-color
property can be found at: http://www.htmlhelp.com/reference/css/color-background/background-color.html
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. 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">
More information about the BODY element can be found at: http://www.htmlhelp.com/reference/html40/html/body.html
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
More information about Cascading Style Sheets can be found at: http://www.htmlhelp.com/reference/css/
With HTML, the FONT element can also be used to suggest colors. Use
of the FONT element brings numerous usability and accessibility problems,
see: http://www.mcsr.olemiss.edu/%7Emudws/font.html
More information about the FONT element can be found at: http://www.htmlhelp.com/reference/html40/special/font.html
If you want others to view your web page with a background image,
the most appropriate way is to suggest the background with a style sheet.
Cascading Style Sheets use the background-image
property to specify a background image. More information about Cascading
Style Sheets can be found at: http://www.htmlhelp.com/reference/css/
More information about the CSS background-image property can be found at: http://www.htmlhelp.com/reference/css/color-background/background-image.html
With HTML, you can suggest a tiled 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">
More information about the BODY element can be found at: http://www.htmlhelp.com/reference/html40/html/body.html
If you specify a background image, you should also specify text, link,
and background colors (see the answer to the question "How
can I specify colors?") since the reader's default colors may not
provide adequate contrast against your background image. The background
color will be used by those not loading images. Authors should not rely
on the specified background image since browsers allow their users to
disable image loading or to override document-specified backgrounds.
Use a style sheet with the following ruleset:
body { color: black; background: white url(foo.gif) fixed }
Note that the fixed property used in the above style
sheet is supported by Internet Explorer 3+, Netscape Navigator 5+, and
other browsers. In contrast, the proprietary BGPROPERTIES=fixed
attribute is supported only by Internet Explorer 3+.
Use a style sheet with the following ruleset:
body { color: black; background: white url(foo.gif) no-repeat
}
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. If
your graphics program doesn't support the Windows icon format, you can
use a tool like the free Java-based icon generator at <URL:http://www.favicon.com/>
to convert/create your icon.
For further information, see <URL:http://msdn.microsoft.com/workshop/Author/dhtml/howto/ShortcutIcon.asp>
or search for "favicon.ico" at <URL:http://msdn.microsoft.com/workshop/essentials/versions/ICPIE5.asp>
See Alan Flavell's document on tables for a good discussion at <URL:http://ppewww.ph.gla.ac.uk/%7Eflavell/www/tablejob.html>.
Yes, a table can be embedded inside a cell in another table. Here's
a simple example:
<table>
<tr>
<td>this is the first cell of the outer table</td>
<td>this is the second cell of the outer table,
with the inner table embedded in it<br>
<table>
<tr>
<td>this is the first cell of the inner table</td>
<td>this is the second cell of the inner table</td>
</tr>
</table>
</td>
</tr>
</table>
The main caveat about nested tables is that Netscape has problems with
them if you don't close your TD and TR tags meticulously. You're best
advised to include every </TD> and </TR>,
even though the HTML spec doesn't require them; otherwise Netscape users
may not be able to view your page.
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>
The "correct" way of doing it is <TABLE ALIGN=CENTER>,
but this doesn't work in several popular browsers. Put <CENTER>;
around the entire table for these browsers.
This causes some problems with browsers that do support CENTER
but not tables, such as Lynx. In these browsers, the contents of the
cells are now displayed centered, which is not what is intended. To
avoid this, you can put the cell's contents in <P ALIGN=left>
or <DIV ALIGN=left> depending on the amount of text
in the cell.
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:
<TABLE ALIGN="right">...</TABLE>
The table will float to the right.
This text will appear to the left of 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.
Graphical browsers leave a narrow margin between the edge of the display
area and the content. For information on how you can specify that the
browser omit these margins, see the answer to the question "How
do I eliminate the margins around my page?"
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 pargins, 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. See the answer
to "How can I check for errors?" Even with
correct syntax, nested tables may not display correctly in Netscape.
See the answer to "Can I nest tables within tables?"
for what you can do about that.
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 use of tables for layout is explored in detail at <URL:http://www.dantobias.com/webtips/tables.html>.
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
- at least one submit button (i.e., an
<INPUT TYPE="submit"
...> element),
- form data elements (e.g., <INPUT>, <TEXTAREA>, and <SELECT>)
as needed, and
- additional markup (e.g., identifying data elements, presenting instructions)
as needed.
A more detailed explanation of the use of forms is available at <URL:http://mirror.subotnik.net/jkorpela/forms/>.
If you want to install CGI programs on your server, the following are
useful resources:
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. A list of such services can be found
at <URL:http://cgi.resourceindex.com/Remotely_Hosted/Form_Processing/>.
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. They
may work for some of your users, but they will fail for others who have
different 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>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>
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. For a more detailed
answer, see <URL:http://ppewww.ph.gla.ac.uk/%7Eflavell/www/formquestion.html>.
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 an image of a custom submit button. Use <INPUT
NAME=Send TYPE=image SRC="http://url.to/image.gif" ALT="Send" VALUE="Send">.
Most browsers will also send the x and y coordinates of the location
where the user clicked on the image to the server. They are available
as "Send.x=000&Send.y=000" in the CGI input. For more information,
see <URL:
http://ppewww.ph.gla.ac.uk/%7eflavell/www/trysub.html>.
For the reset button, one could use <BUTTON TYPE=reset ...>,
JavaScript, and/or style sheets, although none of these mechanisms work
universally. For more information, see <URL:http://mirror.subotnik.net/jkorpela/forms/imagereset.html>.
Sure. This is part of HTML 2.0 Forms support (some early browsers did
not support it, but browser coverage is now excellent).
You will need to give your Submit buttons a Name attribute, and, optionally,
a Value attribute. In order to determine which button was used, you
will want to use distinctive Names, or Values, or both. Browsers will
display the Value, in addition to sending it to the server, so choose
something that's meaningful to the user as in the following example:
<INPUT TYPE=SUBMIT NAME=join VALUE="I want to join now">
-or-
<INPUT TYPE=SUBMIT NAME=info VALUE="Please send full details">
Note that if you are using image submit buttons, you need to provide
different Value attributes for them too.
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.
Yes. 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) data filled in as the default values
for the form fields.
In addition, you could use JavaScript in the form's ONSUBMIT attribute
to check the form for those who have JavaScript enabled. If the form
is incomplete, have the ONSUBMIT event handler inform the user of the
problem and return false. Note that the server-side program should not
rely upon the checking done by the client-side script.
First of all, the RFC for this is located at <URL:http://www.ics.uci.edu/pub/ietf/html/rfc1867.txt>.
File upload is handled by the CGI.pm Perl5 library available from <URL:http://stein.cshl.org/WWW/software/CGI/cgi_docs.html>.
The most recent versions of the cgi-lib.pl library also support file
upload.
These things are necessary for Web-based uploads:
Not all browsers support form-based file upload, so try to give alternatives
where possible. 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.
See <http://mirror.subotnik.net/jkorpela/forms/navmenu.html>,
which explains how to create pull-down menus, as well as some better
navigation alternatives.
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.
A frameset is a particular combination of frames. To use frames, one
document must define the frameset, so that other documents can be displayed
in the frames. This document is called the frameset document. 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. The Web Design Group's guide to
frames <http://www.htmlhelp.com/design/frames/>
includes guidelines on the suitable use of frames, in addition to a
description of the related HTML syntax.
In the frameset document (the HTML document containing the <FRAMESET>
and <FRAME> elements), 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.) You can specify the target frame
for a link (e.g., <A TARGET="content" HREF=...>)
or for a form (e.g., <FORM TARGET="content" ACTION=...>).
Also, you can use <BASE TARGET=...> to change the
default target frame for the entire document (normally, the default
target frame is "_self", the current frame).
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
TARGET="_top" (replacing the entire frameset), but there
is an alternative if the frames to be updated are part of a nested frameset.
In the initial frameset document, use a secondary frameset document
to define the nested frameset. For example:
<FRAMESET COLS="*,3*">
<FRAME SRC="contents.html" NAME="Contents">
<FRAME SRC="frameset2.html" NAME="Display">
</FRAMESET>
A link can now use TARGET="Display" to replace simultaneously
all the frames defined by frameset2.html.
The JavaScript-based solution uses the onClick attribute
of the link to perform the secondary update. For example:
<A HREF="URL1" TARGET=Frame1
onClick="top.Frame2.location='URL2';">Update frames</A>
The link will update Frame1 with URL1 normally.
If the reader's browser supports JavaScript (and has it enabled), then
Frame2 will also be updated (with URL2).
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.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. If you can configure your server to send the proprietary
header Window-Target: _top in the HTTP response, then
Netscape browsers will display your document in the full browser window.
However, other browsers ignore this header, and it doesn't work to use
<META HTTP-EQUIV="Window-target" CONTENT="_top">
in the document itself to mimic the HTTP response.
Another workaround is to use <BASE TARGET="_top">
in the document, but this only specifies the default target frame for
links in the current document, not for the document itself.
If the reader's browser has JavaScript enabled, the following script
will automatically remove any existing framesets:
<SCRIPT TYPE="text/javascript">
<!--
if (top.frames.length!=0)
top.location=self.document.location;
// -->
</SCRIPT>
An alternative script is
<SCRIPT TYPE="text/javascript">
<!--
function breakOut() {
if (self != top)
window.open("my URL","_top","");
}
// -->
</SCRIPT>
</HEAD>
<BODY onLoad="breakOut()">
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 two major
frames-capable browsers use different proprietary attributes to achieve
this.
Netscape recognizes the BORDER attribute on FRAMESET.
It can be set to 0, in which case the border will not be shown, and
the spacing will be set to zero.
Microsoft Internet Explorer recognizes the FRAMEBORDER
and FRAMESPACING attributes on FRAMESET, but
in some versions also on FRAME for individual frames. Both
attributes must be set to 0.
So, 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 specifications. Also, removing the border around a frame makes it
impossible to resize it, as this border is also used in most GUIs to
change the size of the window.
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).
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.
For further discussion, see <URL:http://www.htmlhelp.com/design/frames/whatswrong.html>
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.