Lesson 10

In this lesson, we'll take a break from the more testing stuff of learning new tags and attributes, and look at a few of the ways we can make life easier for ourselves when creating web pages.

If you have any experience of programming, you'll know that programming languages usually provide a way for developers to insert "comments" into their source code. These comments are ignored completely by the language interpreter or compiler, but they allow programmers to "write notes" to themselves within their code. All teachers and writers on programming underline the value of commenting code clearly and extensively, the principal reason being that while you may know today what this variable means or that subroutine does, many months after you have finished the program you will surely have forgotten. So when some time down the line you need to make a change to the program, it will be much easier to follow your original line of thought if you have put plenty of meaningful comments into your source code.
The same is true of creating web pages, even though there is typically less complexity in the coding than is true of most programs. If you use templates (which we'll talk about later in this lesson) for creating and maintaining consistently-styled web pages, comments in the template would be a useful way of pointing out what kind of content gets inserted where in the template.
Happily, HTML furnishes a method for putting comments into our code, just like real programming languages. Here's how to do it:
<!-- this is a comment -->
An important point to note: You must not have any white space in between the "<!" (called the "declaration open delimiter") and the first "--" (the "comment open delimiter"). However it is permissible to have space between the final "--" (the "comment close delimiter") and the ">" (the "declaration close delimiter"). For this reason, you should avoid putting two or more adjacent hyphens inside comments except for the comment delimiters. A common error seen in many authors' HTML code is a string of hyphens inside comments.
If you make sure you start every comment with "<!--" and end with "-->", and you don't have any other hyphens between the delimiters, then you'll be just fine.
Another feature of comments is that white space and line breaks within the comment string itself are permitted, just like any other HTML code. So you can have a comment like this:
<!-- this is another comment
which this time, spans two lines -->
And of course, when a browser encounters a comment in the course of parsing (interpreting) an HTML file, it simply ignores it. This page you're looking at right now, for instance, has many comments in the source code, but these are invisible on screen.

HTML, like many programming languages, is quite flexible in the way that it lets us lay out our source code, as it pays little attention to line breaks and extraneous white space. How you lay out or format your source code is largely a matter of personal preference, but it is a subject of much interest in the programming world, and entire chapters of books and software manuals are devoted to it. The main thing is that your code should be easy to read, and the logic behind what you are doing should be evident. This is particularly important if there is a possibility that future maintenance on your work will be done by someone else, who was not privy to your particular thought processes when the web pages were originally being created! (That's also a good reason for including lots of clear comments.)
That said, let's take a look at one approach. Review the layout of a sample HTML file.
I hope the text in this sample explains adequately the idea of indenting to reveal structure and clear pairing of opening and closing tags, where required. Now, if you've followed my example and got yourself a copy of Arachnophilia, you can type in your code any old way, then at the push of a couple of keys, Arachnophilia's "Beautifier" will leap into action and automatically format your file in this fashion.
But as I say, it's all a matter of taste, so try different approaches and see what you like best. Have a look at the way other people lay out their code. There are examples everywhere -- books, magazine articles, and of course, on the Web itself! Most browsers have an option called something like "View" on their menu bar, from which you should be able to select something like "View Source" or "View Page Source". When you select it, the source code for the file you are looking at will open up (in its own viewer, or in the computer's text editor, or perhaps in an application that you've specified in the browser's Preferences).
Be aware, though, that some people's code looks horrid. Sometimes this is because they made it that way; sometimes it's because they used a WYSIWYG web page design program to create their code for them: many of these programs output notoriously untidy (not to mention error-filled) code. Another warning about these kinds of programs: if you originally create your file in an editor like Arachnophilia or Notepad, then later import it into a WYSIWYG editor, you might well find that the WYSIWYG editor destroys the formatting of your file! It might also actually change some of the code, to do things the way it likes them to be done, rather than the way you like them to be done. They are also inclined to "fix" problems that didn't actually exist, too. Didn't I say back in the Introduction to this tutorial that there are disadvantages to using these programs?

If you use a word processor program like Microsoft Word or Lotus Word Pro, you'll probably be familiar with the concept of templates (or Smart Masters, or Style Sheets, or whatever your particular word processor may call them).
The idea behind templates is that if you are going to produce similar documents over and over again -- where perhaps the layout and structure are identical, and it is only the content that varies -- you create a template that contains all of the "standard" structural and stylistic elements. Then each time you have to create a new document of this type, you start with the template and "fill in the blanks". A simple example would be a letterhead, where you already have your name and address entered on the template, and you define in the template the page margins, the location of the recipient's address, and perhaps the typeface to be used.
It's equally easy and useful to create templates in HTML, and with similar advantages. Let's say you're creating a large web site, with tens or maybe even hundreds of pages. If you create a basic page template into which you can "plug" the unique content for individual pages
These are very worthwhile gains. As well as saving time, templates reduce the opportunity for error. Once you have checked and tested your template code, you can be sure that it works and concentrate on the content of the individual pages. And applying a consistent style throughout your site by using templates lends a professional appearance to your work -- just look at big corporate web sites to see what I mean. Large corporations use templates for their sites to preserve a sense of "corporate identity" throughout.
I'm not suggesting that every page on your web site should use the same template (though it might), but perhaps every page in the same "section" should.
Of course, I use templates extensively. As you might guess, this tutorial site is based around a template, so that every page has the same background, the same positioning of navigation buttons, and the footer information at the bottom of each page.
Let's review another example, this time for the front page of an imaginary company newsletter. First, take a look at the result of the basic template. Doubtless you can see where the information for each issue is to be inserted (date, names of story authors, and story summaries).
Next, examine the code for the template.
The first thing you'll notice is that the code is multicoloured. I did this just to show you how the code might appear in many HTML editors like Arachnophilia. In this example, HTML tags and attributes are coloured blue, attribute values are green, and text to be displayed on the web page is black. This contextual colouring is usually linked to a syntax checker which makes it easy to debug your code by highlighting the location of errors.
The next thing you'll notice is that there are a bunch of tags like <TABLE>, <TR> and <TD> that you haven't seen before. Don't worry about this; these relate to tables, which by a remarkable coincidence is the topic of our very next lesson!
The important points are:
You can probably see a repeating pattern -- this is what you might expect, since when you saw the output of the template, you saw that there were four areas for entering details of the story authors, and four areas for entering summaries of the stories.
Good use has been made of comments within the code to indicate where content is to be inserted or details are to be changed according to the needs of the issue, for example:
<!-- ***ENTER DATE BELOW*** -->
<!-- ***ENTER LINK TO FIRST STORY BELOW*** -->
<!-- ***ENTER AUTHOR OF FIRST STORY BELOW*** -->
I like to put some asterisks in the comments that indicate where text is to be inserted or modified, to draw attention to these areas. I don't put asterisks in other "information only" comments to distinguish them.
Now take a look at a page once some "real content" has been put into the template.

Comments are useful for indicating your train of thought in your HTML code, and benefit both you and anyone else who may have to maintain your code in the future. Comments are placed between the comment delimiters "<!--" and "-->" thus:
<!-- this is a comment -->
You should think about and take some care in the way that you format your code, for the sake of making it as easy as possible to read and understand. Some HTML editors can help you with this; others (notably WYSIWYG editors) can make a real dog's breakfast of things!
Using templates simplifies creating and maintaining large or small web sites, saving you typing effort and the potential for error, and giving a consistent appearance to your pages.
<< Go back to Lesson 9 | Top | Go on to Lesson 11 >>
Copyright © Keith W Bell, 1999 - 2001
This page last updated 1 February 2001
http://www.campanile.org/tutorials/html/lesson10.html
|