4.2. Web page Basics

4.2.1. Format of Web Page Markup

Documents can be presented in many forms. A simple editor like Idle or Windows’ Notepad produce plain text: essentially a long string of meaningful characters.

Documents can be displayed with formatting of parts of the document. Web pages allow different fonts, italic, and boldfaced emphases, and different sized text, all to be included. Microsoft Word, Open Office, and Latex, all display documents with various amounts of formatting. The syntax for the ways different systems encode the formatting information varies enormously.

If you look at an old Microsoft Word .doc document in a plain text editor like Notepad, you should be able to find the original text buried inside, but most of the symbols associated with the formatting are unprintable gibberish as far as a human is concerned.

Hypertext markup language (HTML) is very different in that regard. It produces a file of entirely human-readable characters, that could be produced with a plain text editor.

For instance in HTML, the largest form of a heading with the text “Web Introduction”, would look like

<h1>Web Introduction</h1>

The heading format is indicated by bracketing the heading text ‘Web Introduction’ with markup sequences, <h1> beforehand, and </h1> afterward. All HTML markup is delimited by tags enclosed in angle brackets, and most tags come in pairs, surrounding the information to be formatted. The end tag has an extra ‘/’. Here ‘h’ stands for heading, and the number indicates the relative importance of the heading. (There is also h2, h3, .... for smaller headings.) In the early days of HTML, editing was done in a plain text editor, with the tags being directly typed in by people who memorized all the codes!

With the enormous explosion of the World Wide Web, specialized software has been developed to make web editing be much like word processing, with a graphical interface, allowing formatting to be done by selecting text with a mouse and clicking menus and icons labeled in more natural language. The software then automatically generates the necessary markup. An example used in these tutorials is the open source Kompozer, available at http://kompozer.net.


Careful - although this is free, open source software, the URL is Kompozer.*net*, not Kompozer.org. There is a site Kompozer.org that is designed to confuse you!)

You can open Kompozer and easily generate a document with a heading, and italic and boldfaced portions....

4.2.2. Introduction to Static Pages in Kompozer

This section introduces the Kompozer web page editor to create static pages. A static page is one that is created ahead of time and just opened and used as needed. This is as opposed to a dynamic page, which is a custom page generated by software on demand,given some input parameters.

Kompozer is used because it is free software, and is pretty easy to use, like a common word processor. Unlike a common word processor you will be able to easily look at the HTML markup code underneath. It is not necessary to know a lot about the details of the markup codes for HTML files to use Kompozer, but you can see the results of the markup.

We will use static pages later as a part of making dynamic pages, using the static pages as templates in which we insert data dynamically.

To creating static web pages

  1. If you are in a Loyola University Windows lab, follow the sequence of selections Start menu ‣ Loyola software ‣ Math and Computer Science ‣ Kompozer. (It may be under Internet instead of Math and Computer Science instead.) You may get pop-up window wanting to count users of Kompozer. Click OK as another user of Kompozer.
  2. However you start Kompozer, go to the menu in Kompozer and select File ‣ New. You will get what looks like an empty document.
  3. Look at the bottom of your window. You should see a Normal tab selected, with other choices beside it, including a Source tab. Click on the Source tab. You should see that, though you have added no content, you already have the basic markup to start an html page!
  4. Click again on the Normal tab to go back to the Normal view (of no content at the moment).
  5. Assume you are making a home page for yourself. Make a title and some introductory text. Use regular word processor features like marking your title as Heading 1 in the drop down box on a menu bar. (The drop down menu may start off displaying ‘Paragraph’ or ‘Body Text’.) You can select text and make it bold or italics; enlarge it ... using the editing menu or icons.
  6. Before getting too carried away, save your document as index.html in the existing www directory under your earlier Python examples. It will save a lot of trouble if you keep your web work together in this www directory, where I have already placed a number of files yo will want to keep together in one directory.
  7. Just for comparison, switch back and forth between the Normal and Source views to see all that has gone on underneath your view, particularly if you edited the format of your text. Somewhere embedded in the Source view you should see all the text you entered. Some individual characters have special symbols in HTML that start with an ampersand and end with a semicolon. Again, it is more important the understand that there are two different views than to be able to reproduce the Source view from memory.
  8. You can use your web browser to see how your file looks outside the editor. The easiest way to do this is to go to the web browser’s menu and select something like File ‣ Open File, and find the index.html file you just wrote. It should look pretty similar to the way it looked in Kompozer, but if you put in hyperlinks, they should now be active.

The discussion of web page editing continues in Editing HTML Forms, but first we get Python into the act.

4.2.3. Editing and Testing Different Document Formats


In this chapter you will be working with several different types of documents that you will edit and test in very different ways. The ending of their names indicate their use.

Each time a new type of file is discussed in later sections, the proper ways to work with it will be repeated, but with all the variations, it is useful to group them all in one place now:

My convention for regular Python programs taking all their input from the keyboard, and producing output displayed on a web page. These programs can be run like other Python programs, directly from an operating system folder or from inside Idle. They are not a final product, but are a way of breaking the development process into steps.
Python program to be run by a web server. You will develop code using a local web server on your own machine.

Web documents most often composed in an editor like Kompozer. By my convention, these have a sub-categories

not intended to be displayed directly in a browser, but instead are read by a Python program (...cgi or ...Web.py) to create a template or format string for a final web page that is dynamically generated inside the Python program.

Other files ending in .html are intended to be directly viewed in a web browser. Except for the simple static earlier examples in Introduction to Static Pages in Kompozer, they are designed to reside on a web server, where they can pass information to a Python CGI program (...cgi).

To make this work on your computer:

  1. Have all the web pages in the same directory as the example program localCGIServer.py. It is easiest to leave it in the www subdirectory of your examples directory.)
  2. Include the Python CGI server programs in the same directory.
  3. Have localCGIServer.py running, started from a directory window, not from inside Idle
  4. In the browser URL field, the web page file name must be preceded by http://localhost:8080/. For example, http://localhost:8080/adder.html would refer to the file adder.html, in the same directory as the running localCGIServer.py. The URL may either by an html file or possibly a CGI file. For example, http://localhost:8080/now.cgi would call the file now.cgi (assuming it is in the same directory as the running localCGIServer.py).
  5. Most often CGI programs are referenced in a web form, and the program is called indirectly by the web server. CGI programs can be edited and saved inside Idle, but they do not run properly from inside Idle. They must be run via the server/browser combination. More on this later.