| О КОПИРАЙТАХ |
| Вся предоставленная на этом сервере информация собрана нами из разных источников. Если Вам кажется, что публикация каких-то документов нарушает чьи-либо авторские права, сообщите нам об этом. |
|
|
|
|
|
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!
|
Copyright © 1996-1999.  All rights reserved.
|
