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.
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.
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]):
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.
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.
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.
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
<HTML><HEAD>
<TITLE>Test for chart</TITLE>
<TAG NAME="CHART" HasEndTag NonNesting SRC="http://hertz.njit.edu/chart/chart.class">
<ATTR NAME="type" VALUE="BAR, PIE, LINE" REQUIRED>
<ATTR NAME="width" VALUE=number>
<ATTR NAME="height" VALUE=number>
</TAG>
<TAG NAME="TABLE" HasEndTag IN="Chart"SRC="http://hertz.njit.edu/chart/table.class">
<ATTR NAME="HasLegend" VALUE=boolean>
</TAG>
<TAG NAME="TR" HasEndTag IN="Chart"SRC="http://hertz.njit.edu/chart/tr.class">
<ATTR NAME="Type" VALUE="LABEL, DATA" REQUIRED>
<ATTR NAME="Color" VALUE=RGB>
</TAG>
<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>
</HEAD><BODY>
<P>Some normal HTML text followed by the chart:</P>
<CHART TYPE=BAR> <TABLE HasLegend>
<TR TYPE=LABEL>
<TH> <TH><EM>Jan/Mar</EM> <TH>Apr/Jun <TH>Jul/Sep <TH>Oct/Dec
</TR>
<TR TYPE=DATA COLOR=RED>
<TH>Smith <TD>125 <TD>257 <TD>327 <TD>250
</TR>
<TR TYPE=DATA COLOR=GREEN>
<TH>Green <TD>137 <TD>140 <TD>110 <TD>160
</TR>
<TR TYPE=DATA COLOR=BLUE>
<TH>Brown <TD>421 <TD>380 <TD>250 <TD>150
</TR>
</TABLE> </CHART>
</BODY></HTML> |
import awt.Graphics;
class HelloWorldDisplet extends browser.Displet {
public void startElement() {
graphic.drawString("Hello world!", 10, 25);
}
} |
<!ELEMENT tag - o attr*>
<!ATTLIST tag
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>
|
<HTML><HEAD>
<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>
<tag name="NODE" hasEndTag nonNesting in="GRAPH"
src="http://hertz.njit.edu/displets/graph/node.class">
<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>
<tag name="ARC" hasEndTag nonNesting in="GRAPH"
src="http://hertz.njit.edu/displets/graph/arc.class">
<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>
</tag>
</HEAD><BODY>
<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>
<node name="second" pos=100,20 size=160,40 shape=rect>
<B>This is the second label</B>
</node>
<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>
</graph>
</BODY></HTML>
|
Figure 3 shows how the graph looks on the screen.
Figure 3. A graph element in an HTML page.
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
<HTML><HEAD>
<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>
<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>
</tag>
</HEAD><BODY>
<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>
</agroup>
</BODY></HTML>
|
<HTML><HEAD>
<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>
</tag>
</HEAD><BODY>
<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>
</BODY></HTML>
|
<TAG NAME="MYTAG">
<ATTR NAME="first" VALUE=string>
</TAG>
<STYLE TYPE="text/css">
H1 { color: red }
MYTAG { src: "http://hertz.njit.edu/displets/label/a.class" }
</STYLE>
|
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
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> |
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
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN" [ <!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.
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.
| [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 |
