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 that appear in the final text you view.

Documents can be displayed with formatting of parts of the document. Web pages allow different fonts, italic, and boldfaced emphases, and different sized text and paragraph layouts. Microsoft Word, Libre Office, and OSX Pages, 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, but the markup parts of the file do not appear directly in your browser, but instruct the browser how to format the page.

For instance in HTML, the largest size 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!

We will use little enough of the markup that the very limited introduction in HTML Source Markup, along with samples that show easily modified examples, will cover all the markup you need for the course.

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. In this tutorial, a possible example for Windows users and Macs that are NOT upgraded to the Catalina OSX version, is the free, open source Kompozer from https://sourceforge.net/projects/kompozer/. It downloads the appropriate version for either a Windows machine or Mac with operating system version before Catalina. Users of Catalina, or later OSX versions, can look at the introduction to the Mac app TextEdit in HTML Source Markup.

If your operating system fits, you might download Kompozer, if you are not already using another environment that lets you see both the unformatted plain text and the formatted view.

An alternative for the simple markup needed for exercises is to modify example html source code using the ideas in HTML Source Markup.

4.2.2. Introduction to Static Pages in Kompozer¶

If you cannot run Kompozer, you can see the parallel html source discussion in HTML Source Markup, and skip this section that is specifically on 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.

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

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. However you start Kompozer, go to the menu in Kompozer and select File ‣ New. You will get what looks like an empty document.
2. 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!
3. Click again on the Normal tab to go back to the Normal view (of no content at the moment).
4. 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.
5. Before getting too carried away, save your document as home.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 that you will want to keep together in one directory.
6. 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.
7. 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 home.html file that you just wrote. It should look pretty similar to the way it looked in Kompozer, but if you had 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¶

Note

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:

...Web.py
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 in a testable way.
...cgi
Python program to be started from a web browser and run by a web server. You will develop code using a local web server on your own machine.
...html

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

...Template.html
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, the pages for this course are designed to reside on a web server, and include forms that 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. Looking ahead to when we get to using a server dynamically (CGI - Dynamic Web Pages):
1. Include the Python CGI server programs in the same directory.
2. Have localCGIServer.py running, started from a directory window, not from inside Idle
3. 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).
4. 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.