If you were hoping to find information to make a website look like a clownsuit, or do things that make webbrowsers running on 500MHz PCs behave like they're a 16MHz 386, then you're in the wrong place. Before you get keen on adding all sorts of gumph to pages, you should read the morons in webspace page, which goes into detail about what people find seriously annoying about websites, and common serious mistakes in webpage authoring.
I won't go into things like adding Flash to pages, because it's a complex thing, requiring more understanding of how web browsers work than I care to go into, won't work for a lot of browsers, and is rarely needed. It may look pretty, but it's usually pretty useless. For those who can't live without such dross on their pages, and can't work out how to do it, they're better off using an authoring program which handles it for them. Likewise, I won't discuss adding sound to pages, as it's another unreliable thing to attempt, and extremely annoying.
There are many extra things that you can do with your website, some of which will be useful, some ignored, some will cause problems, and so on. Until you understand what you're doing, such things are best avoided. Though, here's a few tricks, with explanations, that should be useful, and not cause problems:
These typically allow you to specify information in your pages, that are usually derived from the HTTP headers sent by the web server (“http-equiv” ones), though some are stand-alone information to go with the page (the other ones). In either case, meta elements go into the document “head” (between the opening and closing head tags, not inside the opening head tag) as does just about everything that isn't “displayed” as part of the page. Here's some of the things you can do with them:
It's a requirement that webpages specify the character set being used on the page (because not all computers use the same scheme, and there's no reliable way to guess what's being used). Unfortunately some people have difficulting doing this, or doing it right. It is sometimes possible to specify the charset within a meta statement on the page, as a last resort.
<meta http-equiv="content-type"
content="text/html; charset=iso-8859-1">
This can be useful if your server doesn't specify the charset used on the pages (which it should), or your page uses a different charset than other pages on the webserver (but only if the webserver, now, pays attention to your meta element, and tells the browser that your charset is being used), though can be a problem if the browser doesn't like being told the information twice (once from the server, then from your page; even more so if it gets conflicting information).
But few webservers pay attention to this, and web browsers are not supposed to pay attention to it if the webserver is sending out the proper HTTP Content-Type headers.
It will cause a problem if you specify the wrong character set (you really should know what it is, before you try and insist that you're using a particular one). It's better not to specify any character set, and let the browser try and cope with that, than give it misleading information (even though it's a requirement to supply the information).
It can be handy for people who save a local copy of your page, and will no-longer have the HTTP headers to specify what was used (although, their browser really should have taken care of that as it saved the file, e.g. saving the file in the computer's native character set, or inserting a meta element).
This sort of information really ought to be done via the HTTP headers (configured on the webserver), but sometimes that's not possible, and this is a possible way to provide the information, though it'll usually be ignored.
You need to specify the right one, the one that you're actually using. Typically, for English-language Windows users, it'll be the “windows-1252” character set. For Amiga or Linux users, it'll usually be “iso-8859-1”, though more recent Linux users may be using “utf-8”. But, for any of those, they'll typically be only using the characters that are present in ASCII, and can get away with declaring that they're using “US-ASCII” (those character sets use characters that are in the same positions as ASCII, for the usual characters found on an U.S. style IBM clone keyboard).
The character set only describes how the page was authored (what particular character set was used to represent what letters, numbers, and symbols, you used to write the document). It has nothing to do with the font, and thinking that the two are related will lead you to writing broken documents. Browsers may use the information to translate the page into the local system's character set, or may render the page differently to accomodate a different character set, or may fail to deal with a different character set. Unusual or misused ones, may cause serious reading problems.
For instance, the old ASCII standard has the letter “A” as the 65th character. When you type a letter “A” using ASCII, the system is using character number 65 (it doesn't know that it's a letter, or what it is, at all). Other codepages have the symbols in different positions; specifying the wrong one (charset) will produce a scrambled display. Changing the font face is a different thing, yet again (character 65, for instance, is still character 65, no matter what font face is being used, and no matter what shape glyph is displayed).
It's possible to include a description of a page, which may be used by a search engine (*), when it lists your page. Not all do, particularly due to abuse (people filling the description with rubbish, in an effort to boost the number of hits to their page **). Though, if you describe it properly (and briefly), there's (usually) no harm done (***).
<meta name="description" content="A page about
writing webpages.">
(* When search engines list pages, they usually include a brief snippet from the page. A random quote may not be very useful, so some will try and quote some of the page around whatever words match the search query, but if you've provided a clear and concise “description” of the page, this is probably better. Some search engines will display your description.)
(** Some people have this stupid idea that it's good to have masses of hits to their page, regardless of whether those hits have any relevance to what the person was searching for. Nor do they think of the costs involved in all the extra useless traffic; which, in some cases, they'll be billed for.)
(*** Due to such abuse (as above), some search engines are said to ignore pages with any meta descriptions, and many will just ignore the descriptions.)
It's possible to include extra keywords, so that your page is associated with other suitable terms, but ones that aren't specifically mentioned on the page (e.g. a page that was about “soccer”, may not have used the word “football” in the text, but the author would still like search queries about football, to find their page).
<meta name="keywords" content="soccer,
football, team sports.">
Note that due to abuse on a massive scale (as with meta descriptions), some search engines are rumoured to ignore pages with any, or too many, meta keywords, and many will just ignore the keywords. Don't write huge arrays of keywords, trying to associate a page with things it only has the vaguest connection with, nor include huge permutations of spellings, or repeat keywords many times. This sort of thing constitutes “abuse”, something which causes some search engines to automatically reject your page, as well as causes seach engine administrators to set up their systems to ignore what was once a useful feature. Anyway, search engines are getting better at finding “related” material to a query, negating the need for page authors to provide additional keywords.
Links have already been mentioned in two ways:
Link elements (which only go in the document “head”, as do meta elements), can also be used to link to other documents; though such links do not (generally) show up as part of the page, but as additional information which some browsers use in an additional navigational interface; giving you such features as “previous” and “next” page linking (which isn't the same as your browser “back” and “forward” functions—they step through the sequence in which you've visited pages; previous and next page links provide a relationship between pages, in the order that they're meant to be read), and search engines can use the information to correlate the content of a website. There's also some other commonly recognised link types: links to the starting page of a document set, for instance; as well as links to contents and index pages.
<head>
<title>Example page 2</title>
<link href="./contents.html" rel="contents">
<link href="./cover.html" rel="start">
<link href="./page1.html" rel="previous">
<link href="./page3.html" rel="next">
<link href="./index.html" rel="index">
</head>
Providing such links, helps people to navigate through complex documents, in a coherent manner (as well as providing machine assessable relationships between different pages).
This guide makes extensive use of the link element, but you'll need a decent web browser (like Mozilla or Opera), to see them (you might want to look at the pages source code to see how it's done). On such browsers, extra information is available in their tool bar, for navigating between pages, and to bookmarks on the same page. Whilst it's a chore to insert all that information that by hand (although you could get a computer to do it for you; after all, that's what they're for), it significantly enhances the usefulness of complex websites, particularly documentation.
One very common “want” with webpage authoring, is to include the content of some other resource into a page. Using SSI is one way to do it. It involves writing a page which includes an instruction for the server to include something else where the instruction is inserted into the current page. The resultant page that is generated by the server, is the same as if the page had always been authored with that content (there's no SSI instructions served to the browser, they're replaced by the inserted content).
<!--#include virtual="guide.links"
-->
The Apache webserver would allow you to insert a file called guide.links into a page, where you wrote that instruction. Of course, you have to put the instruction into a sensible part of the HTML document, and the file has to contain suitable content (in this case, it'd have a snippet of HTML in it).
SSI can be used for more than just including the content of something else, it can be used to generate content in a variety of different ways (page hit counters, information about the server or the visiting web browser, calculations, etc.). But, probably, one of its most common uses, is to insert common navigational links on every page, from a master template. This means less typing per page, and pages don't need to be re-typed should the navigational links need updating (only the master template needs editing).
Naturally, this requires having a server which includes that feature, and allows you to use it; and because how it's done depends on which specific WWW server that you using, you'll need to read its manual, to find out how to use it.
An alternative, is to use a programming language that can work with your web server (e.g. PHP, Perl, etc.). Now, rather than have the web server provide a limited amount of page generating functions, you can produce pages using whatever functions can be done with that programming language. Again, you'll need to research how your web server handles that, and read the documentation for whatever programming language that you use.