Brief Statement of the Problem ------------------------------ While there are currently over 200 Web browsers, many of these have an obfuscated internal structure. The main goal of this thesis is to create a Web browser with an elegant implementation that is easy to understand as well as extend. However, we must recognize that even novice users will want to create HTML documents. A browser that could also edit documents in WYSIWYG format would make generating new HTML documents much simpler. This additional feature could play a very large role in determining what internal structure is appropriate. Background ---------- In 1990, an idea was conceived to unify the access to various information sources at CERN by creating a system which would understand the myriad of protocols needed to gather information using the network and would display this information in a meaningful way. Not only would this obviate the need to explicitly employ multiple programs on different computers, it would simplify access by presenting a simple and consistent interface based on hypertext (text with navigable links to other pieces of text). One key part of this system is the Web browser, the program responsible for gathering and displaying hypertext on behalf of the user. Even from the begining, there was more than just a single browser. A line-mode browser demonstrated this technology on character-only display systems, and a browser running under NeXTStep showed what advantages could be gained by using a more powerful graphical display. As time passed, a few more browsers came into existence, such as Midas and Viola. In February of that year, NCSA's Mosaic (written by Marc Andreesen of Netscape fame) for X Windows was released as an alpha version. Later that year in September, NCSA Mosaic for X Windows, Microsoft Windows, and the Macintosh was released. Mosaic quickly became the reference by which other browsers would be evaluated against. Today, the dominate browsers of the more than 200 Web browsers in existence are Marc Andreessen's Netscape and the various incarnations of Mosaic. Other notable browsers are Lynx, the "best line-mode browser" and HotJava from Sun which incorporates the possibilty of including executable programs along with hypertext. However, most of the good browsers are now commercial, so their internal structures are not available to study and build upon. This is why this thesis is important. The availibilty of a non-commercial browser with a clear internal structure could be the basis for further research into the design of Web browsers. To create a browser with a clear internal structure, its necessary to understand the functions or processes that a Web browser should perform. First, before a Web page can be viewed, it must be fetched from memory, the network, a local disk or possibly by some means not yet devised. It is important to realize that this function can involve many policy decisions. For example, browsers will typically employ caches or local copies of pages to reduce the amount of network time needed. Since the network is often slow, this makes the browser much more responsive. Naturally, each of these policies should be broken into a seperate piece of code rather than mashed all together into one giant piece of code. This way, when someone wants to change one of these decisions, for example, to make a global cache shared by multiple users rather than having many seperate caches, it will not be hard to accomplish. Another policy that should have its own module is the naming mechanism since this is very likely to evolve over time. The next major function of a browser is to present the page to the user. Naturally, this task involves many steps and should be broken up into smaller pieces. One flexible design is to first tokenize the HTML document, then parse these tokens into a parse tree, and finally format the parse tree for display. Many browsers do not use this model and they will probably have problems being extended to handle style-sheets, a major improvement to HTML being explored for the next HTML standard. Some style-sheet mechanisms implicitly assume that a parse tree exists. The browsers which do not seperate the task of parsing from the task of formatting (HotJava is one such browser) will be at a disadvantage should such a style-sheet mechanism become popular. Another good reason to seperate parsing from formatting is that then it should be possible to format for different output devices. For example, a very simple formatter could be plugged in to create a line-mode browser while more sophisticated formatters could be used for a graphical display and for printing. Even with this clear structure, it can still be difficult to make simple changes to a browser since these pieces are still pretty complex. One complexity handling technique which I want to employ is the use of machine-generated modules. For example, a parser can be broken up into two pieces, a grammer or specification, and the engine which implements this grammer. If the engine is automatically generated from the grammer, someone wishing to change the grammer can do this easily without understanding how the engine actually operates. Of course, this abstraction barrier works the other way, so someone wishing to change the engine does not have to understand the exact grammer used for HTML documents. Another benefit of using a parser automatically generated from a grammer is that it is easy to check if the HTML has any errors in it and inform the user. Most browsers will happily display HTML documents with errors in them without ever telling the user (because they do no error checking). Most authors, are satisfied with thier documents as long as they look correct with their browser. Of course a document with errors in it could look terrible with a browser that uses a slightly different set of formatting decisions so it is actually very important to do error checking. While there are seperate tools that some HTML authors use to look for errors, building it into the parser makes it automatically available. The last major function of a Web browser is the user interface. Obviously user interfaces can range from very simple to very complex. Here again there are many policy decisions that determine the "look and feel" of the browser as well as its usability. Consider the common model of organizing visted Web pages in a stack (negotiated with the forward and backward buttons) used by virtually every Web browser. The problem with the stack model is that it sometimes "throws away" pages before this appropriate. When you traverse down through a series of pages, use the Backward button multiple times to return to the starting point, and then descend down a different pathway, all of the pages down the first path have been "lost." (Excepting of course, reloading the page by a history mechanism, hotlists, or by renaviagting down the path to the page again.) Some browsers actually handle Web pages differently making them more useful in my opinion. W3 never automatically throws away pages letting the user do this explictly. DeckScape solves this problem by allowing the user to create "decks" (sets) of pages. The deck offers an important organization component absent from most other browsers. Also, because decks are persistent across invocations of the browser and otherwise act as first-class entities, they permit the user a higher level of control. The point is that intertwining the user interface elements together, or worse, intertwining the user interface with the other aspects of the browser, makes it difficult to experiment with different user interfaces. Since it is hard to believe that a single user interface is right for all users, it would be a major step forward if a Web browser could employ different user interfaces. The Thesis ---------- Arena, the current reference browser maintained by the World Wide Web Consortium implements a basic web browser for "HTML 3.0", a proposed standard for the next version of HTML. It is written in C and works under the X Window system. It even includes one of the proposed style-sheet mechanisms. My thesis will be to rewrite Arena into Java, a new programming language from Sun designed for use with the internet, while improving the its implementation making it clearer and easier to modify for future Web browser research. Much of the improvement in implementation is expected to come from the superior data-abstraction mechanisms available to the Java programmer as well as the use of machine-generated code. Some important consequences result from the use of Java as the implementation language. First of all, the editor should run unmodified on any machine with an implementation of Java and its standard-runtime and graphics libraries. Second, the incorportation of Java applets should be simplified either as part of this thesis or as a seperate addition. Applets allow Web pages to "come alive" and are an area of very active interest. As a reference browser, it is important the this new version of Arena incorporate error reporting so that incorrect HTML can be detected and corrected. I would also like to incorporate the Deck feature from DeckScape, and other user interface elements from the current assortment of Web browsers such as a user configurable toolbar. Finally, I would like to add editing capabilities to this new Web browser. Hopefully, just as Mosaic spawned a number of new Web browsers, a free version of an HTML Editor would make editors much more common.