Appendix C of Keith's HTML Tutorial

There are many things I haven't told you in this tutorial. Some things I've omitted because they might have caused you confusion; some things I've omitted because they are more complex topics than I planned to include in what is essentially a "start from no knowledge" introduction to HTML; and some things I've omitted because if I didn't, I'd never get this tutorial finished!

So in this Appendix, I'll tell you a little about these things, or I'll tell you why I'm not going to tell you about them. So here we go, in no particular order.

Previously I've told you that most tags come in pairs, an opening tag and a closing tag, that act as a "container" for what goes between: like the <BODY> and </BODY> tags contain everything in the body of the web page. I've also shown you that some tags have no closing tag, like <IMG>: these are "empty" containers.

However the HTML specifications define some tags as having an "optional" closing tag. For example, the <LI> list item tag. What this means is that if you like, you can leave out the closing </LI> tag, and it will still work and still be valid HTML. For example this:

would be perfectly valid HTML code. However, I recommend that you don't omit closing tags, for two reasons:

Some people say omitting optional tags saves typing and also helps keep your file sizes small, but hey! It's not a lot of work (especially if you use an editor like Arachnophilia or PageSpinner, that will insert the tags automatically for you), and the saving of a few bytes in your file will make no appreciable difference to download times for your web site visitors. Plain text downloads much faster than graphics.

If you've been surfing the 'net for any length of time, you'll have come across sites with forms that you can fill in to send information to the web site owners: feedback forms, enquiry forms, guestbooks and the like.

I chose at this stage not to include anything about forms, not because the HTML is particularly difficult (no more so than tables or frames), but rather because of the difficulties in processing the form. To do this effectively requires server-side processing using CGI scripts. In other words, you have to set up a program on your web server to handle the form.

So I've set this aside for now. But perhaps in a future update to this tutorial...

And image maps are rather a similar story. You may have seen web sites where a large graphic is used for the navigation (a map is a common metaphor) and clicking your mouse on different areas of the graphic takes you to different pages on the site. These are called image maps.

In the past, image maps all required server-side programming to make them work, which is one reason for leaving them alone at the moment. More recently, however, client-side image maps have been introduced where the processing is done on the user's computer. These are easier to set up, and actually have some advantages over server-side maps. Unfortunately, unlike server-side maps, they don't work with every browser. So you always need to incorporate an alternative navigation mechanism (which can be a server-side map!).

As well as forms and image maps, there are other elements of HTML that I haven't covered, because hey, you've had enough to learn already! Take a breather, get to grips with what you've covered so far -- then go on to learn some more from the resources I've listed in Appendix D.

Take it from me, though, the things that I've skipped aren't major omissions, and some folks might argue that they have pretty limited usefulness.

I haven't mentioned these terms to you before, but every HTML element (the things represented by tags) used in the BODY of a document is either a block-level element or an inline (sometimes called text-level) element.

As a general rule, block-level elements can contain both inline elements and other block-level elements as well as data. Block-level elements generally begin on new lines, though whether any additional white space is inserted before the new element depends on both the element and the browser.

By contrast, inline elements can contain only data and other inline elements. (As HTML 4.0 states: "Inherent in this structural distinction is the idea that block elements create ‘larger' structures than inline elements".) In other words, you should not place block-level tags inside inline tags: this is not valid HTML, and the results in browsers would be unpredictable. Also in contrast with block-level elements, inline elements do not begin on a new line.

I've prepared a table that shows whether an element is block-level or inline. If in future you want to look at this table without opening the tutorial, the name of the file to load is "elements.html".

This is a point to watch out for when validating your code. One of the commonest causes of errors detected during validation is having a block-level element nested inside an inline element. For example:

Hello, World!

Hello, World!

META data is "data about data", and the <META> tag -- which fits inside the <HEAD> and </HEAD> tags -- allows us to enter information about the information in our document. WHY? I hear you ask. The most obvious example (and the only one which really works to any extent, and even then it's limited) is to help search engines to make a better job of indexing our pages.

<META name="" content="">

A search engine that is wise to the tags will use the META data to match up with the words entered by users when searching. For example, an (imaginary!) florist's business might use tags like these:

<META name="description" content="Foxglove Flowers is a florist and fruit supplier with branches in Edinburgh, Livingston and Haddington. We make deliveries from Monday to Saturday throughout the East of Scotland"> <META name="keywords" content="florist, florists, flowers, fruit, bouquets, floral arrangements, floral displays, wreaths, fruit baskets, flower deliveries, Interflora">

Remember that the <META> tags must be enclosed in the HEAD section of the document. All of the data is enclosed within the tag itself, and there is no closing tag.

These two versions of the tag are worth including, even though not all search engines make use of them. There's a certain skill in applying them well, and I don't propose to go into greater detail here: the example above should give you the general idea (note that it can be worthwhile to include singular, plural, capitalised and non-capitalised versions of words).

It's likely that META data will assume an increasing importance in the future, as search engines, browsers and other user agents become "smarter" in their ability to use the data.

You've probably seen how in many web pages, an email address is presented as a link, like this: myname@mydomain.com. When a viewer clicks on this link, the browser might launch its own email program (or another email program like Eudora, if it has been configured to do so), with the email address already entered in the message window. Note that I say might, because this feature depends on the browser. If the viewer is using Netscape Navigator, Internet Explorer, Opera, or a number of other browsers, this will work. However, whether the user can take advantage of the feature and go on to compose and send an email depends on whether they have configured the email program properly to dial up their email account.

To include this feature in your own pages, you assign a "mailto" URL to the href attribute in the <A> tag. For instance, here's the code snippet for the example that I gave above:

...an email address is presented as a link, like this: <A href="mailto:myname@mydomain.com"> myname@mydomain.com</A>. When a viewer clicks...

Simply prefix the required email address with "mailto:" in the href attribute.

Note that this "mailto" method is not part of the HTML specifications, but it is quite widely used and supported.

Strictly speaking, HTML does not provide for true typographical quotation marks, apostrophes or "em" dashes: you can only use "typewriter" quotes (remember the character entity "?) rather than “real” quotes, and ' as a pale imitation of ‘real’ single quotes.

There is actually a way to get proper typographical characters, but it comes with a "government health warning"! Whether a viewer sees these marks as they should depends on the browser that he or she is using. The major browsers like Netscape Navigator, Internet Explorer and Opera will display these characters correctly, but some others will not. They may instead display a spurious character -- perhaps a small square, for example.

Now that I've warned you of the pitfalls, I'll tell you how to do it. Instead of entering the usual character or character entity in your HTML, you replace it with another code according to the table below.

Knowing your audience helps in your judgment of whether or not to use these "high ASCII" characters. If you want to be sure that everybody can read your pages without funny symbols popping up, then don't use them. If you know all your likely viewers are using a browser on which these codes work, then go ahead, if you choose.

Of course, whether you can see the true typographical characters in the places they were intended to appear above, depends on whether your browser supports these codes! You may be looking at something totally weird...