| Table of Contents |
Chapter 1: Introduction to HTML * What is HTML? * Basic HTML Guidelines * HTML Editors, creating your website * How do I post my webpage? Chapter 2: Markup Tags * Basic tags * Special tags * Hyperlinks Chapter 3: Making your page look better * Tag attributes * Visual effects * Formatting Chapter 4: Lists * Using various types of lists * Nesting lists Chapter 5: Multimedia * Intro to graphics files * Using Images in your HTML document * Audio/Video and your webpage Chapter 6: Tables * Creating simple tables * Advanced features of tables Chapter 7: Frames * Splitting your document into frames * Special concerns when working with frames Chapter 8: Forms * Designing a form * Processing form data Chapter 9: Image Mapping * Image Mapping Chapter 10: "Behind the scenes" HTML * Meta commands * Commenting * Extracting Source Code Chapter 11: Cascading Style Sheets (CSS) * Meta commands * Commenting * Extracting Source Code Chapter 12: Other Advanced Concepts (brief overview) * Image Mapping * Javascript * PERL * Java Applets * Designing for maximum "viewability"
| CHAPTER 1: Introduction to HTML |
HTML documents are plain-text (also known as ASCII) files that can be created using any text editor (such as Notepad or Wordpad on a Windows machine). You can also use word-processing software if you remember to save your document as "text only with line breaks". My favorite HTML editor is a great text/HTML editor well suited for advanced web site design, called TextPad.
Some HTML-specific editors are also available (Homesite, Hotdog, etc.). You may wish to try one of them after you learn some of the basics of HTML tagging. Often these HTML editors allow "WYSIWYG" editing. WYSIWYG is an acronym for "what you see is what you get"; it means that you design your HTML document visually, as if you were using a word processor, instead of writing the markup tags in a plain-text file and imagining what the resulting page will look like. WYSIWYG editing can be useful for beginners, but often produces "sloppy" code which may be difficult to update with advanced features. Your best bet is to learn good HTML coding from the ground up, and then you can decide what is best for you.
Once you have your files ready to post on the internet (or intranet as the case may be), you should contact the individual who maintains the server to see how you can get your files on the Web. The most common way to do this is via an interface called File Transfer Protocol (FTP). WS_FTP is a great apllication that uses this protocol and is very easy to use.
Before we get started, here are a few common terms which we will be using frequently:
The part of your Web browser most often mentioned is the browser display window (also the display window or browser window). This is the part of the Web browser where the actual contents of an HTML document are displayed.
The other thing I'll mention is the history list (sometimes called the go list). That's the list of pages you've visited during the current session. In most browsers, it is available as either a menu or a pop-up dialog box.
Favorites, Refresh, Home, etc.
Web browsers are written by different people. Each person has their own idea about how Web documents should look. Therefore, any given Web document will be displayed differently by different browsers. In fact, it will be displayed differently by different copies of the same browser, if the two copies have different preferences set.
Therefore, you need to keep this principle foremost in your mind at all times: you cannot guarantee that your document will appear to other people exactly as it does to you. In other words, don't fall into the trap of obsessively re-writing a document just to get it to "fit on one screen," or so a line of text is exactly "one screen wide." This is as pointless as trying to take a picture that will always be one foot wide, no matter how big the projection screen. Changes in font, font size, window size, and so on will all invalidate your attempts.
On the other hand, you want to write documents which look acceptable to most people. How? Well, it's almost an art form in itself, but my recommendation is that you assume that most people will set their browser to display text in a common font such as Times at a point size of somewhere between 10 and 15 points. While you shouldn't spend your time trying to precisely engineer page arrangement, you also shouldn't waste time worrying about how pages will look for someone whose display is set to 27-point Garamond. I is always a good thing to test out your web pages in several common browsers/versions to make sure they will look acceptable to your target audience. At a minimum, you should test it out in NS and IE, version 4 or higher.
| CHAPTER 2: Markup Tags |
HTML is composed of tags. HTML tags are always enclosed in angle-brackets ( < > ) and are case-insensitive; that is, it doesn't matter whether you type them in upper or lower case. I almost always use lower case, but that's just me. You can do whatever you like. I have found that the code tends to be more readable when you use all lowercase tags.
Tags typically occur in begin-end pairs. These pairs are in the form
<tag> ... </tag>
where the <tag> indicates the beginning of a tag-pair, and the </tag> indicates the end. (The three dots indicate an arbitrary amount of content between the tags.) The usual way to refer to each tag is "tag" for the first and "slash-tag" for the second, where tag is the actual name of the tag being discussed.
These pairs define containers. Any content within a container has the rules of that container applied to it. For example, the text within a "boldface container" would be boldfaced. Similarly, paragraphs are defined using a "paragraph container."
Thinking of tag-sets as containers will help in another way: it will help you remember that tags should always be balanced. In other words, you should keep containers nested within each other, just as you would have to do in the real world. Let's try some visual examples where we actually draw the containers:
Why should you worry about this? Well, if you start overlapping containers as shown on the right, about the best you can expect is that the document will be formatted in unexpected ways.
One more thing to keep in mind with regards to containers. Since HTML is based on these structures, it is often the case that the arrangement of text within a container is irrelevant. For example, within a paragraph container, all of the text can be in one long line, or in a series of separate lines, or with every word on its own line, or with every word separated from every other by nineteen spaces. These would all be displayed exactly the same.
Therefore, try to keep in mind this thought: whitespace doesn't matter. (Whitespace is all of the blank areas in a text file--empty lines, extra spaces, and so on.) I'll mention this again when discussing the paragraph tag, and it will crop up in other places. Again: whitespace doesn't matter.
Having said all that, I will now attempt to muddy the waters a bit by mentioning that not every tag in HTML is paired. Some tags, such as the line-break tag, stand on their own (that is, they have no closing tag). These are known as empty tags. As we encounter them, I'll point them out.
In summary, use the following conventions when writing web pages:
Every HTML document should contain certain standard HTML tags. Each document consists of head and body text. The head contains the title, and the body contains the actual text that is made up of paragraphs, lists, and other elements. Browsers expect specific information because they are programmed according to certain HTML specifications.
Required elements are shown in this sample bare-bones document:
Insert info here on tag attributes...
|
|
The required elements are the following tags (and their corresponding end tags):
Because you should include these tags in each file, you might want to create a template file with them. (Some browsers will format your HTML file correctly even if these tags are not included. But some browsers won't! So make sure to include them.) These are referred to as "document tags".
By "document tags," I mean the tags which divide up a Web page into its basic sections, such as the header information and the part of the page which contains the displayed text and graphics. This may seem confusing right now. Just hang on.
The first and last tags in a document should always be the HTML tags. These are the tags that tell a Web browser where the HTML in your document begins and ends. The absolute most basic of all possible Web documents is:
That's it. If you were to load such a page into a Web browser, it wouldn't do anything except give you a blank screen, but it is technically a valid Web page. Obviously, you'll want more than that.
The HEAD tags contain all of the document's header information. When I say "header," I don't mean what appears at the top of the browser window, but things like the document title and so on. Speaking of which...
This container is placed within the HEAD structure. Between the TITLE tags, you should have the title of your document. This will appear at the top of the browser's title bar, and also appears in the history list. Finally, the contents of the TITLE container go into your bookmark file, if you create a bookmark to a page.
What you type should probably be something which indicates the document's contents, but it doesn't have to be. The length of the title is pretty much unlimited, but don't go overboard. Users will either sneer at or be confused by exceedingly long titles.
If you don't type anything between the TITLE tags, or don't include the TITLE tags at all -- remember the blank document in the HTML section earlier? -- then the browser will typically use the actual file name for the title. Therefore, a document titled "TCh4ex4.html" will have that name appear in the history list. Again, you can choose to do this, but it will likely generate either confusion or contempt.
You should only have one TITLE container per document. Having more than one instance could cause enexpected results. Usually, the last title reference given will be used, but this type of overlap should be avoided!
BODY comes after the HEAD structure. Between the BODY tags, you find all of the stuff that gets displayed in the browser window. All of the text, the graphics, and links, and so on -- these things occur between the BODY tags. We'll get to what happens there starting with the next chapter.
So, putting everything we've covered thus far into one file, we have:
This time, the result would be a document with a completely blank browser window, but at least the words "Document Title" would appear in the browser's history list.
Let's look at the above block of HTML again, but this time with container lines sketched in. Note that the TITLE tags and text have been rearranged to make it easier to draw in the container lines. The rearrangement of the text does not in any way change the resulting Web page's appearance.
If you want to leave yourself notes in an HTML document, but don't want those notes to show up in the browser window, you need to use the comment tag. To do that, you would do the following:
Your note would go where the text Hi, I'm a comment. appears. Yes, you do need an exclamation point after the opening bracket, but not before the closing bracket. That's the way the standard is written. I have no idea why. Also, there is no end tag; that is, a tag like </!-- text --> does not exist. The comment tag is not a container. This is our first example of an empty tag.
You can put comments pretty much anywhere, but you have to be aware of one important thing: you shouldn't put any HTML markup within a comment tag. Theoretically, you should be able to, but some browsers handle this less than gracefully (i.e., they either mess up or crash). This can be useful for commenting out sections of code for use later.
What if you get the tag wrong, like forgetting to include the exclamation point? In that case, the text you did type in would be displayed.
Commenting in Javascript and VBS code...
Just to confuse matters, if you have a Javascript or VBS script embedded in your file, it should be commented...
All right, we know how to set up a document, but all we've gotten so far has been dull, blank browser windows. Time to fix that.
You'll remember that I discussed the way tag-pairs are used to create containers in which content is held and certain rules applied to it; in short, the structural nature of HTML. We've already seen some of that in the way a Web document is split into two main sections: the document's header and body. In this chapter, we're going to get into some of the structures within the BODY.
The heading structures are most commonly used to set apart document or section titles. For example, the word "Headings" at the beginning of this section is a heading. So is this document's title (it's at the top of the page, in case you somehow missed it).
Remember that these heading structures go into the body of the document. The headings being discussed here have nothing to do with the HEAD structure from the previous chapter.
There are six levels of headings, from Heading 1 through Heading 6. Heading 1 (H1) is "most important" and Heading 6 (H6) is "least important." By default, browsers will display the six heading levels in the same font, with the point size decreasing as the importance of the heading decreases. Here are all six HTML pairs, in descending order of importance:
These six lines, when placed into an HTML document, will simply display the six levels of headings.
Since, as we have discussed, whitespace doesn't matter, you might think that the above block of HTML would just string the content into one line of text. However, because headings are meant for section titles and the like, they are defined as existing on a line by themselves. A heading always begins at the margin of a line and always forces a line break at the end of the heading. In other words, you cannot have two heading levels on the same line.
This also means that you cannot highlight text in the middle of a paragraph by marking it as a heading. If you try this, the paragraph will be split in two, with the heading text on its own line between the two pieces. (Later on, we'll talk about ways of highlighting text). To do this, you will need to use a different tag like FONT.
If you have a browser which is set close to its default settings, you'll notice that the text for the last two headings gets pretty small. This leads to some page designers using H6 for the fine print at the bottom of pages. This is a mistake, not to mention an abuse of the heading structure. As you no doubt know, many browsers allow the user to set the size of each element, including the headings. If a user sets H6 to a size of 18 point, the fine print won't be so fine any more! Remember: you cannot guarantee that your document will appear to other people exactly as it does to you.
As you might suspect, paragraphs are quite common in Web pages. They are one of the most basic structures in HTML. If you regard a document as a collection of structures and sub-structures, you may come up with something like:
The overall structure is a page. The page is composed of a number of sections, each of which is composed of one or more paragraphs. Each paragraph is composed of words, and each word of letters.
Admittedly, this is a simplified way of looking at text, but it will do for our purposes. The furthest HTML goes down this progression is to the paragraph level.
The beginning of a paragraph is marked by <p>, and the end by </p>.
Let's say you want to create a paragraph. You start to wonder, "What happens if I hit return at the end of every line in the paragraph? Should I make the paragraph just one long continuous line? What if I accidentally put too many spaces between words?"
At this point, you should once again be saying to yourself: whitespace doesn't matter. You could put each word on its own line, and the paragraph would look completely normal. In fact, no matter how much whitespace you put between words, whether returns or spacebar hits, the words will be separated by one space in a Web browser.
Got all that? If you're not sure you completely understand, go through the section again -- or better still, try it on your own.
So what if you want to end a line after a certain word, but don't want to start a new paragraph? Well, what you need is a line break, which is invoked by using the <br> tag. This forces a line break wherever you place it in the content (that is, whatever is after the <BR> tag will start from the left margin of the next line on the screen.)
And no, there is no </br> tag. The line break tag is -- that's right! -- an empty tag. And when you think about it, this makes sense. The concept of a line break beginning and ending doesn't really work, since a line break is a one-shot occurrence.
Blockquotes are handy for those long pieces of text which are quoted material and therefore need to be set apart and indented. That is exactly what blockquote does. For example:
This section of text is surrounded by the blockquote tags. A blockquote can exist inside of a paragraph, and always lives on its own line (which is to say, there is an implied line break before and after the blockquote, just as with headings or paragraphs themselves).
Blockquotes are set up as follows:
<blockquote> ...text... </blockquote>
Just like most other things in HTML, it's a container.
The "correct" way to highlight text is to use the logical tags, which do not directly specify the type of highlighting they will employ. There are 'defaults' written into the specification (see the quotations below) but there is no direct rule about which tag should be displayed in what way. This is entirely in keeping with HTML's structural nature.
These tags are recommended for use because they leave the most control to the reader of a document. However, in the real world, the tags in the next section are a lot more popular than those above.
The tags I will cover here are sometimes called forced style tags, because their very nature forces a certain style within the document (at least, that's the idea). This does run counter to the entire "HTML is purely structural" philosophy, but my advice is not to worry about it too much. As long as you use the logical style tags where appropriate, then you're fine.
The four most commonly used forced style tags are very simple:
The HTML 2.0 Specification does allow the mixing of these styles, but does not require that a consistent appearance be maintained. In other words, different browsers will display combined styles differently. Some will pick one or the other style, others will not display either, and a few will simply crash.
The horizontal rule is a pretty useful effect. Horizontal rules are not allowed within headings. The tag, which is empty, is <HR>, and produces the following:
There. That was pretty easy, wasn't it? Now that you have everything you need to arrange your text, it's time to start linking things together.
The real point of the Web, of course, is that documents can be linked to each other, or to other types of files such as movies or sound clips, through the use of hyperlinks. These links allow authors to link documents together in intuitive ways, as opposed to traditional linear texts such as books, articles, or almost anything else printed.
In order to create a hyperlink, you'll need to know two things. The first is the URL -- that is, the location -- of the file to which you want the link to go. (If you are unclear as to how URLs work, take a look at NCSA's A Beginner's Guide to URLs.) The second is knowledge of how links work, which is the subject of this chapter.
The simplest possible anchor starts with <A> and ends with </A>. However, you will never ever use the <A> tag by itself, because it doesn't do anything. You'll need to enhance the <A> tag with attributes like...
HREF stands for "Hypertext REFerence," which is another way of saying, "The location of the file I want to load." Most anchors are in the form <A HREF="URL">, where URL is the location of the resource to which you want the link to point. For example, the CWRU Web server is at "http://www.cwru.edu/" (that's the server's basic URL). A sentence which contained a link to that address would look something like:
Check out the <A HREF="http://www.cwru.edu/">CWRU Web server</A>--
it's pretty cool!
The words between the open and close of the anchor ("CWRU Web server") would be displayed as a hyperlink. Selecting that link within a Web browser would cause the browser to load the CWRU Web server's main page. Here's what the above markup looks like in your browser:
Check out the CWRU Web server-- it's pretty cool!
The double-quote marks found around the value of HREF in an anchor are, under certain specific circumstances, optional. However, in most cases they are required. In addition, if you start the URL with a double-quote, you must close it with another. Just as tags need to be balanced, quote-marks do too. I personally recommend the use of the double-quotes, because it's a good habit to get into, especially when it comes to named anchors (below). Besides, in most cases they'll be required, so just go ahead and use them all the time.
A URL (and therefore, by implication, an anchor) can point to any resource available on the Web. This is usually another HTML page, but it can also be a graphic, a sound file, a movie, or any other kind of file. This fact lets you set up links to large graphics without actually having to display them in the page. For example, if there were a graphic file called "welcome.gif" in the directory "emeyer" of a server with the address "www.site.edu," the URL would be:
http://www.site.edu/emeyer/welcome.gif
Therefore, a text anchor referring to this graphic file would look something like:
<A HREF="http://www.site.edu/emeyer/welcome.gif">See my welcome message!</A>
A user who selects the anchor thus created will cause his Web browser to download the graphic file, which will then be displayed by his browser or by a helper program. The same general principles hold true for referring to sound files, movie files, multimedia files, and any other non-HTML files. So if I wanted to refer to a sound file called "welcome.au" in the same directory as the welcome graphic, I might set up a link like this:
<A HREF="http://www.site.edu/emeyer/welcome.au">Hear my welcome message!</A>
In case you were wondering, the first four letters of a Web URL do mean something. http stands for "HyperText Transfer Protocol," which is the technical way of saying "how the computers move Web data back and forth."
Well, all this is fine for linking between files, but what about jumping around within a document? Glad you asked.
You can make it easy for a reader to send electronic mail to a specific person or mail alias by including the mailto attribute in a hyperlink. The format is:
<A HREF="mailto:emailinfo@host">Name</a>
For example, enter:
<A HREF="mailto:pubs@ncsa.uiuc.edu"> NCSA Publications Group</a>
to create a mail window that is already configured to open a mail window for the NCSA Publications Group alias. (You, of course, will enter another mail address!)
Using the NAME attribute, you can invisibly mark certain points of a document as places that can be jumped to directly, instead of loading the document and then scrolling around to find what you're after. This is accomplished by using a named anchor, which is slightly different than the anchor used to create a hyperlink.
Setting a named anchor is done using the form <A NAME="label"> ... </A>, where label is any text you care to use. It could be anything from chapter1 to 2.4.1 to oscar-the-grouch. So putting a name of pt.3 to the text "Part 3: Bagels and You" would be accomplished like this...
<A NAME="pt.3">Part 3: Bagels and You</A>
...and would look like this:
Part 3: Bagels and You
Note that there is no obvious, visible way to tell that the text has been named. This is as it should be. The only way named anchors are important is if they're referred to somewhere else. Also note that the HREF attribute does not appear in this anchor. It can do so, but it is not required; the only requirement is that an anchor have either an HREF or a NAME attribute. It need not have both.
How does this happen? Using a standard hyperlink, of course, but with a small addition. Found in the HREF attribute, the name is tacked onto the end of the URL of the document in which it appears. To do this, just enter document's URL, and then add a pound-sign and the name to the end of the URL. For example, assuming that the document's URL is "http://www.site.edu/food.html," the pointer to the named anchor pt.3 would be:
http://www.site.edu/food.html#pt.3
A hyperlink which has the above URL in its HREF attribute will take the reader straight to the text contained within the anchor <A NAME="pt.3">... </A> within the file "food.html." (Incidentally, if the browser loads a file but can't find the named anchor which has been specified, it simply goes to the top of the file, just as it would have if there hadn't been a name in the URL at all.)
Now, you may be confused about why a pound-sign (#) is in the URL. That pound-sign is how the browser knows that it's looking for a name, and how it keeps the named anchor separate from the document's filename. Therefore, if you are writing a hyperlink which points to a named anchor found within the same document, you only need to have the pound-sign followed by the name of the anchor. For example, a hyperlink to Part 3 which is found within the file "food.html" would have this markup:
<A HREF="#pt.3">Part 3</A>
A common use for named anchors is to create a "table of contents" at the top of a long document. This approach was used in the markup of individual departments in the CWRU General Bulletin, as well as many other pages in the CWRU Web system. Each section within a document is given a named anchor, and hyperlinks to each of these anchors are put at the top of the file.
Unlike HREF, the double-quotes in the NAME attribute are never optional (because of the # character). This has another benefit, in that you may use spaces in your name. Why does this make a difference? Here's an example, assuming for the moment that the quotes aren't used: the anchor <A NAME=section 1.2> would create an anchor name section. This is because the space between section and 1.2 would be interpreted as the separator between attributes. The Web browser would take section as the name, toss out 1.2 as an unrecognized attribute, and proceed merrily along.
Similarly, the reference <A HREF=#section 1.2> would look for an anchor named section and completely ignore the 1.2.With the use of double-quotes, which are pretty much required anyway, this problem does not occur.
For those of you who have been through the companion to this tutorial, you will recall that in earlier, we discussed a number of logical style tags (as well as the forced-style tags). For the purposes of clarity and simplicity, I did not cover all of the logical style tags in that chapter, a fact that I intend to remedy here.
Here are the remaining tags, all of which are containers:
Remember that these are all logical style tags, so the actual display of these elements will vary by browser.
The last type of special-effect tag, <PRE>, is complicated enough to warrant its own section. So...
That's what <PRE> defines: preformatted text. It's a container, and it's a very special one.
Again, those of you who have read my tutorial Introduction to HTML will recall that I spent a lot of time droning on about the fact that whitespace doesn't matter. Extra spaces between words, multiple returns, blank lines-- all of these disappear in an HTML document, due to the structural nature of HTML.
Well, almost. There is an exception to this rule. In a preformatted text block, whitespace does matter. Suddenly, the number of spaces between words, or blank lines between paragraphs, will be seen.
Markup:
<PRE>
Now is the time for all good men
to come to the aid of their network...
</PRE>
Result:
Now is the time for all good men
to come to the aid of their network...
Thus, it is possible to use preformatted text to achieve otherwise impossible effects, such as aligning columns of numbers. Just insert the right number of spaces, and that spacing will be preserved.
This ability to utilize whitespace does not come without its prices, however. The first, as you can already see, is that the browser uses a monospaced font (that is, one in which all the characters have exactly the same width) to render preformatted text, much as it does for the <TT> tag. Most readers find this a less attractive type of display.
The second price is that the usual browser formatting rules go right out the window. For example, text within a preformatted text block does not flow within the margins of the browser window. So, if I have a really long line of text within a preformatted text block, it will go right off the edge of the screen. This is obviously not a very good thing.
There are also restrictions on which other HTML tags may be placed inside the preformatted text container, and in what contexts a preformatted text block may occur. Headings are forbidden within preformatted text blocks, as are paragraph tags. In fact, about the only tags allowed inside <PRE>...</PRE> are the anchor tag, the image tag, the line break tag, the horizontal rule, and the various text-effect tags (both logical and forced).
You may place a preformatted text block within the <BODY> container, obviously, as well as <blockquote>, the <DD> tag, forms (which are covered in Chapters 4-8 of this tutorial), and a list item in a list. Unfortunately, that's all.
Although by far the most common header element, <TITLE> is not the only tag which is allowed in the header of an HTML document. There are other tags, though most of them are not very popular. The two which are perhaps the least unpopular are discussed below.
Consider this example of HTML:
<B>This is an example of <I>overlapping</B>
HTML tags.</I>
The word overlapping is contained within both the <B> and <I> tags. A browser might be confused by this coding and might not display it the way you intend. The only way to know is to check each popular browser (which is time-consuming and impractical).
In general, avoid overlapping tags. Look at your tags and try pairing them up. Tags (with the obvious exceptions of elements whose end tags may be omitted, such as paragraphs) should be paired without an intervening tag in between. Look again at the example above. You cannot pair the bold tags without another tag in the middle (the first definition tag). Try matching your coding up like this to see if you have any problem areas that should be fixed before you release your files to a server.
HTML protocol allows you to embed links within other HTML tags:
<H1><A HREF="Destination.html">My heading</A></H1>
Do not embed HTML tags within an anchor:
<A HREF="Destination.html">
<H1>My heading</H1>
</A>
Although most browsers currently handle this second example, the official HTML specifications do not support this construct and your file will probably not work with future browsers. Remember that browsers can be forgiving when displaying improperly coded files. But that forgiveness may not last to the next version of the software! When in doubt, code your files according to the HTML specifications.
Character tags modify the appearance of the text within other elements:
<UL>
<LI><B>A bold list item</B>
<LI><I>An italic list item</I>
</UL>
Avoid embedding other types of HTML element tags. For example, you might be tempted to embed a heading within a list in order to make the font size larger:
<UL>
<LI><H1>A large heading</H1>
<LI><H2>Something slightly smaller</H2>
</UL>
Although some browsers handle this quite nicely, formatting of such coding is unpredictable (because it is undefined). For compatibility with all browsers, avoid these kinds of constructs. (The Netscape <FONT> tag, which lets you specify how large individual characters will be displayed in your window, is not currently part of the official HTML specifications.)
What's the difference between embedding a <B> within a <LI> tag as opposed to embedding a <H1> within a <LI>? Within HTML the semantic meaning of <H1> is that it's the main heading of a document and that it should be followed by the content of the document. Therefore it doesn't make sense to find a <H1> within a list.
Character formatting tags also are generally not additive. For example, you might expect that:
<B><I>some text</I></B>
would produce bold-italic text. On some browsers it does; other browsers interpret only the innermost tag.
To see a copy of the file that your browser reads to generate the information in your current window, select View Source (or the equivalent) from the browser menu. (Most browsers have a "View" menu under which this command is listed.) The file contents, with all the HTML tags, are displayed in a new window.
This is an excellent way to see how HTML is used and to learn tips and constructs. Of course, the HTML might not be technically correct. Once you become familiar with HTML and check the many online and hard-copy references on the subject, you will learn to distinguish between "good" and "bad" HTML.
Remember that you can save a source file with the HTML codes and use it as a template for one of your Web pages or modify the format to suit your purposes.
| CHAPTER 3: Making your page look better |
I know you're just itching to find out how you can make your documents all colorful and put backgrounds on your pages, so we'll start there. In the next chapter, I'll transit into other visual effects such as font sizing and new style tags.
Note that you must have your browser set to use document colors and backgrounds for the examples in this chapter, and the following chapters, to make sense. If your browser is set to always use your settings no matter what, then you won't be able to see the effects described in the text.
In a recent survey of Web users, it was found that the four most important features that users look for in a web site are Fast loading times (89%), Intuitive navigation (78.5%), Simple, focused content (73.1%) and Attractive graphics (33.3%).
Once upon a time, the BODY tag was a lonely tag-- it had no attributes. Then lo, the HTML committees did look upon the Web, and did see that documents were boring and in need of visual enhancement, or, to use the ancient dialect, "eye candy." Then did they speak among themselves, and decide that this effect could be achieved by adding attributes to BODY. And verily, so it was done.
Thus were backgrounds invented (and BODY was made less lonely). Originally a feature of HTML 3.0, backgrounds were for some time only supported by Arena, a UNIX-based browser. Then Netscape 1.1 introduced backgrounds to the masses, and the Web hasn't been the same since. Whether this is a good or bad thing depends on who you ask and which page they're viewing. While a good background can make a page look really great, there are few things worse than an obnoxious background. At the end of this chapter, I'll take a moment to discuss using backgrounds effectively.
You can specify two kinds of background using the BODY tag. The first kind is a solid color; the second, a tiled image.
If all you want for a page's background is a solid color -- let's say a medium tan -- then you can specify it using the attribute bgcolor. The value of bgcolor is a hexadecimal number that represents the color you want.
<BODY bgcolor="#xxxxxx">
...where xxxxxx is a six-digit hexadecimal number such as C0A280. Therefore, the BODY tag shown above would become:
<BODY bgcolor="#C0A280">
The pound sign (or number sign or whatever) denotes that the string following is a hexadecimal number, so it's required. The hexadecimal number breaks down into three pairs, as follows: the first pair of digits give the red value, the second pair the green value, and the last pair the blue value. Each pair can go from 00 to FF, which in regular base-ten numbering works out to the range 0-255. Therefore:
C0--> 75% red
A2--> 63% green
80--> 50% blue
How did I get those percentages? I'll take the red value as an example. I converted C0 to the corresponding decimal number (192) and then divided it by 256 to arrive at a percentage:
C0 hex --> 192 decimal
192/256 = 0.75 (in other words, 75%)
Presto! Therefore, in order to figure out the hexadecimal value of a given percentage, simply divide it by 100, multiply that by 256, and convert the result to hexadecimal notation. As an example:
55% red would be...
55/100 = 0.55
0.55 * 256 = 140.8 (round to 141)
141 decimal --> 8D hex
What could be easier? Besides an unanaesthetized root canal, I mean.
All right, so it's a bit annoying having to convert three percentages to numbers and then convert them to hex every time you want to come up with a color... not to mention the process of figuring out what the red-green-blue percentages are to begin with. Fortunately, some programs available on the Internet allow you to pick a color from a color wheel or palette, and will then give you the hexadecimal code representing that color.
Note that different computers will display a given color code differently. This is true in any case, even with graphics, but it can be more noticeable with a solid-color background. As an example, the hexadecimal notation for brown on a Macintosh is #371212, whereas on a typical Intel-based machine the code would be #A52A2A. Therefore, using the code representing brown on a Macintosh will show PC users a color other than brown, and vice versa. The problem tends to vanish at extremes; that is, where the pair values approach either 00 or FF, the colors will become more 'universal.' For example, blue (#0000FF) looks more or less the same no matter what platform you're using. As usual, the basic thing to keep in mind is that what you see on your screen won't necessarily be what others see on theirs.
Of course, just when you thought this was going to be far too annoyingly difficult, the standards commitees have come to the rescue. (They're cool that way.) The HTML 3.2 specification currently includes the ability to use one of sixteen named colors instead of a hexadecimal number. These colors, along with their hex equivalents, are:
Black = "#000000" Maroon = "#800000"
Green = "#008000" Navy = "#000080"
Silver = "#C0C0C0" Red = "#FF0000"
Lime = "#00FF00" Blue = "#0000FF"
Gray = "#808080" Purple = "#800080"
Olive = "#808000" Teal = "#008080"
White = "#FFFFFF" Fuchsia = "#FF00FF"
Yellow = "#FFFF00" Aqua = "#00FFFF"
Therefore, to set the background color of a document to white, you would use the BODY tag:
<BODY bgcolor="white">
You do not preface a named color with a pound-sign. Doing so will likely confuse a Web browser.
Not every browser will recognize these color names, so you need to be careful. On the other hand, newer browsers such as Netscape will recognize a whole bevy of named colors besides the sixteen listed above, and there are a number of lists of color names and their corresponding hexadecimal codes. A good place to start is the Color Information page provided by Yahoo!.
So why even bother with the hexadecimal notation? Well, it gives maximum flexibility. Instead of being restricted to the named colors recognized by various browsers-- and not every browser will recognize the same named colors as every other browser-- you can directly specify the exact color you want. Or at least try to, given the variance in color display between platforms.
Did I mention that this was going to be frustrating?
Solid colors can be very nice, of course, but what if you want something a little fancier than a solid color-- for example, a nice kitchen-tile pattern? (Oh, lovely!) This can be accomplished using an image of a single tile, which the browser will repeat indefinitely. The repeat pattern follows the grid pattern shown by the red lines in Figure 1.1. (In that example, the background image is 50 pixels tall by 50 pixels wide.)
...so a small image can be used to create interesting effects. I could, for example, use this image as a background:
to create a very Zen sort of page.
This is all accomplished by adding the attribute background to the BODY tag. The value of this attribute is the URL of the image you want to tile in the background. So, for example, let's assume the above yin-yang image is located at http://images.site.net/yinyang.gif. In order to get the effect shown in the above example, you would need to write:
<BODY background="http://images.site.net/yinyang.gif">
The URL can be relative, of course, as well as take the absolute form shown here.
What sort of images can be used in backgrounds? In all browsers that can display backgrounds, GIF is supported. JPEG and PNG are supported only in certain browsers, although this is expected to change (for the better) in the near future. As always, then, for maximum compatibility, use GIF.
Of course, background images can be any size, and in any proportion.
If you wanted to create a left-border effect, you could simply create a graphic about fifteen hundred pixels wide and only a few pixels tall. This would be repeated vertically. Of course, if the browser display window were somehow widened past fifteen hundred pixels, the background image would tile horizontally as well, but not too many users will stretch their windows that far (in fact, few are even able to do so). This has the obvious drawback of forcing the browser to download a large graphic and tile it so that large portions of the image are 'off-screen,' but that's the price your users will have to pay.
Since you can mess around with the background color and patterns, it makes sense that you can do the same with the color of various types of text. Using BODY attributes, it is possible to set the color values of ordinary text (using text), the text of hyperlinks (link), the text of already visited links (vlink), and the color which the browser uses to highlight a link when it's selected by the user (alink, which stands for "activated link").
Each of these attributes can be given the same values as those used for bgcolor-- that is, a hexadecimal number or named color. So, to set up a page with a black background, white text, and light blue links, the markup would be:
<BODY bgcolor="#000000" text="#FFFFFF" link="#90C8DB">
or
<BODY bgcolor="black" text="white" link="cyan">
Since the coloring of visited links is unspecified, the actual color displayed is left up to the browser. For most people, this will be purple, since that's the default Netscape color, but your display may vary.
Remember the warning about background colors and how they aren't always the same on different platforms? Unsurprisingly, the same holds true for text colors, as they're based on the same notation.
Okay, so now we can change the colors of everything. Cool, huh?
Well, yes and no.
I'd like to point out a few things regarding this ability. It can be very, very easily abused. Truly ugly pages are now within anyone's reach. Confusing or frustrating navigation paradigms are just a few keystrokes away. It isn't as dangerous as, say, nuclear weapons technology, but it can make the Information Superhighway as annoying as the term itself.
Let's take an easy example. Suppose you set a page up so that all the links, both active and visited, are colored black, the same as the normal text. Therefore, when a user reads the page, they have no way of seeing at a glance where the links are. (Remember that many users turn off link underlining, relying instead on link colors to guide them.) This could possibly be useful in certain limited cases, but the odds are that it's a bad design choice.
Of course, the same could be done with the background also set to black, which would make the text fairly hard to read. Other, less appealing possibilities abound as well-- how about peach-colored text with dark purple links on a lime green background? Yuck!
Similar issues come into play with tiled images. In general, it is best to pick an image which is either mostly light, or mostly dark, and set the text color accordingly. If the background image has areas of both light and dark, the text will probably clash annoyingly with the background, making it hard to read in places.
Remember that some users may have their browsers set to use their own colors and ignore yours. So, once again, you can't be sure that the user will see what you do. Also, as a general point, most users have been conditioned to expect that active, unvisited links will be blue, and visited links will be either red or purple. Breaking that paradigm is likely to confuse the user, at least for a few moments. In other words, a page featuring dark orange links which turn pink when followed against a cyan background might not be appreciated by the majority of users.
As always, the choice is yours. You must choose wisely.
Well, now that we've seen ways of spicing up images by adding maps, it's only fair to look at ways of taking text to the next stage. HTML 3.2 has added a number of new tags which are used to control the appearance of text, and most of them are forced, not logical, style tags. Some may feel this is not something for which we should be glad, but the tags are part of the specification now, so let's look at them in more detail.
For the last few years (the lifetime of the popular Web, if you will), text has been fairly boring. Oh, sure, you could boldface it, and headings were usually different size from the rest of the text, but it was all basically the same. Only links looked any different, generally being a different color. But changing the color of non-link text? No way. Until now, that is.
Using the FONT tag, one can alter the color of text, or the size, or both at once. You might think that this tag could also be used to change the actual font-- say, to specify that the text should be displayed in Helvetica-- but this is not the case. Only color and size may be controlled using this tag.
Back in Chapter 1, we talked about how to change the color of text by using the text and link attributes to the BODY tag. These work very well as document-wide settings, of course, but what if you just want to change the color of an isolated sentence or word-- or even a single letter? Using the container <FONT>...</FONT> and the color attribute, you can do just that.
Let's say we want word "maroon" to be colored maroon (makes sense, no?) in the following sentence:
References to Silsby&Clarke are in maroon.
All we need to do is enclose the word "maroon" in a FONT container, using the color attribute. Thus:
References to Silsby&Clarke are in <FONT color="maroon">maroon</FONT>.
Colors may also be specified using the triple-hex notation described in Chapter 1; you may use whichever system is easier for you. The color you specify in a FONT tag overrides any colors you may have set in the BODY tag of the document, so even if you've set the document text to be purple, <FONT color="red">...</FONT> will color red the text contained within. This is true of both regular text and hyperlinks.
As I mentioned, you can also change the size of the text using the FONT tag. This is done using the size attribute. The values of size are the numbers 1 through 7, and also relative values such as +2 or -1.
How do these work? We'll start with the absolute values (1-7). These numbers represent sizes from the smallest (1) to the largest (7), with the default value for normal-sized text being 3. So if you wanted to define little teeny text, like a legal disclaimer or the fine print in a contract, you would use the container <FONT size="1">...</FONT>.
Or, perhaps you want to make some text really big.
You may notice that the scale for FONT sizes is exactly backwards from headings, where the most important (and, therefore, usually the largest) heading is H1. It's a bit confusing, but unfortunately we're stuck with it.
Instead of assigning plain numbers, however, you can assign relative values. For example, let's say you want to make some text two "sizes" bigger than the rest of the text. This would be accomplished by using <FONT size="+2">...</FONT>.
Under normal circumstances, this is equivalent to <FONT size="5">, since 3 (the default) plus 2 equals 5. You can change this as well. Using the empty tag BASEFONT, you can set the size which is used as the default text size. The values are 1-7, the same as the absolute values for FONT size. So, if you want a document where the text is a little bigger than usual, you could use <BASEFONT size="4">.
This will have the effect of not only changing the default text size, but of shifting the actual size of FONT tags which use relative values for the size attribute. For example, the container <FONT size="+2">...</FONT>, in a document with a BASEFONT of 4, will effectively define text of size 6 (4+2=6).
You can see that using relative sizes is often advantageous, since it lets you preserve the relative sizing of text even if you start fiddling with the BASEFONT value.
What happens if the combination of BASEFONT and relative sizing pushes the size above seven, or below one? After all, <BASEFONT size="5"> and <FONT size="+3"> equals 8, does it not? As with so many other things, what happens at this point is more or less browser dependent. Some browsers will render the text as even bigger than text of size="7", while with others the sizes of 7 and 8 will be the same. It's pretty much universal, though, that values of less than one are rendered as size="1".
And yes, you can put these FONT attributes together, so that a word can really stand out:
It's up to the author to decide if such a combination is desirable. Also remember that not every browser will recognize the word "maroon," even if the FONT tag is understood.
In addition to the forced style effect of FONT, there are some other style tags. Let's go through them quickly.
The BIG and SMALL containers do about what you'd expect. Text enclosed in <BIG>...</BIG> gets bigger, and text in <SMALL>...</SMALL> gets smaller. By how much? Most browsers make size changes equivalent to <FONT size="+1"> and <FONT size="-1">, respectively. It need not always be so, however; with some browsers, the user gets more control than that. Therefore, BIG and SMALL cannot be guaranteed to be one-step changes in font size.
<SUB>...</SUB> and <SUP>...</SUP> are used to subscript and superscript text, so footnotes and chemical formulas are easier to display.
Not much more to say about them, really.
In a move sure to warm the hearts of lawyers everywhere-- refrain from the obvious jokes, please-- HTML 3.2 allows for the definition of strikethrough text. <STRIKE>...</STRIKE> is what causes this.
STRIKE may be supplanted by the more concise <S>...</S> in the near future, but there's no way to be sure. Netscape 2.0 and later already recognize both strikethrough tags, and the <S>...</S> construct is under consideration by the standards committee.
Speaking of things covered in previous works of mine, the ISO Latin-1 character entities have a few new text entities-- three, to be exact. These are:
That's all. But wait! The chapter isn't over yet...
Horizontal rules, that is. Quite a few attributes were added to the venerable <HR> tag, giving the author much more control over the appearance and placement of a horizontal rule (which I sometimes refer to simply as a "rule"). It's fair to warn you that in discussing them, I'm going to be showing a lot of different horizontal rules, which will make this section of the chapter look a bit fragmented.
The easiest attribute to start with is noshade. Using the noshade attribute, the "engraved" look of most browser's horizontal rules is abandoned in favor of a plain black line. Visually, this is sometimes desirable to an engraved line, which is classy and elegant but sometimes a bit too subtle.
<HR noshade>
Now let's say you want a nice, thick, solid line instead of the thin line most browsers will generate by default. You can increase the line's thickness using the size attribute. size is generally expressed in terms of pixels, so size="7" would create a horizontal rule seven pixels thick.
<HR noshade size="7">
Of course, the size attribute can be used regardless of the shading. Most browsers will display the following as an "inset" box running the width of the browser display window:
<HR size="10">
Okay, so we can increase the rule's vertical size. How about decreasing the horizontal size? It's easy to do if you use width, which can be expressed in two ways: as pixels or as a percentage of the display area. If, for example, you want a horizontal rule which is exactly 275 pixels wide, it would look like this.
<HR width="275">
The thing to remember here, though, is that not every browser window will be the same size. Therefore, on some screens the above rule will look like it's a little more than half the width of the display window. On others-- those running on Sun SparcStations, for example, or on those computers where the browser window to full-screen size-- the HR will look much skinnier in comparison to the size of the window.
You can get around this by using percentages instead. If you want a horizontal rule which is three-quarters as wide as the window itself, the following will do nicely:
<HR width="75%">
That way, no matter how narrow or wide the browser display window gets, the horizontal rule will always be seventy-five percent as wide as the display window itself.
Now that horizontal rules can be smaller than the window size, it makes sense that we should be able to assert more control over how they are placed. Perhaps unsurprisingly, this is accomplished using the align attribute. There are currently three possible alignments: left, right, and center. Let's take the last example and make a rule 'grow' from the right margin:
<HR width="60%" align="right">
By combining size, width, and align, some interesting effects are possible.
<HR size="10" width="20" noshade align="left">
<HR size="10" width="10" align="center">
<HR size="1" width="90%" noshade align="right">
As of this writing, there is no way to change the color of a horizontal rule using standard HTML.
Now that we've gone over ways of specifying document-wide behaviors, let's take a look at the ways in which you can do nifty things with structural elements within the document. This includes things like centering and general element alignment, ways of altering the appearance of lists, and embedding objects.
In HTML 2.0, the align attribute was used with the IMG tag, and not much else. Under HTML 3.2, lots of elements can be aligned, including paragraphs and headings.
Aligning is quite simple; all you have to do is add an align attribute. For now, align has three possible values: left, right, and center. Support for justify, which will force the text to line up along both the left and right margins, is planned for the future but not part of the specification. The default alignment for any element in a Western-language document is align="left".
The markup for a centered paragraph would be <P align="center">, and a right-justified Heading 1 would be <H1 align="right">. Any of these containers is closed with the usual end tag, so <P align="right"> would be ended with </P>. The end tag both ends the paragraph and the centering, so that's all you need. As an example:
<P align="center"> <B>Centered text. Cool!</B> </P>
Centered text. Cool!
It is, however, a bit tedious to put an align attribute in every paragraph and other element you want to have centered, especially if you're trying to center the whole document. Fortunately, you don't have to do this; instead, you can put a DIV tag around everything you want to have centered and give that container the align attribute. For more detail on DIV, we press on...
Unlike the metaphorical house to which Abraham Lincoln referred, divided documents can stand quite well, and may even improve from the operation. Let's take a look at how it's done before we worry about the reasons for doing so.
An author may create divisions of a document by using the DIV tag. DIV is a container, and the rules it asserts hold true throughout the container. One of the main attributes of DIV is align. Therefore, using DIV, the author can center several paragraphs and other elements using this single container.
<DIV align="center"> [.....lots of text contained in several paragraphs...] </DIV>
As I mentioned in the section on align, right justification is also possible, and full justification (getting the text to line up with both margins) is on the drawing boards.
Centering can be accomplished in another way: the CENTER container. First introduced by Netscape, CENTER has the sole effect of centering anything between <CENTER> and </CENTER>. In terms of what the user sees, this is no different than using <DIV align=center>. Using either construct is legal under HTML 3.2, since both tags are part of the specification. The drawback to CENTER is that it has only one possible use, whereas DIV is a more general construct, since it allows for multiple attributes. I tend to prefer using DIV, but that's a personal preference.
| CHAPTER 4: Lists |
There are three main types of lists. I've included the heading here because lists are basic text structures -- they just need a lot more explanation. That's what you'll find in the next section.
While simple in concept, lists can be very powerful in execution. There are three types of lists: unordered lists, ordered lists, and definition lists. The first two are very similar in structure, while definition lists have a unique setup.
The term "unordered list" may be a bit unfamiliar to you, but odds are you've heard of the "bullet list." That's exactly what an unordered list is -- a list of items, each one preceded by a "bullet" (a distinctive character; typically, a small black circle).
The list begins and ends with the tags <UL> and </UL> respectively. Each item in the list is marked using the <LI> tag, which stands for "List Item." <LI> has a corresponding </LI>, but this closing tag is not required to end the list item (although you could use one if you really wanted to). You can use as many list items as you like, up to your browser's built-in maximum, if any.
Here's the markup for a simple list:
<UL> <LI>Monday <LI>Tuesday <LI>Wednesday <LI>Thursday <LI>Friday </UL>
If you loaded an HTML page containing the markup above, you would see the days of the week, each one preceded by a "bullet." like so:
Almost anything can be put into a list item -- line breaks, entire paragraphs, images, links, or even other lists. For example:
<UL>
<LI>Monday
<LI>Tuesday
<LI>Wednesday
<UL>
<LI>6am - 9am
<LI>9am - 12n
<LI>12n - 3pm
<LI>3pm - 6pm
</UL>
<LI>Thursday
<LI>Friday
</UL>
In the above case, under "Wednesday" in the 'outer list,' you would find another unordered list (the three-hour blocks of time), which is referred to as a nested list. (In the markup above, I have indented the nested list for purposes of clarity; this is not required for the lists to work. Remember what I've said about whitespace...) Here's how it looks:
In theory, you could probably nest lists indefinitely, but a bit of restraint is called for. Don't nest them too deeply unless you absolutely have to, if for no other reason than aesthetics. Nesting lists too far can look pretty bad.
On the face of it, ordered lists look a lot like unordered lists, and a lot of the same rules apply to both constructs. The only difference in HTML is that instead of using <UL> and </UL>, an ordered list is contained within the tags <OL> and </OL>. Ordered lists are based on list items, just as unordered lists are.
However, when an ordered list is displayed in a Web browser, it uses an automatically generated sequence of item markers. In other words, the items are numbered. The markup for a simple ordered list, based on the first example in this chapter:
<OL> <LI>Monday <LI>Tuesday <LI>Wednesday <LI>Thursday <LI>Friday </OL>
The above markup will look similar to the previously discussed simple unordered list, with the important difference that each day of the week is numbered instead of preceded by a "bullet." In other words, it looks like this:
Ordered lists are as nestable as unordered lists, and you can nest unordered lists in ordered lists, as well as the other way around. This can get pretty complicated, but sometimes it's what you need.
As you might expect, definition lists begin and end with the tags <DL> and </DL>. However, unlike the unordered and ordered lists, definition lists are not based on list items. They are instead based on term-definition pairs.
Here's the markup for a basic definition list:
<DL> <DT>Do <DD>a deer, a female deer <DT>Re <DD>a drop of golden sun <DT>Mi <DD>a name I call myself <DT>Fa <DD>a long, long way to run <DT>Sol <DD>a needle pulling thread <DT>La <DD>a note to follow so <DT>Ti <DD>a drink with jam and bread </DL>
A good way to think of it is that <DT> stands for "Definition-list Term" and <DD> stands for "Definition-list Definition." When the above list is displayed, it arranges the elements such that each term is associated with the corresponding definition. The exact arrangement of elements may vary from browser to browser. Here's how the above markup comes out:
Similar to ordered and unordered lists, definition lists can be arbitrarily long. Almost any structure can be placed in a <DD> tag, but putting large-scale structures (such as paragraphs, headings, and other lists) in the <DT> tag is not legal, according to the HTML Specification 2.0. You can leave out one part of a DT-DD pair, but this is not recommended.
Definition lists are perfect for creating glossaries. For example, the Beginner's Web Glossary on our server is simply one relatively long definition list.
There is one attribute to the <DL> tag, which is compact. This causes the display of the definition list to be compacted. What does that mean? It means that the information contained in the <DD> will be displayed on the same line as the <DT> term, if possible. (By the way, Microsoft's Internet Explorer does not support this attribute, so the examples in this section aren't going to work if you're using Explorer.) The markup would start out:
<DL compact> <DT>Do <DD>a deer, a female deer <DT>Re <DD>a drop of golden sun .....
...and the entire compacted list would look a bit different than the first definition-list example. Thus:
Pretty neat, eh? One word of warning, though: this will only work when your terms are short enough to allow the definition to appear on the same line. If the term is too long, the definition will start on the next line, just as they would in an uncompacted list. Here's an example:
In the first case, the term "1." is so short that there is no problem with starting the definition on the same line as the term. In the second case, however, since the term is so long, the definition is forced to start on the next line.
In the next chapter, we'll see out how to spice up text even more by using what I refer to as "special-effect" tags.
Okay. As an example, let's say you're compiling a glossary. You decide to write a definition for "Web client" which reads, "see browser". Instead of leaving it as plain text, thereby forcing the user to scroll most of the way through the glossary to find "browser," you could set a named anchor around the term "browser" and then turn the word "browser" in the definition for "Web client" into a hyperlink to the label gl.browser-- and therefore to the term "browser." Got all that? In other words, the markup used to create the entry for "Web client" would be:
<DT>Web client
<DD>see <A HREF="#gl.browser">browser</A>
Meanwhile, the markup for the "browser" entry would be:
<DT><A NAME="gl.browser">browser</A>
<DD>A program which is used to access the Web.
The user, reading through the glossary, sees the definition for "Web client." He clicks on the hyperlink in the definition (the word "browser"). This causes the browser to jump to the entry for "browser" -- no scrolling required!
Remember plain old boring ordered and unordered lists? They've gotten a bit of a life in HTML 3.2, thanks to some new attributes.
To begin with, the "bullets" in unordered lists can be modified by using the type attribute. Legal values for type in this circumstance are circle, square, and disc. Let's say you want your bullets to be squares instead of the usual filled circles.
Note that the Windows95 version of Microsoft's Internet Explorer may not render the squares. I don't know why this is, but I've received reports to this effect, so if you're using MSIE, you may not see squares.
The markup to accomplish this effect is:
<UL type="square"> <LI>Monday <LI>Wednesday <LI>Friday </UL>
You can also set the type of individual list items as follows:
Markup:
<UL> <LI>Monday <LI type="square">Tuesday <LI>Wednesday <LI>Thursday <LI>Friday </UL> |
Result:
|
In most browsers, setting the bullet type of an item will cause all items after that to have the same type, which is the behavior called for by the HTML specification. Therefore, if you just want one item to have a different type, it should be done like this:
Markup:
<UL type="circle"> <LI>Apples <LI type="square">Bananas <LI type="circle">Oranges <LI>Mangoes </UL> |
Result:
|
The reason to assert the type in the UL tag is to ensure that all of the items' bullets (besides the square, of course) will be the same.
Ordered lists also allow alternate display types. In addition to the usual numbers that count from one to infinity, you can specify the use of letters or Roman numerals, in either upper or lower case.
Let's say you want a list of items which are marked A through F, rather than 1 through 5. Using the type attribute, it's no problem at all. While this is similar to the way type is used in unordered lists, the value is obviously different. For example:
Markup:
<OL type="A"> <LI>January <LI>February <LI>March <LI>April <LI>May </OL> |
Result:
|
If you wanted to use lower-case letters instead of upper-case, then you would use the tag <OL type="a"> rather than the 'A' shown above. This is one of the few cases in HTML where capitalization actually counts for something. Similarly, Roman numerals are specified using the values I or i, depending on which capitalization style you're after. Here's an example of lower-case numerals:
Markup:
<OL type="i"> <LI>Acknowledgements <LI>Publisher's Note <LI>Author's Note <LI>Foreword <LI>Introduction </OL> |
Result:
|
It's possible to switch styles in the middle of a list as well. For example, let's say you want a list that counts from 1 to 3, switches to small letters for the next four items, over to upper-case Roman numerals for two items, and then back to regular Arabic numbers for the end of the list. Here it is:
Markup:
<OL> <LI>January <LI>February <LI>March <LI type="a">April <LI>May <LI>June <LI>July <LI type="I">August <LI>September <LI type="1">October <LI>November <LI>December </OL> |
Result:
|
The type="1" sets the display to ordinary numbers. Note that the numbering is not reset with each style change. Each item's number is merely "translated" into the appropriate style, where necessary. Therefore, the seventh item above is "g," which is the seventh letter of the alphabet. The next item is "VIII," which is eight in Roman numbering.
You can also fiddle with the actual numbers that are displayed. This is done by setting a start number, or by setting the value of an item in the list. Let's start with start, since that somehow seems to make sense. By setting the start attribute in the OL tag, the list will start with a number other than one.
Markup:
<OL start=5> <LI>Bob <LI>Carol <LI>Ted <LI>Alice <LI>Mortimer </OL> |
Result:
|
On the other hand, you may want to assign a specific value to an item in the list. If you do so, then the items which follow will be numbered based on the value you assign. Therefore:
Markup:
<OL> <LI>Bob <LI>Carol <LI value=7>Ted <LI>Alice <LI>Mortimer </OL> |
Result:
|
As you can see, the item is set to the given value, and the items after that are numbered sequentially, using the specified value as a "base."
You can set values for one, some, or all of the items in the list. Therefore, in order to create a descending-order list (like a Top Five list, let's say), you will have to explicitly set the value of each item, as follows:
Markup:
<P>Top Five HTML Mistakes:</P> <OL> <LI value=5>No SGML prologue <LI value=4>Multiple line breaks <LI value=3>Badly defined frames <LI value=2>Not closing paragraphs <LI value=1>The BLINK tag </OL> |
Result:
Top Five HTML Mistakes:
|
As of this writing, both start and value must be given a number as a value, as opposed to a letter or Roman numeral. Therefore, <LI value="G"> is not legal, even if the display type has been set to upper-case letters. Be careful, and be aware that this could change over time.
Now it's time to tackle a complicated new structure in HTML-- tables. This will require two chapters to finish, so you might want to grab some snacks or go to the bathroom first. No, no, go ahead, I'll wait...
| CHAPTER 5: Images |
Besides hyperlinks, the other great advantage of the Web is the ability to integrate graphic images into a document. Some would argue that this represents one of the greatest strengths of the Web. Graphics are certainly used as heavily as hyperlinks, and represent most of the data which is transferred, so it's fitting that we spend some time discussing them. By the time you finish this chapter, you'll be able to create eye-catching pages that will make you the envy of your friends! Okay, so that would be the case if you had friends like mine. Never mind.
Images are placed in Web documents using the IMG tag. This tag is empty, and therefore has no closing tag. The basic form of the image tag is <IMG>, but just like <A>, <IMG> by itself is pointless-- it will do nothing. At the very least, you need to let the browser know where to find the image that it's supposed to place in the document.
This brings up an important point. Visually speaking, images are part of a Web document, but in reality an HTML file and any graphics it refers to are actually all separate files. In other words, one HTML file which has five graphics within it makes a total of six files required to make the page look right. These files are all stored on a Web server, but don't have to all be in the same exact place. (Often, server administrators will set up separate directories for pictures.)
In order to make the IMG tag work, you need to use an SRC attribute. SRC stands for "source," as in, "the source of this graphic." (One way to read a typical image tag is "image source equals..." You'll see what I mean in a minute.) The value of SRC is the URL of the graphic you want to have displayed on your Web page. Thus, a typical image tag will take the form:
<img src="URL of graphic">
The URL of the graphic is just like the URLs used in the anchor tag (see previous chapter), except in this case the location used is that of the graphic file. A graphic named "blat.gif" located in the directory "pics" on the server "www.site.edu" would have the URL http://www.site.edu/pics/blat.gif. You can use either relative or full URLs to refer to the graphic file.
Okay, but how does the browser know where to put a graphic once it's been loaded? In relation to the text, the browser puts a graphic wherever an image tag occurs in the document. It will do this as though the graphic were just another piece of the text (which, in a certain way, it is). For example, if you put an image tag between two sentences, the browser would show the first sentence, then the graphic, and then the second sentence right after the graphic. Thus...
Further inquiries should be directed to Jodi at x303.
<img src="pix/redsquare.gif">
There will be a meeting next Tuesday night...
...will look like this:
Further inquiries should be sent to Jodi at x303.There will be a meeting next Tuesday night...
Images can be placed almost anywhere within the body of the document. They can be between paragraphs, within paragraphs, in list items or definition-list definitions, and even within headings.
Placing images within links is also possible. To do so, merely place the IMG tag within the anchor container. For example:
<A HREF="http://www.site.net/">
<img src="generic-image.gif">
</A>
You can also mix in text to either side of the image, or both sides: it doesn't matter. Let's say that you wanted to put a link to a copyright notice, and you wanted to draw attention to the link with a small warning symbol. It might go something like this:
<A HREF="tcopy.html">
<img src="pix/warning.gif"> Unauthorized duplication is prohibited!
</A>
The above markup would then appear as:
Unauthorized duplication is prohibited!
As you can see, if you do include text within the anchor container, then it will be a part of the anchor along with the image.
There are two other attributes to the IMG tag which should be discussed in this tutorial. Both are less frequently used than SRC (because SRC is so essential) but each is important in its own way. In my opinion, the more important of the two is...
The ALT attribute is used to define "alternate text" for an image. The value of ALT is author-defined text, enclosed in double-quotes, and ALT text can be any amount of plain text, long or short. To pick one of an infinite number of examples, a warning symbol could be marked up as follows:
<img src="warning.gif" ALT="Warning!!!">
This ALT text will have no effect whatsoever in a graphical browser with image loading turned on. So what's the point? ALT improves the display and usefulness of your document for people who are stuck with text-only browsers such as Lynx, or who have turned image loading off. Since these users cannot see graphics, the browser will substitute a marker such as "[IMAGE]" for any image tag. This is, in effect, a placeholder, but a frustrating one, since there isn't any way for the user to tell what the image is, or what it says, or what its purpose is.
However, if ALT text has been defined, the browser will display that text instead of the placeholder. This makes the display a lot nicer and more useful for users who can't see the graphics, and doesn't affect users who can see graphics at all. A common trick to make image placeholder disappear in text-only browsers is to set the ALT text to be a single space:
<img src="generic-image.gif" ALT=" ">
Some people also use no space at all (ALT="") but this particular use of the ALT tag has been known to confuse certain Web browsers, including some older, but still common, versions of Netscape. For maximum safety, use the single-space ALT text.
Figure 1 shows two Lynx (text-based Web browser) screen-shots. The first (Figure 1a) is of a document with a number of images that have not had any ALT text defined. The second screen-shot (Figure 1b) is the same document, but this time the images have been enhanced with ALT text. Notice how the use of ALT tags significantly reduces the "clutter" in the document.
![[Figure 1: Lynx screens both with and without the use of ALT text.]](images/TCh7Fig1.gif)
In addition to character-based browsers, some graphical browsers will use the ALT text if automatic image-loading has been turned off. Therefore, ALT is really more of a consideration to the reader than it is a necessary component of the image tag, but it is still important to the design of any intelligently constructed Web page.
A lot of vertical space can be wasted when graphics are integrated into paragraphs. This is because ordinary HTML 2.0 does not support anything which allows for multiple lines of text flowing past a graphic.
However, the text can be shifted within the vertical space which is created by the graphic. In addition to having the text lined up with the bottom of the graphic, you can align it to either the top or the middle of the graphic. This is accomplished using the ALIGN attribute, as in the following:
<img src="generic-image.gif" ALIGN=top>
This will cause the top of any text on the same line as that graphic to be aligned with the top of the graphic. There is also an ALIGN=middle option, which will align the text's baseline with the middle of the graphic, and of course ALIGN=bottom, which is the default display strategy for most browsers.
While the above is all true for HTML 2.0, it is also the case that the HTML 3.2 specification supports the flowing of text around graphics (that is, allowing multiple lines to wrap around a graphic). The ability to flow text around a graphic is accomplished through the ALIGN attribute.
Before you go flying off to create the ultimate killer graphic, you need to remember that the "universal" standard (at least for the near future) is the GIF file format. GIF stands for Graphic Interchange Format, and all graphical browsers use that format for in-lined images. While this may change to some degree in the future, for now, my advice is to use GIF files in order to ensure maximum cross-browser compatibility.
Most advanced graphics programs will save to the GIF format. If they do not, they will usually save to a format like PICT or PCX, which can then be converted using another program. If you are not sure how to get your graphics into the GIF format, ask your local computer graphics whiz.
As you have probably guessed, a discussion of graphics could fill up its own tutorial-- there are issues like file sizing, when to use GIF and when to use JPEG, transparent areas, future development, and image mapping, just for starters.
Unfortunately, I haven't enough room in this tutorial to tackle this subject. Besides, most of it isn't about HTML, but more about style decisions, which is outside the scope of my intent for this work. There are some good style guides available; see Appendix C for some possibly useful links. I hate to leave you hanging like this, but as Dirty Harry once said, "A man's got to know his limitations." Sorry.
Of all the HTML 2.0 tags, the venerable IMG may have gotten the most dramatic upgrade. In all, there are six new attributes for IMG, and one of the old attributes was made much more powerful. We'll start with the old-made-new, take a side trip to another tag's new attribute, and then dive into the completely new attributes for IMG.
You remember align, don't you? It let you determine how text will be vertically aligned with an image contained in the same line-- top, middle, and bottom, among a few other values. Well, there are two new values for align: left and right. These are what you use to let text flow around an image [Figure 2.1].
That's rather a dramatic shift, isn't it?
Under these circumstances, the image becomes what's called a "floating image." This term is derived from the idea that an image "floats" down to the next line of text and over to whichever margin is defined by align (right or left), and any subsequent text flows around it. So align="left" would cause the image to float down and over to the left margin, and the text would flow around it to the right. Figure 2.2 show a side-by-side example of a regular image, and then the same graphic as a floating image.
Okay, what's all this about floating down one line? This happens in circumstances where the image would ordinarily not be placed against the defined margin. For example, if you put a floating image into the middle of a line of text, instead of being displayed partway across the page, the image will float down one line of text and over to the appropriate margin.
If you put the image at the beginning of a paragraph and float it to the left, the paragraph text will begin near the top of the image in question, and to the right side of it, as shown in Figure 1. If you put the image tag inside the paragraph text-- even after a single letter-- it will float down one line and over to the left [Figure 2.3].
This "floating" behavior is what causes the first line of text in the paragraph to be above the image, and not beside it. Again, this has happened because the image tag is somewhere with in the text of the paragraph-- say, after the word "computers," or between the first and second letters of the sentence. Therefore, care should be taken with the placement of floating images.
This does bring up a small wrinkle, however. The problem here is that everything-- text, horizontal rules, other images-- will flow around a floating graphic. What if you want to make sure that certain text starts after the floating graphic?
Ending a paragraph won't work, and neither will a single ordinary line break. You could put in a string of multiple line breaks, but that's not a very good idea-- what if the breaks go too far, leaving you with a lot of ugly blank space? Worse still, what if the browser is one of those which treats line breaks as whitespace and therefore collapses multiple breaks down to a single break?
What you need is a way of saying, "Insert a break here which will cause anything after it to start on the first line with a margin clear of this floating image." Fortunately, you have exactly that in the form of a new attribute for the BR tag: clear.
clear has three possible values: left, right, and all. If, for example, you want to make sure that you break past an image which has floated to the left, you would use <BR clear="left">. Starting on the first line with a clear right margin would employ <BR clear="right">, and if you want to start subsequent material on a line which has both margins clear of floating images, use <BR clear="all">. That's clear enough, isn't it?
Sorry. On to the new attributes for IMG!
Of course, in the process of floating an image, you may find that the text is snuggled up just a little bit too closely to the edges of your image. You can't use a text-space to keep the text away-- the image isn't really located next to that space any more!
Not to worry. Thanks to hspace and vspace, you can give your images a bit of breathing room. hspace and vspace stand for "horizontal space" and "vertical space," respectively. Both attributes are measured in pixels, and negative values are not permitted-- only positive integers.
Let's say you want to make sure your image has a minimum of ten pixels of blank space to either side of it. The markup would go something like this:
<img src="image.gif" align="left" hspace="10">
This will add 10 pixels of blank space to the left and right of the image. Note that in the above case, not only will this markup push any text 10 pixels away from the image, but it will push the image ten pixels away from the left margin. Here's a comparison:
No hspace attribute
hspace="10"
Similarly to hspace, vspace adds blank space to the top and bottom of an image. If you wanted six pixels of space above and below the image, then the markup would resemble:
<img src="image2.gif" align="right" vspace="6">
Getting six pixels of space all the way around the image would require:
<img src="image2.gif" align="right" hspace="6" vspace="6">
This usually brings up the question, "How do I simply add space to one side and not the other?" You can't-- not in HTML. You could create an image with some blank space built in, or you could wait for style sheets, which should offer this sort of capability. In plain old HTML, however, you can add space to both side margins, or above and below, or both. That's all.
Incidentally, you can use hspace and vspace on ordinary, non-floating images. It's simply much more common to use them on floating images.
You might think, upon first impulse, that border is a way to set blank space all the way around an image... but no. I wasn't lying in the last section when I said that you can't do that with HTML. border instead draws a visible border around the image. The value of border is the number of pixels thick you want the border to be.
Let's say you set the value of border to be 5. You'll get:
<img src="warning.gif" border="5">
Ick. Not very pretty, is it? And you can't even set the color of the border. You can make the border go away, though.
Once again, I hear the rustling of nonplussed users. Wait! Maybe this will interest you: if you have an image which is part of a hyperlink, setting border to 0 will make the highlight disappear! Here's the difference:
<A HREF="legal.html"><img src="warning.gif"></A>
<A HREF="legal.html"><img src="warning.gif" border="0"></A>
They both link to the same document... but one looks kind of ugly, and the other doesn't.
This effect is most often used to make rectangular, 3-D buttons look like buttons imbedded in the page, not like graphics with colored borders around them, with the colors changing from blue to red (or worse, from user-defined color to user-defined color) all over the page and ruining the delicate color balance the graphics create. Unsurprisingly, corporate sites love to use this trick.
Very important among the new attributes are height and width, both of which are measured in pixels. With these attributes, you can define the size of an image right in your HTML document. Let's say you have an image called icon.gif which is 50 pixels wide and 30 pixels tall. The markup for this image would be:
<img src="icon.gif" height="30" width="50">
Thus, when the document is loaded, the browser will actually know the dimensions of the image before it loads the graphic file!
All right, I realize that this may not seem like a big deal at first, but honest, it is. Let's look at the advantages first.
When you look at any Web page with even small numbers of images, realize that the vast majority of the data on that page is the graphics. Text takes up a lot less data room than images do. For example, a document which takes up roughly a single printed page, including markup, probably represents no more than 3KB of text. Four small pictures and a toolbar could easily total over 20KB (depending on the pictures). If your page has a lot of graphics, you could be looking at 4KB of text and 200KB of images, if not more. Obviously, it's a lot easier and faster to get text than it is to get images.
I'm probably not telling you anything you don't already know. Consider this, though: what happens if you're loading a page from overseas and it has graphics sprinkled throughout the text? In most browsers, the page loads to the point where it hits an IMG tag and then drops everything in an attempt to load the image. You're left looking at the first few paragraphs of the document while you wait for your browser to finish loading the image. Once it's done so, it goes back to loading text-- until it hits another image, at which point everything stops dead once again, forcing you to wait until that next image has been loaded. And so on.
However, if the browser understands height and width, and you've used them, then it doesn't have to wait for those images. It will keep loading text and leaving open blank areas based on the values of height and width. Then, once the page is loaded, the browser goes back and starts filling in those blank areas with images. In the meantime, you can be reading through the document, and perhaps moving on to another one, without having to wait for all those images.
As an author, height and width may seem like an annoyance. To the reader, however, they're a godsend. No more waiting for big, flashy graphics before being permitted to view the actual content of the page! What a concept! If the author has used height and width, this is possible. Therefore, use of these attributes should be regarded as a courtesy to your readers.
One thing you may be tempted to do is resize graphics using the height and width attributes. Please don't. In the first place, only browsers which support these attributes will do the resizing, so if it's important to have the graphic be a certain size, produce a version at that size. More importantly, the usual application of this technique is to make graphics smaller. This forces the reader to download a large graphic only to have it show up small on his screen. Why make the user wait? Produce a small graphic which is quick to download instead.
Multimedia
Here is an example of how to insert a multimedia file in your HTML document:
|
To embed a single file: auto start (start on page load ) It is hidden and repeats. <embed src="http://YOUR URL.mid" autostart="true" hidden="true" loop=true>< To change this so that it does play automatically in page load:
To change this so that it only plays once:
Allowing Users to Control the Music:
<embed src="http://YOUR URL.mid" height=16 width=47 autostart="true"
controls="smallconsole" loop="true">>
|
| CHAPTER 6: Tables |
All right, it's time to learn about tables! This subject will take two chapters to get through. The first of the two chapters-- that's this one-- will explain how tables are constructed and introduce all of the tags related to tables. The second chapter will discuss in gory detail the various attributes you can add to the tags, and how they can be used to create some very interesting effects.
To start with, tables are containers, so a truly minimal (if useless) table would have the following markup:
<TABLE> </TABLE>
Okay, okay, it's boring, but it made the point, right? Right. All other table elements will go between those two tags. That's simple enough, isn't it?
Before we go any farther, I'm going to mention an attribute of the TABLE tag which gets a lot of use. Ordinarily, a table will be rendered without any borders, so that the data is arranged in discrete cells, but the cells themselves can't be seen. This can be useful, but most of the time, it helps to be able to see the actual structure of the table. To do this, just add the word border to the TABLE tag, so that the opening tag looks like this:
<TABLE border>
This isn't the only attribute to TABLE, but the rest will wait until the next chapter. I only bring border up now because I'm going to be using it a lot in this chapter, and I thought you should know ahead of time what was going on.
Okay, back to the theoretical discussion. Each table is divided into rows, and each row is divided into a number of cells. Therefore, when you're planning a table, think of it as having this basic structure:
The next chapter will introduce more specifics (and a few wrinkles) concerning this model, but for now, let's stick with the way of thinking shown in Figure 1. The height of each row, incidentally, is determined by the height of the tallest cell in that row. The browser itself will automatically figure out how tall that is, based on the data it has to display and the way that data has been arranged.
Each row is specified using the "table row" container, comprised of the tags <TR> and </TR>. Therefore, a blank three-row table would be written as:
<TABLE> <TR></TR> <TR></TR> <TR></TR> </TABLE>
This still isn't enough for a useful table, however. Each row needs to be divided into a number of cells.
Note that there is no way to explicitly specify how many cells are in a given row-- that number is implicit in the cells themselves. In other words, if a row container has four cell containers in it, then that row obviously has four cells. And how, you are no doubt asking, does one specify a cell container?
There are two ways, actually, because there are two types of cells: data cells and heading cells. We'll look at data cells first, since they tend to be much more common.
A data cell is specified using the container <TD>...</TD>, and there can be any number of these cells in a given row. The contents of a data cell are generally referred to as "table data," which is where the letters TD come from. Any kind of information-- text, images, and so on-- is considered data for the purposes of tables. Therefore, most of your cells will contain data of one kind or another:
<TABLE border> <TR> <TD>one kind</TD> <TD>another</TD> </TR> </TABLE>
| one kind | another |
As you may have guessed, the markup for a table can get to be very large very quickly. If you have a table that is four rows of seven cells each, and your markup looks similar to that shown above (each row tag is alone on a line, and each cell gets a line of its own), then markup for this hypothetical 28-cell table would be 38 lines long! Things get even worse if you have a lot of