Extending HTML In A Principled Way With Displets

Fabio Vitali
Dept. of Computer Science
Università di Bologna
Mura Anteo Zamboni, 7
I-40127 Bologna

Chao-Min Chiu
Graduate School of Management
Rutgers University
University Heights
Newark NJ 07102, USA

Michael Bieber
Institute for Integrated Systems Research
New Jersey Institute of Technology
University Heights
Newark NJ 07102, USA


Displets provide authors and programmers with a way to freely extend the HTML language on a per document basis in a principled manner. Currently, in order to be accepted, HTML elements must be approved by the official HTML review board. Non standard extensions have appeared, and have relied on the commercial power of the proponents for acceptance.

Two major forces are driving the extension process of the HTML language: those who favor a better description of document elements, as with SGML and those who would like better control over the final appearance of documents, as with Postscript and other display-oriented languages. Special notations (such as mathematics, music, etc.), are hardly considered - if at all - in defining the HTML standard. We designed displets to fill this frustrating gap.

Displets are Java classes that are activated while rendering an HTML document. Displets provide graphic artists better control over the final appearance of HTML documents, librarians and indexers a better description of their content, and those in need of new notations a way to describe and use graphical objects in a manner compatible with the graphical and structural habits of the HTML community.

1. Introduction

The current debate on HTML sees two opposing positions as preeminent. One wants better control over the final appearance (the rendering) of a document. The other advocates better control over the description of the structure and role of the parts of the document.

The first group, led by graphic designers, would like the standardization efforts on HTML to cease and would allow plentiful ad hoc extensions to the language to cover all visualization needs. The second group, the SGML community, would prefer HTML to abstract from the description of the document's physical appearance, and let style sheets guide the final mapping of structural elements to their visual representations.

Furthermore, commercial software developers often find it irresistible to improve upon and detour from the published standard and seek a commercial advantage by extending HTML with new, proprietary tags ([16], [17], [18]). They hope, of course, for users to switch to their browsers to be able to read and fully appreciate Web pages using those new tags.

Yet, it is our impression that all these approaches miss a critical need of authors of distributed documents - support for special notations. Such notations include (and are not limited to) specialized graphical objects (object-oriented graphics, graphs, charts, etc.), specialized notation for specific fields (chemistry, electrical and electronic engineering, music, mathematics, software engineering, chess, etc.), specialized alphabets (hieroglyphics, cuneiform, etc.), special symbols (philosophical, religious, astrological, alchemical signs, etc.)

Generally there is one basic way to include these types of notation in an HTML document - by providing an image of the symbol's graphic depiction. For particularly complex or dynamic objects, it is now possible to write Java applets that display the object as their sole effect. Applets may include specifications of the object details inside their code, making it therefore completely hidden. Alternatively Applets may receive these specifications as parameters put in the HTML code, but without a required syntax or style, possibly resulting in an arcane and opaque syntax.

We propose a cleaner approach to extensions to the HTML language: displets. Displets are small Java modules similar to Applets. A properly extended browser would activate them while parsing an HTML document, every time it encounters predeclared new tags and would let them handle the display operation for the relevant objects. Declaring both the extensions that will be used in the document and the displet class needed for their display at the beginning of the document enables any kind of customized extension to the HTML language without loss of generality, while maintaining widespread compatibility and stylistic elegance.

We have developed a proof-of-concept implementation of displets by modifying the 1.0 alpha3 release of the HotJava browser. A few extensions have been designed and implemented on that architecture.

The paper is structured as follows: Section 2 summarizes the current state of the HTML language. In Section 3, we discuss the need for HTML to support new notations. Section 4 introduces and describes displets. Section 5 covers some implementation details. Section 6 presents several extensions to HTML that we have developed using displets, and describes others that we would like to create. Section 7 describes a series of suggestions on how to implement displets within existing and future standards.

2. The HTML language

The HTML language was designed as part of the World Wide Web effort at CERN at the beginning of the nineties. Its goal [1] was to provide an easy page description language suitable for:

HTML was designed to be an application of the Standard Generalized Markup Language (SGML, [14]), that is, a class of documents conforming to an SGML Document Type Definition (DTD) defining "HTML documents." SGML is an international standard for describing marked-up text in an electronic format. Its wide acceptance and influence are owed to several characteristics, among which we would like to highlight the following ([23], [10]):

Descriptive markup

An SGML document has its content enriched by embedded tags that describe its parts in terms of their role and meaning, rather than the kind of processing necessary to display them. This allows one to define a generic markup that can be used for any purpose: from display on a wide range of devices (from dumb terminals to highly graphical workstations; from simple line printers to sophisticated typographical systems) to content-based analysis and categorization (useful for large document systems, indexers, search engines, etc.), to processing for information extraction, restructuring, and update. SGML is only interested in the meaningful structuring of the documents, and leaves the task of assigning graphical attributes to document elements of rendering software.

Open set of document types

SGML documents may respect constraints defined by their type (as prescribed in their Document Type Definition, or DTD). This means that only some elements may appear in a SGML document, and that some elements may have constraints as to where and how to appear.

Human-readable representation

SGML markup appears as text tags surrounding the described elements. Both the character set used and suggested practice emphasize readability in the markup, since no special software may be available for marking the text, and using meaningful words as tag names improves understandability of the text in all situations.

HTML is a specific document type described by using an SGML DTD. As such, it inherits some of SGML's qualities: it shows embedded markup with meaningful names, some constraints in the nesting of elements, and some structuring support (the header tags). On the other hand, being a single DTD, HTML has the drawbacks of being a closed document type: only the existing elements can be used and no extension can be created unless approved by the appropriate committee.

This fact has caused several problems in the development of the language itself. Since HTML+ [20], on through HTML 2.0 [2] to HTML 3.2 [21], every proposed enhancement to the language has had to deal with an approval process, with the attacks of competing proposals, and with the need to keep the additional features simple, usable and orthogonal to each other. Several extensions were first implemented in commercial software and then proposed to the language committee with the force of an already widespread usage.

Further needs could have been met with further language extensions (e.g., math markup [8]), but had little support from influential user bases or commercial software, because they were deemed too complex for fast implementation or no consensus was reached among the competing proposals. The needs remain, and are met in the meantime with different, more complex and less elegant solutions. On-line images have long been the standard way to include content elements the graphical depiction of which was outside HTML capabilities, but this usage stresses rendering, not content. Server-side extensions (e.g., [12]) make it possible to specify new tags that are automatically substituted with appropriate content before being delivered to the browser. They rely on the fact that even though a document needs to be shown on several types of browsers, it still resides on only one server, so that it is safe to include new tags of which that server is aware.

In the current discussion, graphic designers compete with SGML enthusiasts to provide new extensions. Extremists appear on both sides. David Siegel [22], for instance, proposes that all standardization in the HTML language be stopped at the current state and that the market decide successful extensions via natural selection of the fittest. C. M. Sperberg-McQueen and R. F. Goldstein [24] suggest using pure SGML documents and activating SGML viewers as plug-ins or external viewers.

Others have more moderate views. The April 1996 W3C Workshop on High Quality Printing from the Web had several proposals for consistent font rendering over the Web ([25], [27]) and new markup elements for managing the display [7]. At the November 1994 First International Workshop on WWW Design Issues, some researchers discussed ways to include SGML features in the Web by improving the structure control ([19], [26]) or by developing simplified SGML-like dialects to replace HTML ([11]).

Important proposals are those receiving support from the W3C in one form or another. Style sheets [5] are a way to attach rendering and formatting instructions to HTML tags. They allow authors to specify the presentation in a precise way without cluttering the content of documents. Style rules can be connected to HTML elements through implicit association, specification of linked style sheet documents (with the LINK element), or the use of a new proposed header tag called STYLE, in which formatting instructions can be specified according to one of several style sheet specification languages ([13], [15]).

The Extensible Markup Language (XML, [6]) is an important proposal by the W3C Working Group on SGML. XML is a simplified SGML with many of the arcane features removed in order to produce a more usable and understandable language. XML documents thus are still valid SGML documents, which leverages existing software.

3. The need for HTML extensions

The previous discussion shows that any proposed new extension is bound to annoy or be ignored by an important authoring community. If the extension is related to rendering, many in the SGML community will criticize it. If related to content or structure, many graphic designers will ignore it, continuing to do HTML hacks or creating images until they obtain the desired specific effect for some specific (high-end) browser, with disregard for compatibility and content analysis. The need for an approval process by the HTML editorial review board and an implementation of commercial applications contributes to the shared discomfort.

Suppose an author needs to display a chart such as figure 1 in a Web browser:

Figure 1: A simple chart in an HTML page

Currently a few solutions are possible:

In the first case, the chart is static and fixed; when changing the data, the author would have to redraw the picture using whichever application he or she used the first time. In the second case, the author would have to mess with CGI scripting and with the dynamic generation of graphic data. In the third case, the author would have to write his or her own Java Applet or use an existing one and learn how to pass the parameters to it.

Obviously, the third solution is probably the most elegant and common one given the current availability of tools. Unfortunately, this solution shares a big drawback with the other ones: the data that form charts are not in an easily understandable or reusable format, as is dictated by the syntax of the Applet parameters. In short, the Applet programmer decides how the chart data should be specified, without any necessary regard for matching the markup of the rest of the page, and with several restrictions on the available character set (we cannot, for instance, use angle brackets or double quotes in the text to be drawn).

Furthermore, the Applet content is completely separated from the content of the page. This leads to a dangerous loss of hypertext in Web documents [3]. Applet authors cannot use hypertext features (such as links on the objects); display HTML text in the chart labels; enable human readers to understand the chart data by reading the HTML source code; or enable bots, indexers and research engines to understand its content - unless the Applet programmer has gone far out of his or her way to duplicate these characteristics from the browser in the code of the Applet itself.

Therefore, while Applets have the procedural power to support all needed notations, they strongly discourage content markup, both in syntax and in structure, and are not an elegant choice for new data objects.

The ideal solution would be to specify the chart data as markup included in the HTML source code, instead of as parameters of the Applet. Unfortunately this is currently not possible. Yet the whole point of structured markup à la SGML is to be able to name and describe all the parts of a document in a significant manner. The whole point of typographic languages à la Post Script is to be able to specify exactly how and where to display all the parts of a document. HTML forces authors instead to fit all the parts of a document into a limited set of available markup tags, and removes most rendering control from the authors.

4. Displets

Displets are our proposal for creating HTML extensions in a principled, general way that will satisfy everyday HTML authors, as well as both disputing communities.

Displets are Java modules that are automatically activated whenever some pre declared tags are parsed by the HTML parser during the display of the HTML document. The author will be able to include any kind of tag, provided some displet exists to handle the data thus specified.

4.1 Displets within HTML documents

Displets are specified within HTML documents as new markup tags. They are preceded by their declaration, and then used within the document as if they were legal HTML markup.

An example of an HTML document enhanced with displets may help one to understand their use:

Table 1. An HTML document defining and using a chart displet

<TITLE>Test for chart</TITLE>
<TAG NAME="CHART" HasEndTag NonNesting SRC="http://hertz.njit.edu/chart/chart.class">
        <ATTR NAME="width" VALUE=number>
        <ATTR NAME="height" VALUE=number>
<TAG NAME="TABLE" HasEndTag IN="Chart"SRC="http://hertz.njit.edu/chart/table.class">
        <ATTR NAME="HasLegend" VALUE=boolean>
<TAG NAME="TR" HasEndTag IN="Chart"SRC="http://hertz.njit.edu/chart/tr.class">
        <ATTR NAME="Color" VALUE=RGB>
<TAG NAME="TH" IN="Chart"SRC="http://hertz.njit.edu/chart/th.class"></TAG>
<TAG NAME="TD" IN="Chart"SRC="http://hertz.njit.edu/chart/td.class"></TAG>

<P>Some normal HTML text followed by the chart:</P>
        <TH> <TH><EM>Jan/Mar</EM> <TH>Apr/Jun <TH>Jul/Sep <TH>Oct/Dec 
        <TH>Smith <TD>125 <TD>257 <TD>327 <TD>250 
        <TH>Green <TD>137 <TD>140 <TD>110 <TD>160
        <TH>Brown <TD>421 <TD>380 <TD>250 <TD>150

A displet-enhanced HTML document has two characteristics: new tags are introduced (with a simple syntax) at the beginning of the document, and, in the body, the newly defined tags are mixed with standard HTML ones to create the needed document.

According to this syntax (others can be defined; a discussion can be found in Section 7), for each tag the main characteristics are described in a simplified syntax that closely resembles SGML DTDs: the name of the tag, the syntax constraints, and the available attributes. There are two major difference from DTDs:

As the example shows, some tags have not been defined from scratch, but are a customization of existing ones. This still allows non-compliant browsers to make use of and display the document content as well as they can.

For instance, leveraging the fact that unknown tags and attributes are usually ignored by browsers, we are re-using TABLE, TR, TH and TD tags for specifying the charting data. Therefore an unaware browser would display the previous document as containing an appropriately formatted table:

Table 2. The same chart displayed by an unaware browser

Jan/Mar Apr/Jun Jul/Sep Oct/Dec
Smith 125 257 327 250
Green 137 140 110 160
Brown 421 380 250 150

By specifying the IN="Chart" attribute within the table-related tags, we signal that the code of the displets should be called only when these tags are found within a CHART tag, so that tables described outside of charts are still handled normally - as tables.

This solution should appeal to SGML enthusiasts because the HTML language can be extended with new tags. Structuring the documents is more flexible and complete, the new tags are explicitly defined, and some syntactical prescriptions (albeit simpler than in SGML) are reinforced.

It also should appeal to graphic designers. Page designers are not constrained to forcing their graphical ideas into existing tags. Also, the final rendering of the elements can be finely controlled by the displet code.

Furthermore, it should appeal to those with special notation needs. Whole new notations can be defined (mathematics, music, etc.), as well as simple elements (special characters, dingbats, etc.), or complex structured data formats (object-oriented graphics, charts, etc.). Authors can easily include everything in HTML documents, with the same ease of use and comprehension as with the other HTML tags.

Also, it may appeal to the HTML review board, because it is the only method so far to extend HTML without deferring to endless committee discussions or to the market force of commercial software, or employing complex specification mechanisms such as SGML and XML.

Finally, it may appeal to Web authors, who will be able to mix and match predefined displets creating sophisticated complex materials without resorting to programming.

4.2 Displets as Java modules

A displet is a Java class whose methods are called during the parse of an HTML document. Displets have control over the display of themselves and their immediate surroundings, such as the HTML code contained between their start and end tag, or immediately following the end tag. They are not usually called while the document is on screen, unless the displet explicitly requests this service.

The Java code for a very simple displet looks like Table 3.

Table 3. The "Hello world" displet

import awt.Graphics;

class HelloWorldDisplet extends browser.Displet {

    public void startElement() {
        graphic.drawString("Hello world!", 10, 25);

Displets require a modified HTML parser that allows external classes to be declared and invoked, and that allows external classes to modify the rendering parameters (such as text font, size or style, margins, etc.)

The modified HTML parser must accept the definition of the new tags upon encountering the TAG element, and invoke the appropriate methods when encountering the start and end tags of the newly defined element.

Whenever encountering an unknown tag, the HTML parser should verify whether a TAG tag with that name has been defined and is permitted to occur in the current context (for instance, if it follows the specifications of the IN and NonNested attributes). If so, the parser will create a new instance of the displet with an array of the valid attributes (as specified by the ATTR elements contained in the TAG element). The parser also verifies and performs appropriate housekeeping tasks when encountering the end tag of the newly defined element.

Upon displaying the page, the startElement() method of the displet should be called when encountering the start tag of the new object. With this method it is possible to create graphical objects and to change the settings of the current rendering (font, margins, etc.). The endElement() method is called in conjunction with the new element's end tag. This method usually should be used to restore the original settings that were modified in the startElement() method.

Furthermore, the browser should be capable of calling the appropriate methods whenever a user event happens within the boundaries of the displayed object. This need is clearly shown for the A tags, where the browser must react when the user clicks on or moves the mouse over the displayed object.

5. Implementation

We have created a proof-of-concept implementation of displets using Java 1.0 alpha3 and the 1.0 alpha3 release of the HotJava browser. Although this forced us to use a nonstandard and outdated version of the language, and a limited set of HTML options to start off with, it allowed us to use the source code of an existing HTML parser and browser that we could modify and extend.

HotJava 1.0 alpha3 parses and displays HTML documents through the interaction of the appropriate subclasses of three different classes: Tag, TagRef and DisplayItem. Tag instances (one for each tag type) are passive objects that simply notify the HTML parser of their existence. TagRef instances are created by the HTML parser every time it encounters the proper tag, and are used as an internal representation of the HTML document. When displaying the document, each TagRef is associated with a relevant DisplayItem, which decides how to display itself.

The current implementation defines two new tags as shown in Table 4.

Table 4. The definition of the TAG and ATTR elements

<!ELEMENT tag - o attr*>
          name        CDATA                          #REQUIRED
          hasEndTag   (hasEndTag)                    #IMPLIED 
          nesting     (nesting)                      #IMPLIED
          interactive (interactive)                  #IMPLIED
          in          CDATA                          #IMPLIED 
          src         CDATA                          #REQUIRED> 

<!ELEMENT attr - o (#PCDATA)?>
<!ATTLIST attr
          name        CDATA                          #REQUIRED
          value       CDATA                          #REQUIRED
          required    (required)                     #IMPLIED>

Three classes are defined, namely the DispletTagRef, DispletDisplayItem and Displet. A DispletTagRef is created whenever a declared new tag is encountered during the parse of the document. The DispletDisplayItem is then activated by the browser during the layout of the document page. This class creates an instance of the appropriate Displet class (the only class supplied by the user), which can create a graphic object or modify the layout settings as needed.

If the INTERACTIVE attribute is specified, the Displet class will also receive all the users' events in the area; in this case the appropriate methods (mouseDown(), mouseUp(), etc.) will be called. An interactive displet can do exactly the same things as an Applet, although the calling method is different (displets should prepare and paint themselves in the startElement() method).

This structure is parallel to and similar to the one used for managing applets.

Figure 2. The analogy between Applets and displets.

The user implementing a new displet simply has to subclass Displet. Displets are built around two basic methods: startElement() and endElement(). In the first, a displet should prepare and draw its graphical representation and/or modify the current setting for the next elements. In the second, a displet should restore the original settings. Two objects are available to all methods in a displet class: the graphic object, providing the context for the drawing routines, and the document object, providing the current values for variables such as the current margins, the current font, etc.

6. Displet examples

In our proof-of-concept implementation, we have created a small set of working extensions to HTML. A few more are in the works, and should be ready at about the conference time.

6.1 Charts

A chart is a graphical depiction of a table of numerical values. In accordance with this definition, and in order to maintain compatibility with other browsers, charts use table tags to define the data they need to show. A complete example of the grammar and use of charts is given in Sections 3 and 4.

6.2 Graphs

A graph is a set of circular and rectangular shapes called nodes connected by arrowed lines called arcs. Table 5 is the declaration of such a displet in the HTML document:

Table 5. Defining and using a graph

<tag name="GRAPH" hasEndTag nonNesting src="http://hertz.njit.edu/displets/graph/GRAPH.class">
    <attr name="width" value=number>
    <attr name="height" value=number>

<tag name="NODE" hasEndTag nonNesting in="GRAPH"
    <attr name="name" value=string required>
    <attr name="pos" value=integerPair>
    <attr name="size" value=integer>
    <attr name="shape" value="rect , circle">rect</attr>

<tag name="ARC" hasEndTag nonNesting in="GRAPH"
    <attr name="name" value=string>
    <attr name="from" value=string required>
    <attr name="to" value=string required>
    <attr name="arrow" value="to, from">
    <attr name="thickness" value=integer>
<graph width=400 height=300>
    <node name="first" pos=290,120 size=160,40 shape=rect>
        <A HREF="http://hertz.njit.edu/first.html">This is the first label</A>
    <node name="second" pos=100,20 size=160,40 shape=rect>
        <B>This is the second label</B>
    <node name="third" pos=100,120 size=120,50 shape=rect>

    <arc from="first" to="second" arrow=from>This has a label, too</arc>
    <arc from="first" to="third" arrow=from>

Figure 3 shows how the graph looks on the screen.

Figure 3. A graph element in an HTML page.

6.3 Anchor groups

Anchor groups are a way to implement multi-endpoint links [4]. The user finds a clickable area that, instead of leading to a single destination, pops up a list of choices each leading to a different destination. As a displet, this corresponds as an anchorGroup tag surrounding a set of plain HTML A anchors.

Table 6 is a declaration for AnchorGroup:

Table 6. Defining and using an anchor group

<tag name="agroup" hasEndTag interactive src="http://hertz.njit.edu/displets/agroup/agroup.class">
    <attr name="name" value=string>
    <attr name="align" value="top, middle, bottom">

<tag name="a" hasEndTag src="http://hertz.njit.edu/displets/agroup/a.class">
    <attr name="HREF" value=URL required>
    <attr name="ALT" value=string>
    <attr name="selected" value=boolean>
<agroup name="agroup1" align="top">
    This is an example of multi-endpoint link:
    <a href="http://www.njit.edu" selected>Go to NJIT</a>,
    <a href="http://info.rutgers.edu">Go to Rutgers</a>

By defining anchor groups as collections of anchors, we can guarantee some compatibility with existing browsers, since the links, rather than being grouped in a single pop-up menu, will be displayed side by side without problems.

Figure 4. An anchor group in an HTML document.

6.4 Anchor labels

Anchor labels are small pop-up windows that appear near an anchor when the user moves the mouse near it. It may contain a small sentence explaining the purpose and the destination of the link. Anchor labels are implemented by extending the definition of anchors, i.e, by adding a new attribute to the A tag.

Table 7. Defining and using an anchor label

<tag name="a" hasEndTag nonNesting interactive src="http://hertz.njit.edu/displets/label/a.class">
    <attr name="HREF" value=URL required>
    <attr name="ALT" value=string>
    <attr name="LABEL" value=string>
<P>Please check <a href="http://www.njit.edu" label="This
link will lead to the NJIT website">here</a> for a description
of NJIT.</P>

Figure 5. An anchor label in an HTML document.

7. A proposal for displets

It is important to distinguish the idea of displets from the details of the proof-of-concept architecture that we have implemented. Some of our design decisions were driven by the availability of a specific, extensible browser and should be modified in future implementations for different software. Others were choices among equivalent candidates, and can be changed in future implementations.

For example, the Displet, DispletTagRef and DispletDisplayItem classes arise from using the HotJava alpha browser, which uses similar classes for its functions. An implementation using more recent software will require rethinking the set of classes to be used. On the other hand, our choice to create Java modules, rather than, for instance, ActiveX objects or Python scripts, is probably still sound, but open to change in different implementations.

In any case, our real contribution is the concept of displets. We summarize the core aspects of displets as follows:

One choice is particularly open to debate: how should new elements be specified? Our choice has been to create two new tags, TAG and ATTR, to be used in the HEAD part of an HTML document, where the new elements can be defined and the rendering code (the displet) is specified. Another choice would be to extend style sheet standards so as to allow the specification of the URL of the displet as a style parameter. An example is shown in Table 8:

Table 8. An alternative way to define displets

    <ATTR NAME="first" VALUE=string>
<STYLE TYPE="text/css">
	H1 { color: red }
	MYTAG { src: "http://hertz.njit.edu/displets/label/a.class" }

We believe that our choice is the easiest to implement and to understand, but it has two drawbacks:

We should note that any extension syntax defined on a per document basis will face the same problems. One solution would use a specific DTD for the new elements and rely on the proposal for specifying HTML Dialects [9]. Another would substantially rework the current HTML DTD to allow specifications of new elements and substitution of the standard DTD invocation


with a new syntax that allow the DTD to be extended on the fly. A possible syntax is shown in Table 9.

Table 9. Extending the HTML DTD to support displets

<!element mytag - - (#PCDATA)>
	... etc ...

It is our opinion, though, that this kind of syntax would be much more obscure to the casual author. It would be better to obtain SGML compliance only when needed by applying a simple pre-parser to the extended documents. Similar considerations can result in XML compliance.

8. Conclusions

Given the current success of the Web, more and more people will need to make nontextual content available to a large number of users. HTML is a compromise between the need to render content in an interesting way and the need to maintain easy analysis and computability of the content itself.

Unfortunately, with HTML being a closed language, tricks and hacks have become commonplace whenever a graphical effect or some structuring that goes beyond the expressive power of the language itself is needed.

Displets are a proposal to allow arbitrary extensions to be defined within HTML documents without reverting to the complexity of SGML or XML and without losing the control on structure that page-description languages may impose.

The current implementation, while only a proof-of-concept, clearly demonstrates the strong potential of allowing the definition of new elements, as well as the specification of the code for their correct rendering.

Without giving up the simplicity in design and use of HTML, displets allow sophisticated graphical effects, better definition of structural elements, and the ability to specify new, arbitrarily complex notations that are not currently supported by any browser except through online images. Implementing these ideas on a large scale should greatly increase the accessibility of the Web to everyday authors.


We would like to thank David Durand of Boston University for his deep and insightful comments on XML and SGML syntax, and New Jersey Institute of Technology masters students Gideon Tam, Guang-Wu Chen, Hsueh-Ching Yen, and Zhengxiang Pan for their help in implementing earlier prototypes of the HTML extensions. This research has been funded generously by the New Jersey Center for Multimedia Research, the New Jersey Commission of Science and Technology, the NASA JOVE faculty fellowship program, the AT&T Foundation, and the New Jersey Institute of Technology under Grant 991967.


[1] T. Berners-Lee, D. Connolly, Hypertext Markup Language 1.0, http://ecco.bsee.swin.edu.au/text/html-spec/HTML.html
[2] T. Berners-Lee, D. Connolly, Hypertext Markup Language - 2.0, http://www.w3.org/pub/WWW/MarkUp/html-spec/html-spec_toc.html
[3] M. Bieber, F. Vitali, "Toward Support for Hypermedia on the World Wide Web," IEEE Computer, 30(1), 1997, 62-70.
[4] M. Bieber, F. Vitali, H. Ashman, V. Balasubramanian, H. Oinas-Kukkonen, "Fourth Generation Hypermedia: Some Missing Links for the World Wide Web," forthcoming in International Journal on Human-Computer Systems, 1997.
[5] B. Bos, D. Raggett, H. Lie, "HTML3 and Style Sheets," W3C Working Draft, http://www.w3.org/pub/WWW/TR/WD-style
[6] T. Bray, C. M. Sperberg-McQueen (eds.), "Extensible Markup Language (XML)," W3C Working Draft, http://www.textuality.com/sgml-erb/WD-xml.html
[7] S. Butler, R. MacMillan, S. Waters, "HTML Extensions To Improve Layout Control for Viewing and Printing Documents," W3C Workshop on High Quality Printing from the Web, http://www.w3.org/pub/WWW/Printing/fmtext.html
[7] D. W. Connolly, Math Markup, W3C page, http://www.w3.org/pub/WWW/MarkUp/Math/
[9] D. W. Connolly, "HTML Dialects: Internet Media and SGML Document Types," W3C Working Draft, http://www.w3.org/pub/WWW/TR/WD-doctypes
[10] Steve De Rose, David Durand, "HyTime," Kluwer, 1994.
[11] P. Duval, "SGML-based dialects for WEB applications based upon content-understanding," International Workshop on WWW Design Issues '94, http://www.cwi.nl/ERCIM/W4G/WS94/papers/Patrick.html
[12] HTMLscript, HTMLscript
[13] ISO-IEC, "Information technology --- Processing languages --- Document Style Semantics and Specification Language (DSSSL)," http://occam.sjf.novell.com:8080/dsssl/dsssl96
[14] International Standards Organisation, ISO 8879, Information Processing - Text and Office Systems - Standard Generalized Markup Language (SGML).
[15] H. Lie, B. Bos, "Cascading Style Sheets, level 1," W3C Proposed Recommendation, http://www.w3.org/pub/WWW/TR/PR-CSS1
[16] Microsoft, HTML Authoring Features for Internet Explorer 3.0, http://www.microsoft.com/workshop/author/newfeat/ie30html-f.htm
[17] Netscape, "Extensions to HTML 2.0," http://home.netscape.com/assist/net_sites/html_extensions.html
[18] Netscape, "Extensions to HTML 3.0," http://home.netscape.com/assist/net_sites/html_extensions_3.html
[19] V. Quint, "Should WWW documents be structured?," International Workshop on WWW Design Issues '94, http://www.cwi.nl/ERCIM/W4G/WS94/papers/Quint.html
[20] D. Raggett, "A Review of the HTML+ Document Format," Proceedings of the First WWW Conference, Geneva (CH) 1994, http://www1.cern.ch/PapersWWW94/dsr.ps
[21] D. Raggett, HTML 3.2 Reference Specification, http://www.w3.org/pub/WWW/TR/PR-html32-961105
[22] D. Siegel, The balkanization of the Web, http://www.dsiegel.com/balkanization/
[23] C.M. Sperberg-McQueen and Lou Burnard (eds.), Guidelines for Electronic Text Encoding and Interchange, chapter 2, "A Gentle Introduction to SGML," ftp://www.ucc.ie/pub/sgml/p2sg.ps
[24] C. M. Sperberg-McQueen and R. F. Goldstein, "HTML to the Max: A Manifesto for Adding SGML Intelligence to the World-Wide Web," Electronic Proceedings of the Second World Wide Web Conference '94: Mosaic and the Web, http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/Autools/sperberg-mcqueen/sperberg.html
[25] R. Stevahn, "PANOSE: An Ideal Typeface Matching System for the Web," W3C Workshop on High Quality Printing from the Web, http://www.w3.org/pub/WWW/Printing/stevahn.html
[26] A-M Vercoustre, "Adding SGML to WWW," International Workshop on WWW Design Issues '94, http://pauillac.inria.fr/~vercous/WWW.html
[27] S. Zilles, "Quality Printing on the Web," W3C Workshop on High Quality Printing from the Web, http://www.w3.org/pub/WWW/Printing/zilles.html

Return to
Top of Page
Return to Technical Papers Index