2.1 A Brief History of Web Authoring

For years, authors have struggled with downloading documents via HTTP, uploading documents via FTP, and exchanging documents via email. The "Stone Age" of Web authoring was the time before any Web authoring tools existed. The only Web software available was the Web browser (HTTP client) and the HTTP server. These were only available on Unix operating systems initially, although Windows-based browsers emerged quickly. Many Web pages were authored in the same location where they were published (in place) using text editors. This approach meant that authors of Web sites had to have Unix user accounts on the Web server.

2.1.1 HTTP Editing

Tim Berners-Lee wanted users to be able to edit documents as easily as they could browse documents on the Web. To this end, HTTP includes two methods that theoretically allow Web pages to be updated: PUT, to create or change a file, and DELETE, to remove a file. Some Web servers allowed these two methods, which meant that the user could theoretically update existing pages.

Soon, however, authors turned from HTTP to other mechanisms (such as FTP and local file copying). HTTP didn't work for these authors for a number of reasons.

• At the time, HTTP didn't have an authentication model administrators trusted. Without that, allowing changes was too insecure. Many administrators disabled PUT and DELETE completely.

• HTTP did not have a concept of collections, so there was no way to decide where to put a new Web page.

• Early HTTP browsers focused on browsing and did not support editing. Text editors did not support HTTP. Thus, files had to be edited using one tool and uploaded to the server using another tool.

2.1.2 Editing via Remote Login

Unix users commonly make changes to a file on another machine by logging in to the remote server and launching a text editor remotely. The rlogin command allows login from a Unix workstation to a Unix server. The Telnet protocol can be used to log in to any server supporting that standard, using client software freely available for any platform. Once logged in to the remote server, the user can issue commands on the remote server, such as a command to rename a file on the remote server.

The first problem is that although remote login is an easy way to move and copy a remote file, it is not easy to edit the file. To edit the file, the Unix user has to launch a text-editing tool installed on the remote server. Since Telnet and rlogin support text exchange only, this capability is limited to tools that have text-only user interfaces, such as vi or emacs. Finally, the user has to have a system account to log in to the remote server, and that account must be granted access to both the file and the editing tool.

A similar but somewhat better option for Unix workstation users was to mount a Unix-based Web server's file system via Network File System (NFS), Andrew File System (AFS), or something similar. Then the pages could be edited as if they were local. In that situation, Graphical User Interface (GUI) text editors could be used.

Note with all these approaches, the author had to find out manually where the Web content was stored in the file system namespace. For example, my first Web home page in 1993 could be downloaded at the address:

http://www.csclub.uwaterloo.ca/~ldusseault/index.html

but I had to log in to csclub.uwaterloo.ca remotely from a student lab and then navigate to and edit the page at the location /home/users/ldusseault/web/index.html.

Windows users worked the same way. In universities and many companies, even if the desktop machines ran Windows, Web developers had to have Unix accounts on the Unix Web server. Just like Unix users, Windows users had to Telnet to the Web server to edit pages. To edit my Web pages in 1993, I used Telnet from a Windows desktop (or a dumb Unix terminal) to connect to the Unix server. I used vi to edit pages within the Telnet window and a Web browser named Cello to view the results. Luckily, I had learned to use vi before, so I already knew some of the esoteric incantations and input modes.

At first, none of the tools used to edit Web pages had any functionality related to either the HTTP protocol or the HTML format, and these tools could not understand HTTP URLs. General-purpose editing tools like vi require authors to know all the codes for HTML elements as well as where to find Web page source files on the file system.

2.1.3 Editing and Copying

Editing pages in place can lead to publicly embarrassing errors. Since HTML pages were edited without the assistance of a tool that understood HTML, it was all up to the author to create syntactically correct HTML. Errors inevitably happen, and if a Web page is edited in place it can't be tested without also making the errors publicly visible until they're fixed. My Web pages had a small enough readership (two or three?) that I could afford to experiment directly, but authors of more professional Web sites preferred to author and test in one location and then copy the finished product to the Web publishing location.

Editing and then copying sounds simple, but it typically involves the following steps, each step using different tools:

1. Edit the page using a text editor. Save locally or to an unpublished local network location.

2. Load the page in progress into a browser to see the effect of your changes. Go back to step 1 if it doesn't look good.

3. When you're satisfied, manually copy the page to the Web content location. This step frequently involved FTP or a file system remote copy command. Recall that this step still required knowing the server's file system path to the live Web content, which is different from the HTTP path and different again from the file system path where the test pages are stored. Make sure that all the necessary files are copied, including images. Make sure that all the links still work, because the paths have just changed! Go back to step 1 if links are broken.

2.1.4 HTML Editing Tools

It wasn't very long before software developers released tools to make it easier to work with HTML. Some early tools were quite primitive essentially text editors decorated with extra buttons for functions such as Paragraph or Header 1. The extra buttons would insert HTML tags like <P> or <H1> at the cursor location. All this did to help the author was make it possible for him or her to edit HTML without memorizing the magic characters for each tag; the author still had to know what each tag did and how to make sure its syntax stayed correct through text changes. Some specialized HTML text editors allowed the author to preview the appearance of the page so that he or she didn't have to open a separate Web browser to view it. However, these tools were still fundamentally text editors because the author had to return to the plain-text display to make any edits.

The next step in Web authoring tools was WYSIWYG (What You See Is What You Get). WYSIWYG tools show the Web page exactly as it ought to appear to browsers and allow the author to edit and manipulate text within the WYSIWYG view. FrontPage, Word, and GoLive are examples of applications that author Web pages in WYSIWYG style now.

Many authoring tools did, and still do, treat Web pages as individual resources without taking into account the relationships between them. To add a link, the author might have been required to type in the entire link manually. This method is error-prone because it's too easy to mistype a file name or the name of an anchor (a location within a file that can be linked directly). If the target of the link was renamed, moved, or deleted, the link broke, and there was no way to discover broken links except through manual testing. Therefore, in addition to sophisticated Web page authoring tools, link and site management tools emerged. This kind of preliminary Web management eventually grew into another tool category, culminating in features such as the ability to view a map of the entire Web site.

By 1996, when preliminary work on the WebDAV protocol began, graphical Web authoring tools included SoftQuad HotMetal Pro 2.0, Quarterdeck WebAuthor 2.0, Adobe PageMill 1.0, and InContext Spider 1.1. These tools focused first on editing and only later on site management tasks such as link checking or automatic link fixup.