- Getting Started
- Where can I find a list
of all the current HTML tags?
- How do I get a so-and-so
character in my HTML?
- Should I put quotes around
attribute values?
- How can I include comments
in HTML?
- 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?
- 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 hide my source?
- How do I detect what
browser is being used?
- How do I get my visitors'
email addresses?
- 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?
- How do I freeze the URL
displayed in a visitor's browser?
- How do I make
a table which looks good on non-supporting browsers?
- Can I nest tables within
tables?
- How do I center a table?
- Hyperlinks
- Should I end my URLs with
a slash?
- How do I create a link
that opens a new window?
- How do I get a button
which takes me to a new page?
- How do I get a back button
on 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 eliminate the
blue border around linked images?
- How do I turn off underlining
on my links?
- How can I have two sets
of links with different colors?
- 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 only download a bunch of characters
instead?
- How do I force a download?
- How do I make animated
GIFs?
- Why am I getting a
colored whisker to the left or right of my image?
- Why are my images coming
out all wrong or not loading?
- 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 can I specify fonts in
my Web pages?
- How do I indent the
first line in my paragraphs?
- How do I indent a lot
of text?
- How do I do a page break?
- How do I have a fixed background
image?
- How do I have a non-tiled
background image?
- HTML Forms
- How do I use forms?
- Why won't my form email
the user's data to me?
- How do I make a form
so it can be submitted by hitting ENTER?
- How can I make a form
with custom buttons?
- Can I have two or more
Submit buttons in the same form?
- How can I allow file
uploads to my web site?
- HTML Frames
- How do I update two
frames at once?
- How do I get out of
a frameset?
- Is there a way to prevent
getting framed?
- How do I specify a
specific combination of frames instead of the
default document?
- Why do my links open
new windows instead of updating an existing window?
- How do I remove the
border around frames?
- How do I change the title
of a framed document?
- How do I make sure
my framed documents are displayed inside their
frameset?
- Are there any problems
with using frames?
- Why aren't my frames the
exact size I specified?
The current W3C Recommendation is HTML 4.0. HTML 4.0
extends HTML 3.2 to include support for frames, internationalization,
style sheets, advanced tables, and more. HTML 4.0 is
not well supported by current browsers, but many of
its features can be used safely in non-supporting browsers.
Recommended materials on HTML 4.0:
Recommended materials on HTML 3.2:
Some materials on browser-specific versions of HTML:
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:HTMLHelp>.
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 TM symbol; neither the actual character nor &#nnn;
is correct. (See the last paragraph of this answer for
more about those characters.)
On platforms whose own character code isn't ISO-8859-1,
such as MS DOS, Macs, there may be problems: you'd have
to use text transfer methods that convert between the
platform's own code and ISO-8859-1 (e.g Fetch for the
Mac), or convert separately (e.g GNU recode). Using
7-bit ASCII with entities avoids those problems, and
this FAQ is too small to cover other possibilities in
detail. Mac users - see the notes at the above URL.
If you run a web server (httpd) on a platform whose
own character code isn't ISO-8859-1, such as a Mac,
or IBM mainframe, it's the job of the server to convert
text documents into ISO-8859-1 code when sending them
to the network.
If you want to use characters outside of the ISO-8859-1
repertoire, you must use HTML 4.0 rather than HTML 3.2.
See the HTML 4.0 Recommendation at <URL:W3>
and the Babel site at <URL:Babel>
for more details. Another useful resource for internationalization
issues is at <URL:flavell>.
It depends. It is never wrong to use them, but you
don't have to if the attribute value consists only of
letters (A-Za-z), digits, periods and hyphens. This
is explained in the HTML 2.0 specs.
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:HTML
Help> for a more complete discussion.
The easiest way to catch errors in your HTML is through
the use of a program called a validator. A validator
is a program which knows all the rules in HTML, reads
your source document and outputs a list of mistakes.
While checking for errors in the HTML, it is also a
good idea to check for hypertext links which are no
longer valid. There are several link checkers available
for various platforms which will follow all links on
a site and return a list of the ones which are non-functioning.
You can find a list of validators and link checkers
at <URL:HTML
Help>. Especially recommended is the use of an
SGML-based validator such as the WDG HTML Validator
<URL:HTML
Help> or W3C HTML Validation Service <URL: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:HTML
Help> for information on choosing an appropriate
DOCTYPE declaration.
Many ISPs offer web space to their dial-up customers.
Typically this will be less than 5MB, and there may
be other restrictions; for example, many do not allow
commercial use of this space.
There are several companies and individuals who offer
free web space. This usually ranges from 100KB up to
1MB, and again there are often limitations on its use.
They may also require a link to their home page from
your pages. The following page has pointers to several
lists of free web space providers: <URL:Yahoo
Free Pages>.
There are also many web space providers (aka presence
providers) who will sell you space on their servers.
Prices will range from as little as $1 per month, up
to $100 per month or more, depending upon your needs.
Non-virtual Web space is typically the cheapest, offering
a URL like: http://www.some-provider.com/yourname/ For
a little more, plus the cost of registering a domain
name, you can get virtual web space, which will allow
you to have a URL like http://www.yourname.com/.
If you have some permanent connection to the Internet,
perhaps via leased line from your ISP then you could
install an httpd and operate your own Web server. There
are several Web servers available for almost all platforms.
If you just wish to share information with other local
users, or people on a LAN or WAN, you could just place
your HTML files on the LAN for everyone to access, or
alternatively if your LAN supports TCP/IP then install
a Web server on your computer.
Yes. Use a meaningful <TITLE> and
headings (<H1> , <H2> ,
and so on). The indexing programs of some search engines
(including AltaVista and Infoseek) will also take into
account the following tags in the <HEAD>
part of your documents:
<META NAME="keywords" CONTENT="keyword keyword
keyword keyword">
<META NAME="description" CONTENT="description of
your site">
Both may contain up to 1022 characters, but no markup
other than entities. If you use a keyword too often
in the <META NAME="keywords"> tag,
the indexing program may ignore your keywords list altogether.
At this writing, "too often" means "more than 7 times"
to some popular engines, but that may change in the
future as indexing programs are changed to defend against
"cheaters."
Search Engine Watch at <URL:http://searchenginewatch.com/>
is a Web site dedicated to search engines and strategies
for Web page authors.
See <URL:WebCrawler>.
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:Apache>.
You can't. The source is necessary for the browser
to display your document. You have to send the complete,
unencrypted source to the browser. Even if a particular
browser doesn't have a "View source" option, there are
many that do, and you can always retrieve the document
by hand (using telnet) to get its source. Or check the
browser's cache.
You can of course put a hundred empty lines above the
actual source. Then newbies who don't see the scrollbars
will think there is nothing there.
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.
HTML itself offers no way to seamlessly incorporate
the content of one file into another.
True dynamic inclusion of one HTML document (even in
a different "charset") into another is offered by the
OBJECT
element, but due to shortcomings of browser versions
in current use, it seems unwise to rely on this yet
for essential content. The same can be said for IFRAME.
Two popular ways of including the contents of one file
seamlessly into another for the WWW are preprocessing
and server-side inclusion.
Preprocessing techniques include the C-preprocessor
and other generic text manipulation methods, and several
HTML-specific processors. But beware of making your
"source code" non-portable.
The HTML can only be validated after pre-processing,
so the typical cycle "Edit, Check, Upload" becomes "Edit,
Preprocess, Check, Upload" (here, "Check" includes whatever
steps you use to preview your pages: validation, linting,
management walk-through etc.; and "upload" means whatever
you do to finally publish your new pages to the web
server).
A much more powerful and versatile pre-processing technique
is to use an SGML processor (such as the SP
package) to generate your HTML; this can be self-validating.
Examples of server-side inclusion are Server Side Includes
"SSI" (Apache,
NCSA and
some other web servers) and "ASP";
processing occurs at the time the documents are actually
retrieved. A typical inclusion looks like
<!--#include virtual="/urlpath/to/myfile.htm" -->
but be sure to consult your own server's documentation,
as the details vary somewhat between implementations.
The whole directive gets replaced by the contents of
the specified file.
Using server-side inclusion (a potentially powerful
tool) merely as a way to insert static files such as
standard header/footers has implications for perceived
access speed and for server load, and is better avoided
on heavily loaded servers. If you use it in this way,
consider making the result cacheable (e.g., via "XBitHack
full" on Apache; setting properties of the "Response"
object in ASP). Details are beyond the scope of this
FAQ but you may find this useful: http://www.pobox.com/~mnot/cache_docs/
Proper HTML validation of server-side inclusion is
only possible after server-side processing is done,
e.g. by using an on-line
validator that retrieves the document from the server.
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.0 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.0 specification--use a validator such
as the WDG HTML Validator
at http://www.htmlhelp.com/tools/validator/
which supports HTML 4.0 and understands different character
encodings.
Browser support for coded characters may depend on
configuration and font resources. In some cases, additional
programs called "helpers" or "add-ins" supply virtual
fonts to browsers.
"Add-in" programs have in the past been used to support
numeric references to 15-bit or 16-bit code protocols
such as Chinese Big5 or Chinese GB2312.
In theory you should be able to include not only coded
characters but also Unicode numeric character references,
but browser support is generally poor. Numeric references
to the "charset-specified" encoding may appear to produce
the desired characters on some browsers, but this is
wrong behavior and should not be used. Character
entities are also problematical, aside from the HTML-significant
characters <, & etc.
C. Internationalization per HTML 4.0
Recent versions of the popular browsers have support
for some of these features, but at time of writing it
seems unwise to rely on this when authoring for a general
audience. If you'd like to explore the options, you
can find comprehensive background documentation and
some practical suggestions at
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 &eacute;
are two different and valid entities; &NBSP;
is invalid.
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.)
There are several possibilities.
First, you may have some incorrect HTML. Browsers vary
in their ability to guess what you meant. For instance,
Netscape is much more fussy about tables than MS Internet
Explorer, so a page with incorrect tables may look fine
in MSIE but not display at all in Netscape. See the
answer to "How can I check for
errors?" for tips on finding your HTML errors. (In
fact, even correct nested tables may not display correctly
in Netscape. See "Can I nest tables
within tables?" below for what you can do about
that.)
Second, you may have valid HTML that different browsers
interpret differently. For instance, it is not clear
from the spec what should be done with a string of
characters. Some browsers will collapse them for rendering
as a single space; others will render one space per
.
Other possibilities are a bug in one or the other browser,
or different user option settings.
See also the ansewrs to "Why
are my hyperlinks coming out all wrong or not loading?"
and "Why are my images coming
out all wrong or not loading?"
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.
See Alan Flavell's document on tables for a good discussion
at <URL:Flavell>.
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.
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.
The trailing slash is used to distinguish between directory
and file URLs. A file URL is an URL for a file, and
a directory URL refers to a directory. For example,
the URL for the WDG's HTML reference is http://www.htmlhelp.com/reference/
and the URL for the overview of HTML 3.2 elements is
http://www.htmlhelp.com/reference/wilbur/overview.html
If you request a directory URL without the trailing
slash, the browser will actually ask for a FILE with
that name. This file doesn't exist on the server, so
the server sends back a message saying that the browser
should ask for the directory. It uses a redirection
message for this. The browser then sends another request,
this time for the directory, and finally gets what was
asked for in the first place. This wastes time and network
resources.
When you write a document, all directory URLs should
end with a slash. Since you already know you are linking
to a directory, why force the user to make that second
request, when it could have been done using only one?
And by the way, it is NOT the browser which appends
the slash. The browser cannot know if what you are asking
for is a file or directory, not even when the final
part of the URL does not have an extension. http://www.somewhere.com/src/something/README
is a perfectly valid URL, has no extension in the final
part, yet refers to a file and not a directory.
The only apparent exception is when you refer to an
URL with just a hostname. Since it is obvious that when
you use http://www.htmlhelp.com you actually want the
main index "/" from our server, you do not have to include
the / in this case. It is regarded as good style to
do so, however.
For a full discussion of the proper form of URLs, see
RFC 1738 at <URL:cis>
and, for relative URLs, RFC 1808 at <URL:cis>.
<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.
This is best done with a small form:
<FORM ACTION="http://url.you.want.to.go.to/"
METHOD=GET>
<INPUT TYPE=submit VALUE="Text on button" NAME=foo>
</FORM>
If you want to line up buttons next to each other,
you will have to put them in a one-row table, with each
button in a separate cell.
Note that search engines might not find the target
document unless there is a normal link somewhere else
on the page.
A go-to-other-page button can also be coded in JavaScript,
but the above is standard HTML and works for more readers.
In HTML, this is impossible. Going "back" means that
you go to the previous page in your history. You might
be able to create a link to the URL specified in the
"HTTP_REFERER" environment variable in your document,
but that only creates a link to a new location in your
history. Even worse, the information in that variable
can be plain wrong. Some browsers incorrectly send the
variable when you use a bookmark or type in an URL manually,
and some don't send that variable at all. This would
result in an empty link.
A JavaScript could use "history.back()" to do this,
but this only works in Netscape 2 or higher and MSIE
3 or higher, and even then only if the user has not
disabled JavaScript.
For a more detailed explanation, please see Abigail's
"Simulating the back button" at <URL:Abigail>.
Use a mailto: link, for example
Send me email at
<A HREF="mailto:me@mydomain.com">me@mydomain.com</A>.
You can't, not in any reliable way. The methods that
are frequently posted don't do the job on all browsers
(or even all popular browsers), and many of them have
an important drawback: if your visitors are using an
older browser such as Netscape 1.22, their mail 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 recent RFC can be found at <URL:isi>.
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.
<IMG ... BORDER=0>
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>
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. See also the answer to "How
can I check for errors?"
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 $-_.,+!*'()
need not be encoded.
You should encode all other characters when they occur
in a URL, except when they're used for their reserved
purposes. For example, if you wanted to pass the value
"Jack&Jill" to a CGI script, you would need to encode
the "&" character as "%26", which might give you
a URL like the following: http://www.foo.com/foo.cgi?rhyme=Jack%26Jill&audience=child.
Note that the "?" and other "&" character in this
URL are not encoded since they're used for their reserved
purposes.
See section 2.2 of RFC 1738 at <URL:w3.org>
for the full story.
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.
You can't, because the Web doesn't work that way.
Here's the explanation. When someone downloads a document,
the server tells the browser what type of file it is.
The browser then displays it or picks the appropriate
helper application. If the server doesn't know the file
type, it tells the browser that the file is "text/plain",
or just plain text (true for most servers). You may
need to ask your server admin to configure this particular
file with the MIME type you want.
"Forcing" a download is not what you are supposed to
do. After all, what is more convenient than having the
proper application started when I download a particular
file? Browsing through a download directory can be quite
a pain. And 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:
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.
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?"
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:flavell>.
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:Developer
Netscape>. See <URL:MSDN>
for more information on BGSOUND. Note that these elements
are proprietary and not in any HTML standard. (The HTML
standard way of doing this is not well supported.)
Be aware that some users find it annoying for music
to automatically start playing. They may not have the
volume set properly on their speakers, or they may be
listening to something else. As a courtesy to your users,
you may prefer to offer the sound file as a link:
<A HREF="your_sound_file">Listen to my sound!
(5 kB MIDI)</A>
One of the easiest ways is to open a document in a
graphical browser such as Internet Explorer or Netscape,
select all the text and copy it to the clipboard. Most
browsers also have a "save as" function which will allow
you to save the file as plain text.
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.
You can use 1st Page to strip all HTML tags. Goto Tools
-> Strip All Tags from the 1st Page menus.
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:flavell>.
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:HTML
Help> 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: @
Yahoo Access Counts/
Log analysis tools and scripts are at @Yahoo
analysis tools/A>
<URL:Markwelch
Counters> is another good source for counter
information.
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".) There's no way to justify text
in HTML 3.2, but it can be done in a CSS1 style sheet
with "text-align: justify". (Before you do that, a caveat:
though justified text may look pretty, human factors
analysis shows that ragged right is actually easier
to read and understand.)
For images, you can use <IMG ALIGN=right SRC="..."
ALT="..."> before the running text. The image
will float at the right margin, and the running text
will flow around it. Remember to use <BR CLEAR=right>
or <BR CLEAR=all> to mark the end
of the text that is to be affected in this way.
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. See: http://www.htmlhelp.com/reference/css/font/font-family.html
The FONT element can also be used to suggest a specific
font. Use of the FONT element brings numerous usability
and accessibility problems, see: http://www.mcsr.olemiss.edu/%7Emudws/font.html
More information about the FONT element can be found
at: http://www.htmlhelp.com/reference/html40/special/font.html
Either way, authors run the risk that a reader's system
has a font by the same name but which is significantly
different. (e.g., "Chicago" can be a nice text font,
or a display font with letters formed by "bullet holes",
or a dingbat font with building images for creating
skylines).
Also, authors are limited to choosing a font (or a
group of similar fonts) that are commonly available
on many systems. If a reader does not have the font
installed on their system, they will see a default font.
Some browsers may use a less legible substitute font
than their normal default font in cases where "the specified
font wasn't found".
Use a style sheet with the following ruleset:
P { text-indent: 5% }
See <URL:HTML
Help> 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:HTML
Help> for more information on style sheets.
Page breaks are offered in Cascading Style Sheets,
Level 2, but they are not well supported by browsers.
See <URL:w3.org>
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.
Use a style sheet with the following ruleset:
body { color: black; background: white url(foo.gif)
fixed }
Note that while Internet Explorer 3+ respects the
fixed property, Netscape does not.
Use a style sheet with the following ruleset:
body { color: black; background: white url(foo.gif)
no-repeat }
Information relating to the use of forms is available
at <URL:jkorpela>.
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.
The only reliable solution is to use a CGI (or other
server-side) program to process your forms and mail
the results to you. If you can run CGI programs on your
server, see the list of prewritten scripts at <URL:CGI
Resources>. If you can't run CGI programs on
your own server, see the list of remotely hosted form-to-email
services at <URL:CGI
Resources>.
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:flavell>.
Rather than a normal submit button (<INPUT
TYPE=submit ...> ), you can use an image of
a custom submit button. Use <INPUT NAME=foo
TYPE=image SRC="http://url.to/image.gif"> .
There is no way to do this for the reset button.
Most browsers will also send the x and y coordinates
of the location where the user clicked on the image
to the server. They are available as "foo.x=000&foo.y=000"
in the CGI input.
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.
Example:
<INPUT TYPE=SUBMIT NAME=join VALUE="I want
to join now"> -or-
<INPUT TYPE=SUBMIT NAME=info VALUE="Please
send full details">
If you're unsure what results you're going to get when
you submit your form, NCSA has a standard script which
you can use. Code this, for example (assuming method
"post"):
<form method="post" action="http://hoohoo.ncsa.uiuc.edu/htbin-post/post-query">
and then go through the motions of submitting your
form. The NCSA server decodes the form input, and displays
the result to you.
First of all, the RFC for this is located at <URL:ics>.
File upload is handled by the CGI.pm Perl5 library
available from <URL:cshl>.
These things are necessary for Web-based uploads:
Not all browsers support form-based file upload, so
try to give alternatives where possible.
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 .
It is in current implementations not possible to display
a frame in the full browser window, at least not very
easily. You would have to read source to determine the
URL of the current 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.
"Getting framed" refers to the technique of using
an existing frameset to display someone else's document
against his wishes into the current display. This can
happen quite easily if one of the documents in the frames
uses a link that does not use the TARGET
attribute, as the destination of that link will be displayed
in the current frame.
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 way to specify that a particular
document should be displayed in the full browser window,
rather than in the current frame. The only workaround
is to configure the server to send out Window-Target: _top
in its HTTP responses, but this is not something that
all authors can do.
The HTML specifications say that META
can be used to mimic HTTP responses in HTML. However,
inserting <META HTTP-EQUIV="Window-target"
CONTENT="_top"> in the document does not work
as expected.
Another attempt 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 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 view.
The author can provide and link to multiple frameset
documents, one for each combination of frame content.
These frameset documents can be generated automatically,
possibly even being created on the fly by a CGI program.
If you use a name that does not point to a currently
available frame, then a new browser window will be opened,
and this window will be assigned the name you used.
In HTML 4.0, the TARGET attribute value
is case-insensitive, so that abc and ABC
both refer to the same frame/window, and _top
and _TOP both have the same meaning. However,
most browsers treat the TARGET attribute
value as case-sensitive and do not recognize ABC
as being the same as abc , or _TOP
as having the special meaning of _top .
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 3.0 only recognizes the BORDER
attribute on FRAMESET . [What about later
versions of Netscape? What do they do?] 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.0 specification. 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 title displayed is the title of the frameset document
- the HTML document containing the <FRAMESET>
and <FRAME> elements - 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).
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
frames by linking to these separate frameset documents
using TARGET="_top" , rather than linking
to the individual content documents.
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.
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:HTML
Help>
Netscape Navigator seems to round pixel-based frame
dimensions to the nearest whole percentage, 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. There is no way
to prevent this behavior.
To accomodate this, you should design your site to
accomodate variations in the browser's presentation.
This is a good idea in general, but especially so in
this situation.
For additions or omissions to this FAQ,
please contact <darin@htmlhelp.com>.
All information contained herein was originally
compiled by members of the Web Design Group, principally
Arnoud "Galactus" Engelfriet and John Pozadzides.
Additional input has been provided by
Lori Atwater, Alex Bell, Stan Brown, Roger Carbol, Alex
Chapman, Alan Flavell, Tina Marie Holmboe, Nick Kew,
Jukka Korpela, Simon Lee, Neal McBurnett, Glen McDonald,
Darin McGrew, Ken O'Brien, Timothy Prodin, Steve Pugh,
Liam Quinn, Kai Schätzl, Warren Steel, Peter Thomson,
and Daniel Tobias.
Thanks everyone!
|