Status of this memo
This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a "working draft" or "work in progress".
To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow directories on ds.internic.txt, nic.nordu.net, ftp.nisc.sri.com or munnari.oz.au.
Distribution of this document is unlimited. Please mail comments to the author at dsr@hplb.hpl.hp.com or to the discussion list: www-talk@nxoc01.cern.ch
This draft is valid until May 1st, 1994. It is available in the file draft-raggett-www-html-00.ps and draft-raggett-www-html-00.txt in the internet-drafts directories on the hosts mentioned above. Readers are recommended to try and obtain the Postscript version, which contains figures and formattting examples which are missing from the plain text version.
This draft presents a proposal for a light weight delivery format for browsing and querying information in a web of globally distributed hypertext, accessible over the Internet. HTML+ embodies a pageless model making it suitable for efficient rendering on a wide range of display types, for example, VT100 terminals, X11 Workstations, Windows 3.x and the Macintosh. HTML+ is based upon SGML, and represents document elements at a logical level, e.g. headers, paragraphs, lists, tables, and figures. Authors can choose to create HTML+ documents directly, or to use filters to convert from other formats such as LaTeX, Framemaker, and Word for Windows.
HTML+ has grown out of several years experience with the HTML document format in the World Wide Web community. Browser writers are experimenting with extensions to HTML and it is now appropriate to draw these ideas together into a revised document format.. The new format is designed to allow a gradual roll over from HTML, adding features like tables, captioned figures and fill-out forms for querying remote databases or mailing questionnaires. Large documents can be split into a number of smaller nodes for reduced latency, with explicit or implicit navigation links. This draft also includes a proposal to add direct support for mathematical formulae. Authors can include limited presentation hints, and further control may eventually be possible via associated style sheets.
Following the WWW workshop in July 1993 and subsequent discussions on www-talk, it seems an opportune moment to try and reach a consensus before writing a more formal draft as an informational RFC.
The World Wide Web is a wide-area client-server architecture for retrieving hypermedia documents over the Internet. It also supports a means of searching remote information sources, for example bibliographies, phone directories and instruction manuals. There are three main ingredients: naming schemes for retrievable objects, protocols and interchange formats.
HTML+ documents offer a means for providing hypertext links to a variety of media including images, sound sequences, MPEG movies, Postscript files and other formats. These links allow a global web of information sources to be established as new servers and document names are announced. Registers of information sources can also be made available via the web, using its ability to let users search for information via keywords. It is hoped that HTML+ will be useful for information exchange via email and network news as well as HTTP.
HTML+ is designed for use in the World Wide Web as a non-proprietary delivery format for wide-area hypertext. It embodies a pageless model making it suitable for efficient rendering on a wide range of display types including VT100 terminals, X11, Windows 3.1 and the Macintosh. HTML+ is based upon SGML and represents document elements at a logical level. Authors may choose to create HTML+ documents directly or to use filters to convert from other formats such as LaTeX, Framemaker, and Word for Windows.
HTML+ is a superset of HTML and designed to allow a gradual roll over from the earlier format, with features like tables, captioned figures and fill-out forms for querying remote databases or mailing questionnaires. Large documents can be split into a number of smaller nodes for reduced latency, with explicit or implicit navigation links. This draft also includes a proposal to add support for mathematical formulae. Authors can include limited presentation hints, and further control may eventually be possible via associated style sheets.
HTML+ is based on the Standard Generalized Markup Language which is an international standard for document markup that is becoming increasingly important. The term markup derives from the way proof-readers have traditionally pencilled in marks that indicate how a document is to be revised.
SGML grew out of a decade of work addressing the need for capturing the logical elements of documents as opposed to the processing functions to be performed on those elements. SGML is essentially an extensible document description language, based on a notation for embedding tags into the body of a document' s text. It is defined by the international standard ISO 8879. The markup structure permitted for each class of documents is defined by an SGML Document Type Definition, usually abbreviated to DTD.
A lot of work is underway to produce DTDs for a range of purposes. These include ISO 12083 for books and ISO 10744 which defines the HyTime architectural forms for hypermedia/timebased documents. The Text Encoding Initiative (TEI) is an international research project for SGML-based document exchange in the humanities. Publishers are cooperating to produce common DTDs for computer manuals, e.g. the DocBook DTD. The CALS programme of the US Department of Defence defines SGML DTDs for documentation for defence procurement contracts.
So what sets HTML+ apart from these efforts? It is impractical to design a DTD to meet the needs of all possible users. Instead, the markup has to be tailored to the needs of a specific community. HTML+ is aimed at fulfilling the dream of a web of information freely accessible over the Internet with links between documents spanning continents. The need to support a very wide range of display types and to keep browser software as simple as possible limits the complexity that can be handled. Similarly the disparate needs of authors has led to the inclusion of limited rendering hints. The features supported arise from several years experience with the World Web and the existing HTML format.
HTML+ documents consists of headers, paragraphs, lists, tables and figures. A simple example of an HTML+ document is:
<title>A simple HTML+ Document</title>
<h1 id="a1">This is a level one header</h1>
<p>This is some normal text which will wrap at the window margin.
You can emphasise <em>parts of the text</em> if you wish.
<p>This is a new paragraph. Note that unlike title and header tags
the matching end tag is not needed.
The text of the document includes tags which are enclosed in <angle
brackets>. Many tags require matching end tags for which the tag name
is preceded by the "/" character. The tags are used to markup the
document's logical elements, for example the title, headers and
paragraphs. Tags may also be accompanied by attributes, e.g. the id
attribute in the header tag which can be used to name destinations for
hypertext links.
Unlike most document formats, HTML+ leaves out the processing instructions that determine the precise appearance, for instance the font names and point size, the margins, tab settings and how much white space to leave before and after different elements. The rendering software makes these choices for itself (perhaps guided by user preferences). This ensures that browsers can avoid problems with different page sizes or missing fonts. Logical markup also preserves essential distinctions that are often lost by lower level procedural formats, making it easier to carry out operations like indexing and conversion into other document formats.
Note that the tag and attribute names are case insensitive. HTML+ parsers are expected to ignore unrecognised tags and attributes, and to process their contents as if the start/end tags weren't present. SGML minimisation is not supported - this avoids any possibility of confusion with unrecognised tags.
An HTML+ document consists of some optional declarations followed by one or more elements from the following:
Keeping a large document such as a book in one node will increase the time it takes to retrieve the node over the network. It is generally better to split large documents into a number of smaller nodes. Many documents are written with the expectation that the reader will start at the beginning and read through until the end. If the document is split into a number of nodes, the intended sequence is known as a path. HTML+ provides a means for authors to specify such paths either explicitly via declarations at the beginning of the node or implicitly according to the context in which a given node is reached. Another possibility is for servers to send such information independently, e.g. as MIME message headers.
You can provide navigation links for readers which appear as buttons on a toolbar or as entries in a navigation menu. For works using a lot of technical terms or perhaps in an unfamiliar language, you can provide glossaries offering further explanation. Readers can invoke this by double clicking on words, or by drag selection and clicking the Glossary menu item. You can also provide a search field that is always present (and can't be scrolled away), in which readers can enter one or more keywords to search an index. These facilities can be specified explicitly using the LINK element. Implicit links allow you to define the table of contents (toc) as an HTML+ document without needing to place links to the toc in every subdocument. The link back to the toc is implied when you follow hypertext link from the toc to its subdocuments.
The tags H1, H2, ... H6 are used to represent headers. H1 is the most significant and rendered in a large font (preferably centered). H2 to H6 are progressively less significant and usually rendered flush left in smaller fonts. A common convention is to begin the body of a document with an H1 header, e.g.
<h1>Introduction to HTML+</h1>
Header names should be appropriate to the following section of the
document, while the title should cover the document as a whole. There
are no restrictions on the sequence of headers, e.g. you could use a
level three header following a level one header.Header and section
elements can take an identifier, unique to the current document, for
use as named destinations of hypertext links. This is specified with
the ID attribute, e.g.
<h1 id="intro">Introduction to HTML+</h1>
This allows authors to create hypertext links to particular sections of
documents. It is a good idea to use something obvious when creating an
identifier, to help jog your memory at a later date. WYSIWYG editors
should automatically generate identifiers. In this case, they should
provide a point and click mechanism for defining links so that authors
don't need to deal explicitly with identifier names. Automatic
generation of IDs for headers, paragraphs and other major elements is
important as it makes it easier for other people to create links to
your document, by ensuring that there are plenty of ID attributes
present as potential destinations.
Should we support headers for which the level is implicitly defined by nestable section elements? We could also support autonumbering of headers. Unfortunately, on further investigation these ideas proved trickier than thought at first, and so have been dropped from this draft.
Normal text is automatically wrapped by the browser at the current window margin and adapts to changes in window size. The text is generally shown in a proportional font:
<P ID="p1">The P element acts as container for the text between
the start tag <P> and end tag </P>. You don't need
to give the end tag as it is implied by the context, e.g. the
following <P> tag.
<P ID="p2">If you wish, you may think of the <P> tag as
a paragraph separator. This works since HTML+ formally doesn't
require you to wrap text up as paragraphs.
This would be rendered as:
The P element acts as a container for the text between the start
tag <P> and the end tag </P>. You don't need to give the end
tag as it is implied by the context, e.g. the following <P> tag.
If you wish, you may think of the <P> tag as a paragraph separator.
This works since HTML+ formally doesn't require you to wrap text up
as paragraphs.
The following samples of HTML+ all produce exactly the same results
when displayed:
<H1>Different ways of using the P element</H1>
<P>The first piece of text</P><P>The second piece</P>
<H1>Different ways of using the P element</H1>
<P>The first piece of text<P>The second piece
<H1>Different ways of using the P element</H1>
The first piece of text<P>The second piece
They all produce:
Different ways of using the P element
The first piece of text
The second piece
In some situations you will want to preserve the original line breaks
and spacing, for this you should use the LIT or PRE elements, these are
described in a later section. You can force line breaks in normal
paragraph text with the <BR> element, but the browser may wrap lines
arbitrarily at window margins prior to reaching the <BR> element.
The ALIGN attribute can be used to center a paragraph, e.g. <P ALIGN=center>. Other possibilities are ALIGN=left (the default), ALIGN=right, ALIGN=justify and ALIGN=indent. This attribute is a hint and may be ignored by some browsers. Note that when using explicit line breaks (see section 5.12) you may wish to switch off word wrap with WRAP=OFF.
Browsers, when parsing paragraphs, can choose to simply treat the <P> tag as denoting a paragraph break. If the paragraph style includes a blank line between paragraphs, then additional care is needed after headers and other major elements to avoid inserting an unwanted blank line, e.g. when a <P> tag directly follows a header. This ability to perceive <P> as a paragraph break provides for continuity with HTML, and allows authors to graduate to treating it as a container in their own time.
Paragraphs can include the following:
By default, HTML+ documents are made up of 8-bit characters from the ISO 8859 Latin-1 character set. The network protocol used to retrieve documents may translate the character set into a locally acceptable form, e.g. EBCDIC. The HTTP protocol uses the MIME standard (RFC 1341) to specify the document type and character set. ISO SGML entity definitions are used to include characters which are missing from the character set or which would otherwise be confused with markup elements, e.g:
& ampersand &
< less than sign <
> greater than sign >
" the double quote sign "
Appendix II lists a broad range of characters and symbols, relating
their ISO names to the corresponding character codes in common
character sets. They allow authors to include accented characters in
7-bit ASCII documents. Some other useful entity definitions are:
– en dash (half the width of an em unit)
— em dash (equal to width of an "m" character)
  en space
  em space
non breaking space
­ soft hyphen (normally invisible)
© copyright sign
™ trade mark sign
® registered sign
There are a large number of entities defined by the ISO, covering most
languages and symbols for publishing and mathematics. Requiring all
browsers to support these would be impractical, e.g. how should a dumb
terminal show such symbols. In some cases there will be accepted ways
of mapping them to normal characters, e.g. as ae and e as e. Perhaps
the safest recommendation is that where authors need to use a
specialised character or symbol, they should use ISO entity names
rather than inventing their own. Browsers should leave unrecognised
entity names untranslated.
In some cases it is useful to specify the language used in a given element, with the LANG attribute. The ISO defines abbreviations for most languages, e.g. FR for french as in: <Q LANG="FR">Je m'aveugle.</Q>. This attribute permits language dependent layout and hyphenation decisions, e.g. Hebrew uses right to left word order.
To allow SGML parsers to recognise entity names, authors should declare them before use, for example:
<!ENTITY % ISOcyr1 PUBLIC "ISO 8879-1986//ENTITIES Russian Cyrillic/EN"> %ISOcyr1;
This introduces ISOcyr1 as a local name for the ISO public identifier for the cyrillic alphabet and then includes the associated set of entity definitions as part of the current document. This declaration is unnecessary for entities defined within the HTML+ DTD.
HTML+ allows authors to embed hypertext links into the document text. In a browser this might look to the reader like:
Links are defined with the A tag[1]. HTML+ supports a number of different link types[2].
Clicking on a link will normally cause the browser to retrieve the linked document and display it in place of the current one. This example is represented by the following piece of HTML+
Links are defined with the <a href="#z1">A tag</a>. HTML+ supports a number of <a href="links.html">different link types</a>.
The first link is to an anchor named "z1" in the current document (using an ID attribute on some element). The second is to a file named "links.html" in the same directory as the current document. The link caption is the text between the start and end tags. The HREF attribute defines the link destination using the URL or URN notations. This may be abbreviated in certain circumstances using relative URLs. The link should be rendered in a clearly distinguishable way, e.g. as a raised button, or with underlined text in a particular color or emphasis. For displays without pointing devices, it is suggested that the link is indicated with a reference number in square brackets after the caption, which the reader enters to follow the link. Note that it is illegal for anchors to include headers, paragraphs, lists etc. The anchor text is restricted to normal text with emphasis and inline images.
The A element has several optional attributes:
You can also use the LINK element at the start of the document to define document-wide relationships with other documents, e.g. a link to a table of contents. This is described later on.
There has been considerable discussion on how to represent character emphasis. The previous draft of HTML+ used a single element to handle all forms with a role attribute for the logical role, and other attributes for providing hints as to how to render the emphasis. This mechanism was seen as being overloaded and prompted the use of separate elements in the current draft.
In many cases it is convenient to indicate directly how the text is to be rendered, e.g. as italic, bold, underline or strike-through:
<I>italic text</I> italic text
<B>bold text</B> bold text
<U>underlined text</U> underlined text
<S>strike through</S> strike through
<SUP>superscript</SUP> superscript
<SUB>subscript</SUB> subscript
<TT>fixed pitch</TT> fixed pitch (TT for Teletype)
These tags may be nested to combine effects, e.g. bold-italic-fixed-pitch text, and should be considered as hints rather than as binding obligations on the browser, e.g.
Some <B><I><TT>bold italic fixed pitch text</TT></I></B>.
which is rendered as: Some bold italic fixed pitch text.
<EM>normal emphasis</EM> typically italic
<STRONG>strong emphasis</STRONG> typically bold
These tags indicate the role of the marked text, e.g. bibliographic references. By using a standard way of marking up text, it becomes possible to automatically index such references. There are a potentially huge number of different distinctions that could be made, and the set given below is intentionally minimalistic. Discussion is welcomed on just which elements should be included in HTML+ given its intended role as a delivery format for hypertext documents:
<cmd>cmp</cmd> [<arg>-l</arg>] [<arg>-s</arg>] <var>file1</var> <var>file2</var>
When translating from other SGML-based formats, documents may include non-standard elements e.g. PROPNAME for proper names. HTML+ browsers will normally ignore such markup and process their contents as if these tags weren't present. The RENDER element can be used to tell the browser how to render such tags, e.g.
<RENDER TAG="PROPNAME" STYLE="I">
The STYLE attribute is a comma separated list of presentation tag names, i.e. one or more names from the list: I, B, U, S, SUP, SUB, TT. Include P in the list of styles if the element needs a paragraph break. Keeping non-standard markup in HTML+ documents may be useful for indexing purposes. Note that the RENDER element isn't meant to apply retrospectively.
Authors can include annotations which act to draw the readers attention or which provide some additional comment on the main text of the paragraph. There are two types:
Images can be included as character like elements with text flowing around the image, e.g.
[Picture missing] Before coming to CERN, Tim worked on, among other
[in text version] things, document production and text processing.
He developed his first hypertext system,
"Enquire", in 1980 for his own use (although unaware of the existence
of the term HyperText). With a background in text processing,
real-time software and communications, Tim decided that high energy
physics needed a networked hypertext system and CERN was an ideal
site for the development of wide-area hypertext ideas. Tim started
the WorldWideWeb project at CERN in 1989. He wrote the application
on the NeXT along with most of the communications software.
This example is produced by the following piece of HTML+
<p><img align=top src="http://spoof.cern.ch/people/tbl.gif"> Before
coming to CERN, Tim worked on, among other things, document
production and text processing. He developed his first hypertext
system, "Enquire", in 1980 for his own use (although unaware of
the existence of the term HyperText). With a background in text
processing, real-time software and communications, Tim decided
that high energy physics needed a networked hypertext system and
CERN was an ideal site for the development of wide-area hypertext
ideas. Tim started the WorldWideWeb project at CERN in 1989. He
wrote the application on the NeXT along with most of the
communications software.
The IMG element specifies an image via a URL. The ALIGN=TOP attribute ensures that the top of the image is level with the top of the current text line. You can also use ALIGN=MIDDLE to align the center of the image with that of the current text line, and ALIGN=BOTTOM to align the bottom of the image with the bottom of the current text line. Browsers are not expected to apply text flow retrospectively, so using ALIGN=MIDDLE and ALIGN=BOTTOM may overwrite previous lines of text. If the ALIGN attribute is missing then ALIGN=TOP is assumed.
Not all display types can show images. The IMAGE element behaves in the same way as IMG but allows you to include descriptive text, which can be shown on text-only displays:
<image align=top src="http://spoof.cern.ch/people/tbl.gif">A photo
of Tim Berners-Lee</image> Before coming to CERN, Tim worked on,
among other things, document production and text processing. etc.
On text-only displays, the text within the IMAGE element can be shown in place of the image:
[A photo of Tim Berners-Lee] Before coming to CERN, Tim worked on,
among other things, document production and text processing. etc.
The SEETHRU attribute can be used to designate a chromakey so that the image background matches the document background. This is an experimental feature and the format of the attribute's value has yet to be defined - suggestions are welcomed.
Images can be made active in one of three ways
<a href="bigpic.giff"><image src="smallpic.gif">Our house</image></a>
In this example, readers can click on a small picture embedded in the document to see a larger version, which would take significantly longer to retrieve. When using images as hypertext links, don't forget to include a textual description. This is needed for the link caption for people using text-only displays.
In some cases, servers can handle mouse clicks or drags on the image. This capability is signalled in the header information returned along with the image data. You can also use the ISMAP attribute. This mechanism and the ability to add shaped buttons are defined in detail in the description of figures.
The delay in connecting to the server for each image in turn can be reduced by asking HTTP servers to include images with the HTML+ document as a MIME multipart message (include multipart/mixed with the Accept: header in the request message).
Change bars are shown for parts of the document designated with the CHANGED element. This can appear anywhere that normal text is allowed (as shown by the %text; entity reference in the DTD):
<changed id=z34>text including some changes<changed idref=z34>
The same element is used to designate the start and end of changes, using matched ID and IDREF attribute values. This mechanism avoids syntactic problems that would arise from using a conventional start and end tag pair, as changes to a document can span different levels of the document's formal structure. Additional attributes may be used with the CHANGED element to hold related details, e.g. BY, WHEN, WHY, WHAT.
In legal documents and amendments to proposed legislation, there is often the need to show parts of the text as being removed or added to the document. This is commonly shown using strike-through and underlining respectively. The REMOVED and ADDED tags are provided for this purpose:
<P>This bill would require the Legislative Counsel, with the advice
of the Joint Rules Committee of the Senate and Assembly, to make
available to the public by means of access by way of
<removed>computer modem</removed> <added>the largest nonproprietary,
nonprofit cooperative public computer network,</added> specified
information concerning bills, the proceedings of the houses and
committees of the Legislature, statutory enactments, and the
California Constitution.
Which might be displayed (on a dumb terminal) as:
This bill would require the Legislative Counsel, with the advice of
the Joint Rules Committee of the Senate and Assembly, to make
available to the public by means of access by way of
<removed>computer modem</removed> <added>the largest nonproprietary,
nonprofit cooperative public computer network,</added> specified
information concerning bills, the proceedings of the houses and
committees of the Legislature, statutory enactments, and
the California Constitution.
Color enhancements may be used to further distinguish the amendments, e.g. red lines for strike-through. This mechanism is not intended for representing revision histories, which are better served by traditional change control mechanisms.
It is often quite difficult to phrase the captions for hypertext buttons so that they make sense when printed out. The ONLINE and PRINTED elements can be used to define text which is for use only when read on-line or on the printed page respectively:
<online>click <a href="info.html">here</a>for more information.</online> <printed>Further information can be found in [Higgins 84b].</printed>
In many cases, you can find a way of phrasing the reference so that it makes sense both ways. Browsers can help by referencing hypertext links as footnotes when printed out. See the earlier description of the PRINT attribute for the A tag.
You can make individual lines explicit with the <L> element, which contains the text of the line in the same way that <P> contains the text of the paragraph.
<P>
<L>22 The Avenue,
<L>Harrow,
<L>London, NW1 5ER
An alternative is the <BR> element which acts as a forced line break.
<P>22 The Avenue<BR>
Harrow,<BR>London, NW1 5ER
The <L> element is useful when you want to name each line, e.g. <L ID="L23">. You may also want to disable word wrap for the current paragraph, as in <P WRAP=OFF>.
To avoid all text appearing in the same style, HTML+ provides distinct styles for quotes, abstracts, bylines and admonishments. All these elements can contain multiple paragraphs:
When you want to include a quotation that extends over more that one paragraph, you should use the QUOTE element. Quoted text should preferably be indented, and rendered using a distinctive font, e.g.
<P>The following is a quotation from the forward by Yuri Rubinsky
to "The SGML Handbook" by Charles F. Goldfarb, published by the
Clarendon Press, Oxford, 1990.
<QUOTE>The next five years will see a revolution in computing. Users
will no longer have to work at every computer task as if they had
no need or ability to share data with all their other computer tasks,
they will not need to act as if the computer is simply a replacement
for paper, nor will they have to appease computers or software
programs that seem to be at war with one another.</QUOTE>
which might be rendered as:
The following is a quotation from the forward by Yuri Rubinsky to
"The SGML Handbook" by Charles F. Goldfarb, published by the
Clarendon Press, Oxford, 1990.
The next five years will see a revolution in computing. Users
will no longer have to work at every computer task as if they
had no need or ability to share data with all their other computer
tasks, they will not need to act as if the computer is simply a
replacement for paper, nor will they have to appease computers or
software programs that seem to be at war with one another.
The ABSTRACT element can be used to give an overview of a document and typically follows a level one heading. It should be rendered in an easily read font, distinct from normal text, and preferably indented. An example is given in the next section.
The BYLINE element is similar to QUOTE and is used for information about the author, e.g. contact details and release date. A common convention is to include a hypertext link to a node with more information about the author. Bylines can occur at the beginning or end of a document, e.g:
<H1>HTML+ (Hypertext markup format</H1>
<ABSTRACT>A proposed standard for a light weight delivery format
for browsing and querying information in a web of globally
distributed hypertext accessible over the Internet
</ABSTRACT>
<BYLINE>Editor: Dave Raggett dsr@hplb.hpl.hp.com</BYLINE>
The NOTE element is used when you want to draw the readers attention to some point or other. For example:
<note role="NOTE" src="info.gif">
The "partial-window-name" parameter must exactly match the beginning
characters of the window name (as it appears on the title bar),
including proper case (capital or lower letters) and any punctuation.
</note>
This is typically rendered as:
---------------------------------------------------------------------- NOTE: The "partial-window-name" parameter must exactly match the beginning characters of the window name (as it appears on the title bar), including proper case (capital or lower letters) and any punctuation. ----------------------------------------------------------------------
The text of the ROLE attribute (if given) is inserted at the start of the note in a bold font and followed by a colon. Typical roles are TIP, NOTE, WARNING and ERROR. The SRC attribute may be used to name a URL or URN as an icon which is displayed in the left margin at the start of the note. An upright hand icon is often used for tips; a warning road sign for warnings and a stop sign for errors. Horizontal rules are drawn automatically to help readers distinguish the note from the surrounding text. You can place horizontal rules in other parts of your document using the <HR> element which can appear anywhere a <P> element is allowed.
There are three kinds of lists, which can be freely nested within one another:
The OL element is used with LI for each item to represent ordered lists:
<OL>
<LI>Wake up
<LI>Get dressed
<LI>Have breakfast
<LI>Drive to work
</OL>
which is usually rendered as:
1) Wake up
2) Get dressed
3) Have breakfast
4) Drive to work
The COMPACT attribute when present e.g. <OL COMPACT> has the effect of reducing inter-item spacing. The numbering style is the responsibility of the browser. Other styles use roman numerals or letters from the alphabet in upper or lower case. One issue for browsers, is how to render ordered lists, nested within a list of the same type. List item text can't include headers, see the DTD in Appendix I for details.
Bulleted lists are represented with the UL and LI elements:
<UL>
<LI>Wake up
<LI>Get dressed
<LI>Have breakfast
<LI>Drive to work
</UL>
which is usually rendered as:
o Wake up
o Get dressed
o Have breakfast
o Drive to work
The COMPACT attribute when present e.g. <UL COMPACT> has the effect of
reducing inter-item spacing. The bullet style is the responsibility of
the browser, and normally an unordered list nested within a list of the
same type is given a different style (bullet, dash, box or check).
Authors can instead use the SRC attribute for the LI element to specify
an icon with a URL or URN, e.g. <LI SRC="folder.gif">. List item text
can't include headers, see the HTML+ DTD in Appendix I for details.
Plain lists without bullets are represented by the UL element together with the PLAIN attribute, e.g. <UL PLAIN>. The WRAP attribute is used for multi-column lists and should be WRAP=HORIZ for horizontally wrapping of list items or WRAP=VERT for vertical wrapping of list items, e.g.
<UL PLAIN>
<LI>icons1/
<LI>icons2/
<LI>icons3/
<LI>src/
<LI>xpm-3-paper.ps
<LI>xpm-3.2-to-3.2a.patch
</UL>
without the WRAP attribute, this is rendered as:
icons1/
icons2/
icons3/
src/
xpm-3-paper.ps
xpm-3.2-to-3.2a.patch
with <UL PLAIN WRAP=VERT> this would appear like:
icons1/ icons3/ xpm-3-paper.ps
icons2/ src/ xpm-3.2-to-3.2a.patch
with WRAP=HORIZ it would appear like:
icons1/ icons2/ icons3/
src/ xpm-3-paper.ps xpm-3.2-to-3.2a.patch
Everyday familiarity with printed lists leads us to expect lists to be organized into columns which are read top to bottom; horizontally wrapped lists are seldom seen. Browsers are free to choose the number of columns to match the current window size and item widths. If there are N items and M columns then the longest column will have (N+M-1)/M rows. This requires a prepass through the list to count the items (and optionally their maximum width). However, this information can be cached to avoid speed penalties when resizing the window or refreshing the screen. You can use the SRC attribute for the LI element to specify an icon for each item in the list, e.g. to show the type of each document in a directory listing.
For convenience, the <MENU> and <DIR> elements can be used in place of <UL PLAIN> and <UL PLAIN WRAP=VERT> respectively.
These consist of pairs of terms and definitions, but can also be used for plays as in:
<DL>
<DT>King Henry
<DD>I myself heard the King say he would not be ransomed.
<DT>Williams
<DD>Ay, he said so, to make us fight cheerfully: but when our
throats are cut he may be ransomed, and we none the wiser.
<DT>King Henry
<DD>If I live to see it, I will never trust his word after.
<DT>Williams
<DD>You pay him then! That's a perilous shot out of an
elder-gun, that a poor and a private displeasure can do
against a monarch! You may as well go about to turn the sun
to ice, with fanning in his face with a peacock's feather.
You'll never trust his word after! Come `tis a foolish
saying.
</DL>
This could be rendered as:
King Henry: I myself heard the King say he would not be
ransomed.
Williams: Ay, he said so, to make us fight cheerfully: but
when our throats are cut he may be ransomed, and we none
the wiser.
King Henry: If I live to see it, I will never trust his word
after.
Williams: You pay him then! That's a perilous shot out of an
elder-gun, that a poor and private displeasure can do
against a monarch! You may as well go about to turn the sun
to ice, with fanning his face with a peacock's feather.
You'll never trust his word after! Come `tis a foolish saying.
or as:
King Henry I myself heard the King say he would not be
ransomed.
Williams Ay, he said so, to make us fight cheerfully: but
when our throats are cut he may be ransomed, and
we none the wiser.
King Henry If I live to see it, I will never trust his word
after.
Williams You pay him then! That's a perilous shot out of an
elder-gun, that a poor and private displeasure can
do against a monarch! You may as well go about to
turn the sun to ice, with fanning his face with a
peacock's feather. You'll never trust his word
after! Come `tis a foolish saying.
Browsers should make allowance for the infrequent case when the term text (DT) is longer than the definition text (DD) and wraps onto subsequent lines. Note that you are allowed to have several consecutive DT elements followed by a DD element, but you can't have DD without an associated DT element, The COMPACT attribute as in <DL COMPACT> forces the browser to use the former more compact style.
The FIG element is similar to the IMAGE element, but acts as a paragraph. The ALIGN attribute can be one of LEFT (the default), CENTER, RIGHT or FLOAT. This determines whether the figure is flush left, centered or flush right. If ALIGN=FLOAT the figure may float to another more convenient location (and possibly zoomed or reduced in the process). A caption can be defined with the CAPTION element and followed by text describing the figure for readers using text only displays:
<FIG ALIGN=FLOAT SRC="cat.gif">
<CAPTION>"Not curried fish again!"<CAPTION>
A cartoon of a scrawny cat with its tongue out saying ACK!
</FIG>
<P>The text in the following paragraphs will flow around the figure
if there is enough room. The browser is free to position the caption at
the top, bottom or sides of the figure.
which is rendered as:
[ ] The text in the following paragraphs will
[ picture missing ] flow around the figure if there is enough
[ ] room. The browser is free to position the
[ ] caption at the top, bottom or sides of the
figure.
"Not curried fish again!"
Note that browsers can only support a limited range of image types.
Currently these are GIF and XBM (X bitmap format). This list will
evolve over time.
The uppe left of the image is designated as x,y = (0, 0), with x increasing across the page and y down the page. This choice was made for continuity with the IMG element in HTML, to ensure a simple migration path to HTML+. If points are given in real numbers, the lower right corner of the image is taken as being (1.0, 1.0), otherwise, with integer values the coordinates are assumed to be in pixels. A simple test to distinguish the two schemes is to check if a "." character occurs anywhere in the list of points. Using scaled coordinates is much safer as the pixel extent of an image may alter, e.g. as a result of format negotiation with the server.
For some images, HTTP servers will be able to handle mouse/pen clicks or drags on the image. This is signalled in the header information returned along with the image data. Alternatively, the ISMAP attribute can be used to signal this capability. The mouse click is sent to the server indicated by the URL in the SRC attribute, using the same URL plus the suffix "?x=X&y=Y" where X and Y are the coordinates of the click event. Mouse drags can be used to designate a rectangular region of the image. In this case the suffix takes the form: "?x=X&y=Y&w=W&h=H" where (X, Y) is the upper left of the rectangle, and (W, H) define its width and height. The ISMAP mechanism is useful when the active regions in the image change their boundaries with time, e.g.
<fig ismap src="weather.gif">
<caption>Click on your area for a local forecast</caption>
Todays weather map for the US.
</fig>
The A element can be used to define shaped buttons on top of images. The shape is defined by an arbitrary polygon and specified via the SHAPE attribute, e.g.
<FIG SRC="test.gif">
<CAPTION>Click on the triangle or the rectangle</CAPTION>
A line drawing with a
<A SHAPE="0.35,0.1&0.1,0.8&0.35,0.8" HREF="button1.html">
triangle</A> and a
<A SHAPE="0.5,0.25&0.5,0.5&0.8,0.5&0.8,0.25" HREF="button2.html">
rectangle</A>
</FIG>
Which could be rendered as:
[ Picture missing in text file ]
The example uses scaled coordinates, and shows how you give the vertices of the polygon defining the shape of the button. Like the ISMAP mechanism, you can use pixel-based coordinates by using integer numbers throughout. Note that clicks on shaped buttons take precedence over the ISMAP mechanism for sending events to the server. An efficient algorithm for testing if a mouse/pen click lies inside a polygon is given as a C routine in Appendix III.
In future, HTML+ may be extended to support simple drawings with embedded hypertext links. One idea would be a line drawing primitive using the SHAPE attribute. A better approach is to extend existing drawing formats such as the ANSI Computer Graphics Metafile format (CGM) or Adobe's PDF to include URL based hypertext links. This extended format could then be used for figures within HTML+ documents.
The use of the MIME multipart message format would also help to speed up the display of figures by sending image data at the same time as the HTML+ document. Another possibility would be to allow image data to be embedded in the document using an EMBED element in place of the SRC attribute. Binary data could be represented using the MIME character encoding or the more compact ASCII base 85 encoding, as used in Adobe's PDF. The drawback with this approach is the inability to use format negotiation. As a result, the EMBED element has been dropped from the current draft.
Tables are specified using the TABLE element. This allows you to define a caption and to differentiate header and data cells. Cells may contain, text, multiple paragraphs, lists and headers. Adjacent cells can be merged, e.g. to define a header which spans two columns. A simple table could look like:
Table 1: A simple tableThis is defined by the markup:------------------------------- | Year | Month | Day | ------------------------------- | 1972 | June | 23rd | ------------------------------- | 1982 | October | 7th | -------------------------------
<table border>
<caption>A simple table</caption>
<th>Year <th>Month <th>Day <tr>
<td>1972 <td>June <td>23rd <tr>
<td>1982 <td>October <td>7th
</table>
The BORDER attribute acts as a hint to the browser to draw lines
enclosing each cell. The TH element precedes header cell text and the
TD element precedes data cell text. The TR element is used to separate
table rows. By default text is centered in each cell. Header text
should be shown emphasised, e.g. the browser could use a bold sans
serif font for headers and a serif font for the data cells. The next
example shows how cells can be merged with their neighbors:
Table 2: A more complex tableThis table is defined by the markup:average other height weight category
males 1.9 0.003 yyy
females 1.7 0.002 xxx
<table> <caption>A more complex table</caption> <th rowspan=2><th colspan=2>average<th rowspan=2>other<br>category<tr> <th>height <th>weight <tr> <th align=left>males <td>1.9 <td>0.003 <td>yyy <tr> <th align=left>females <td>1.7 <td>0.002 <td>xxx </table>The first cell (a header cell) is merged with the cell below it: <th rowspan=2>. Note that this merged cell is empty - the definition of the next column for the first row starts immediately. Looking again at the first row, the second column is merged with the third: <th colspan=2>. The definition for the third column is skipped as it was covered by the merged cell. The fourth column/first row is also merged, this time with the next row: <th rowspan=2>. The <BR> element has been used here to force a line break between other and category. The <TR> element signifies the end of the first row and the beginning of the second. Note that empty cells at the end of a row can be omitted as the <TR> element unambiguously marks the end of the row.
The second row only contains definitions for the second and third columns since the others were merged with cells on the preceding row. The general rule is to avoid defining any cell twice. The last two rows start with headers and the align=left attribute ensures that the browser will align these headers to the left of their cells. The ALIGN attribute can be one of LEFT, CENTER or RIGHT, with CENTER as the default. It can be used with both TH and TD.
Browsers need a prepass through the table markup to count the number of columns and determine their widths. A simple algorithm that takes merged cells into account will suffice. Text fields wrap to fit their columns, which should be sized to best match current window width. This information should be cached to avoid speed penalties during subsequent screen refresh/ window resize operations. Browsers can ignore alignment hints if required, and using a fixed pitch font may speed up the sizing step.
The number of columns is given by the row with the largest number of <TH> and <TD> elements, remembering to add in merged cells. The widths of columns are evaluated by finding the minimum and maximum widths needed for each cell, and hence the minimum and maximum width for the column as a whole. All this can be done during a single pass through the <TABLE> element. Caching these min/max values for each column then permits the browser to instantly adjust the table when the window is resized.
Forms are composed by placing input fields within paragraphs, preformatted/literal text, lists and tables. This gives considerable scope in designing the layout of forms. Each field is defined by an INPUT element and must have an NAME attribute which uniquely names the field in the document. Additional optional attributes can be used to specify the type of the field (defaults to free text), its size/precision, its initial value and whether the field is currently disabled or in error:
<FORM ACTION="mailto:www_admin@info.cern.ch">
<MH HIDDEN>Subject: WWW Questionaire</MH>
Please help up to improve the World Wide Web by filling in the
following questionaire:
<P>Your organization? <INPUT NAME="org" SIZE="48">
<P>Commercial? <INPUT NAME="commerce" TYPE=checkbox>
How many users? <INPUT NAME="users" TYPE=int>
<P>Which browsers do you use?
<OL>
<LI>X Mosaic <INPUT NAME="browsers" TYPE=checkbox VALUE="xmosaic">
<LI>Cello <INPUT NAME="browsers" TYPE=checkbox VALUE="cello">
<LI>Others <TEXTAREA NAME="others" COLS=48 ROWS=4></TEXTAREA>
</OL>
A contact point for your site: <INPUT NAME="contact" SIZE="42">
<P>Many thanks on behalf of the WWW central support team.
<P ALIGN=CENTER><INPUT TYPE=submit> <INPUT TYPE=reset>
</FORM>
This fictitious example is a questionnaire that will be emailed to
www_admin@info.cern.ch. The FORM element is used to delimit the form.
There can be several forms in a single document, but the FORM element
can't be nested. The ACTION attribute specifies a URL that designates
an HTTP server or an email address. If missing, the URL for the
document itself will be assumed. The effect of the action can be
modified by including a method prefix, e.g. ACTION="POST http://....".
This prefix is used to select the HTTP method when sending the form's
contents to an HTTP server. Would it be cleaner to use a separate
attribute, e.g. METHOD?
Servers can disable forms by sending an appropriate header or by an attribute on the optional HTMLPLUS element at the very start of the document, e.g.
<htmlplus forms=off>.
The MH element can be used to specify RFC 822 mail headers that are included when sending the form's content either as an email message or as a HTTP request, e.g.
<MH HIDDEN>
Subject: WWW Questionnaire
Priority: Low
</MH>
The MH element can contain several headers separated by line breaks.
The text within the MH element is transcribed directly, preserving
spaces, tabs and line breaks, with each line terminated by a CR LF pair
as per the RFC 822 guidelines. The preceding example of a form might be
rendered as:
---------------------------------------------------------------------- Please help us to improve the World Wide Web by filling in the following questionnaire:Your organization: [ ] Commercial [N] How many users? [ ]
Which browsers do you use?
1) X Mosaic [ ]
2) Cello 3) Others [ ] [ ] [ ] [ ]
A contact point for your site? [ ]
Many thanks on behalf of the WWW Central support team.
(Submit) (Reset) ----------------------------------------------------------------------
Here, the <P> and <OL> elements have been used to lay out the text and input fields. The browser has changed the background color within the FORM element to distinguish the form from other parts of the document. The browser is responsible for handling the input focus, i.e. which field will currently get keyboard input.
For many platforms there will be existing conventions for forms, e.g. tab and shift-tab keys to move the keyboard focus forwards and backwards between fields, while an Enter key submits the form. In the example, the Submit and Reset buttons are specified explicitly with special purpose fields. The Submit button is used to email the form or send its contents to the server as specified by the ACTION attribute, while the Reset button resets the fields to their initial values. When the form consists of a single text field, it may be appropriate to leave such buttons out and rely on the Enter key.
The INPUT element has the following attributes:
<TEXTAREA NAME="address" ROWS=64 COLS=6>
Hewlett Packard Laboratories
1501 Page Mill Road
Palo Alto, California 94304-1126
</TEXTAREA>
The text up to the end tag is used to initialize the field's value. This end tag is always required even if the field is initially blank. The ROWS and COLS attributes determine the visible dimension of the field in characters. Browsers are recommended to allow text to grow beyond these limits by scrolling as needed. In the initial design for forms, multi-line text fields were supported by the INPUT element with TYPE=TEXT. Unfortunately, this causes problems for fields with long text values as SGML limits the length of attribute literals. The HTML+ DTD allows for up to 1024 characters (the SGML default is only 240 characters!).
The RADIO and CHECKBOX fields can be used to specify multiple choice forms in which every alternative is visible as part of the form. An alternative is to use the SELECT element which is generally rendered in a more compact fashion as a pull down combo list. Every alternative is represented by the OPTION element, e.g.
<SELECT NAME="flavor">
<OPTION>Vanilla
<OPTION>Strawberry
<OPTION>Rum and Raisin
<OPTION>Peach and Orange
</SELECT>
The SEVERAL attribute is needed when users are allowed to make several selections, e.g. <SELECT SEVERAL>. The ERROR attribute can be used to indicate that the initial selection is in error in some way, e.g. because it is inconsistent with the values of other fields.
The OPTION element can take the following attributes:
The form contents are expressed as a property list of attribute names and values. Radio buttons and checkboxes are left out of the list when unchecked. This ensures that only the selected radio button contributes a name=value pair. Omitting the VALUE attribute for a checkbox field causes the field when checked to appear as a name without a value (this is appropriate for Boolean attributes). Currently, there are two ways of transferring form contents to an HTTP server:
URL?org=Acme%20Foods&commerce&users=42
Note that "=", "&" and space characters in attribute names and values should be escaped by "%" followed by the hexadecimal code for the character in question, e.g. "%20" should be used in place of the space character. IMAGE fields are only included in the list when clicked, and give rise to something matching:
URL?name.x=23&name.y=29
They can be used as iconic controls for other images or data. The object-name.property-name notation paves the way for more complex input controls in the future. In the near future, format negotiation will not change the number of pixels in an image, so using pixel based coordinates is okay. In the longer term, scaled coordinates in the range 0 to 1.0 may prove safer.
Multipart MIME messages are necessary if the form contains scribble or audio fields. Form data can be sent in the same name=value representation as described above. For scribble and audio fields, the value identifies a subsequent part in the multipart message, as specified by the Content-ID: header for each part. Another approach is to send just the SGML elements used to define form fields, i.e. the INPUT, TEXTAREA and SELECT elements. The Content-ID: headers are used to define dummy URLs. It may be possible for servers to use this approach to update forms being viewed by a browser without having to send the entire document.
In this case, the form needs to be viewable on ordinary mail readers. The form should be converted to ASCII and mailed as a plain text message, preceded by the headers as specified by the MH element. Each INPUT field is copied as text and delimited by the "[" and "]" characters. An longer term alternative is to send the HTML+ document as a MIME message, along with the current values for each field.
Preformatted text started off in HTML with a simple mechanism for showing computer output, for which the spaces and line breaks were significant in determining the layout. The desire to offer Unix manual pages as hypertext forced a rethink. The next version supported character emphasis and embedded hypertext buttons. HTML+ adds the capability to use variable pitch fonts and to set up tab stops.
The LIT element is rendered in a proportional font, e.g.
<LIT>
From Oberon in fairyland,
The king of ghosts and shadows there,
Mad Robin I, at his command,
Am sent to view the night sports here.
What revel rout
is kept about,
In every corner where I go,
I will o'ersee
And merry be
And make good sport, with ho, ho, ho!
</LIT>
This is rendered literally as:
From Oberon in fairyland,
The king of ghosts and shadows there,
Mad Robin I, at his command,
Am sent to view the night sports here.
What revel rout
Is kept about,
In every corner where I go,
I will o'ersee
And merry be
And make good sport, with a ho, ho, ho!
The ability to set tab stops in LITeral text makes it much easier to write filters that convert documents written on word processors into HTML+. Tab stops can be set by the TAB element and apply for the scope of the LIT element, e.g.
<tab at=40 align=right>
The AT attribute specifies the position of the tab stop, as measured from the left margin in terms of the width of a capital M. The ALIGN attribute can be LEFT, CENTER or RIGHT, defaulting to LEFT. These have the conventional meaning as used on most word processors. If greater control over fonts and layout is needed then authors should make a hypertext link to a document written in a page description format like Adobe's PDF.
For computer output or plain text files, you should use the PRE element which is rendered in a fixed pitch font. The following is part of the man page for the Unix ls command:
<PRE> The next 9 characters are interpreted as three sets of three bits each which identify access permissions for owner, group, and others as follows:+------------------ 0400 read by owner (<B>r</B> or <B>-</B>) | +---------------- 0200 write by owner (<B>w</B> or <B>-</B>) | | +-------------- 0100 execute (search directory) by owner | | | (<B>x</B>, <B>s</B>, <B>S</N>, or <B>-</B>) | | | +------------ 0040 read by group (<B>r</B> or <B>-</B>) | | | | +---------- 0020 write by group (<B>w</B> or <B>-</B>) | | | | | +-------- 0010 execute/search by group | | | | | | (<B>x</B>, <B>s</B>, <B>S</B>, or <B>-</B>) | | | | | | +------ 0004 read by others (<B>r</B> or <B>-</B>) | | | | | | | +---- 0002 write by others (<B>w</B> or <B>-</B>) | | | | | | | | +-- 0001 execute/search by others | | | | | | | | | (<B>x</B>, <B>t</B>, <B>T</B>, or <B>-</B>) | | | | | | | | | r w x r w x r w x
</PRE>
This is rendered as
The next 9 characters are interpreted as three sets of three bits each which identify access permissions for owner, group, and others as follows:+------------------ 0400 read by owner (r or -) | +---------------- 0200 write by owner (w or -) | | +-------------- 0100 execute (search directory) by owner | | | (x, s, S, or -) | | | +------------ 0040 read by group (r or -) | | | | +---------- 0020 write by group (w or -) | | | | | +-------- 0010 execute/search by group | | | | | | (x, s, S, or -) | | | | | | +------ 0004 read by others (r or -) | | | | | | | +---- 0002 write by others (w or -) | | | | | | | | +-- 0001 execute/search by others | | | | | | | | | (x, t, T, or -) | | | | | | | | | r w x r w x r w x
The SEE ALSO section of the Unix manual pages can be processed to make references to other manual pages into hypertext buttons using the <A> element (see section 5.2). The example shows how character emphasis can be added to literal or preformatted text.
Currently, the best way of including equations in HTML documents is to first write the document in LaTeX and then use the latex2html filter to create the corresponding HTML document, together with the equations as a number of bitmap files. The previous draft of the HTML+ specification described a way of embedding LaTeX equations in HTML+ documents. Unfortunately, it now seems too cumbersome to form a practical solution, and has been dropped. The following is a preliminary proposal for representing equations directly as HTML+ using an SGML-based notation, inspired by the approach taken by LaTeX. It is intended to cover the majority of users needs, rather than aiming for complete coverage. This makes it practical to use a simplified notation compared with richer notations, e.g. the ISO 12083 Maths DTD. An experimental browser supporting the MATH element is being developed at CERN.
Consider the equation:
-st
H(s) = integral from 0 to infinity of e h(t) dt
This can be represented as:
<math>
H(s) = ∫<sub>0</sub><sup>∞</sup>
e<sup>-st</sup> h(t) dt
</math>
The mathematical symbols are given with their standard ISO entity names. SUB and SUP are used to specify subscripts and superscripts. For integral signs and related operators, the subscript/superscript text is centered over the symbol, otherwise it appears to the right as shown in the preceding example. The BOX and OVER elements allow you to define more complex equations, as in:
dV V - V
out ( Kappa ( in out))
C ----- = I tanh( -------------------)
dt b ( 2 )
which is represented by:
<math>
C <box>dV<sub>out</sub><over>dt</box> = I<sub>b</sub>
&tanh;(<box>κ(V<sub>in</sub> - V<sub>out</sub>)
<over>2</box>)
</math>
The BOX element can be used to generally group items and can be thought of as non-printing parentheses. The OVER element is optional and divides the box into numerator and denominator. The ARRAY element is used to specify arrays for expressions like:
( |x x | )
( | 11 12| )
( | | )
( |x x | )
( | 21 22| )
( )
( y )
( )
( z )
The ARRAY element has a single attribute ALIGN which specifies the number of columns and the alignment of items within the columns. For each column there is a single letter that specifies how items in that column should be positioned: c for centered, l for flush left or r for flush right. Each item in the array must follow an <ITEM> element.
The preceding example is represented by:
<math>
(<array align="c"> <item>
&ldet;<array align="cc">
<item>x<sub>11</sub>
<item>x<sub>12</sub>
<item>x<sub>21</sub>
<item>x<sub>22</sub>
</array><rd>&rdet;
<item> y <item> z
</array>)
</math>
The browser is responsible for working out the vertical and horizontal spacing required for the array. Parentheses are stretched to match the size of the array. Arrays can be used only in the context of the MATH element. The TABLE element should be used for other contexts.
Spaces are significant within the MATH element, and used for disambiguation, as can be seen in the following two examples:
integral from i to j of x ∫<sub>i</sub>i<sup>j</sup> x
j
integral of x ∫ <sub>i</sub>i<sup>j</sup>x
i
Authors can adjust the default horizontal spacing with the ISO entities:   for thin space (1/6 em) and   for hair space. Horizontal, diagonal and vertical ellipsis are possible with … &dellip; and ⋮ respectively. Common functions like sin, log and tanh should be rendered in a non-italic font. These functions are defined by their entity namesakes. Additional elements are needed to represent roots and for over and under lining.
An open question is how to render maths on dumb terminals. One approach is to translate into an existing convention such as Mathematica. Another is to write equations as they would be spoken aloud. For GUI displays, browsers need to be able to show characters in at least two point sizes as well as being able to stretch parentheses and integral signs etc. to various sizes. The processing time needed to size and position symbols suggests that caching may be useful to speed up subsequent scrolling and refresh operations.
Comments from mathematicians are welcomed. Widespread support for formulae is likely to be delayed until most platforms support the relevant symbols fonts (or Unicode).
A good index plays an important role in helping you find your way to the material you need. It allows you to type in one or more keywords to see a list of matching topics. The ability to view an index directly allows you to gain a feeling for what is covered, and lets you dip in and out of the associated document. Full text indexes like WAIS are easy to create, but don't give you this flexibility since the index itself cannot be viewed directly.
Generating a conventional index for a document is a skilled task, and HTML+ allows authors to include directives for automatically creating hypertext indexes. These directives can be included in many HTML+ elements, such as headers, paragraphs and character emphasis using the INDEX attribute. This allows each such element to be referenced in the index under primary or secondary keys, e.g.
<h3 id="z23" index="Radiation damage/shielding from as difficult">
Radiation shielding</h3>
This can be used to generate an index like:
Radiation damage
classical target theory
dominance of
in molecular mills
shielding from as difficult
simple lifetime model
track-structure lifetime model
Radicals
and so on ...
In many cases, a given key will be associated with more than one part
of the document. In this case you can either use secondary keys to
disambiguate the references, as shown above, or allow the indexing
program to generate its own names for each reference, e.g. (a), (b),
(c), ...
The indexing program creates an HTML+ file that can then be linked to the documents it was produced from. The program may also generate a list of references from occurrences of the CITE element. These can be simply ordered alphabetically. Sophisticated bibliographic references are beyond the scope of HTML+ as they require a much richer system of markup.
It is recommended that HTML+ documents start with the following external identifier, indicating that the document conforms to the HTML+ DTD. This will ensure that other SGML parsers can process HTML+ documents, without needing to include the DTD with each document.
<!DOCTYPE htmlplus PUBLIC "-//Internet/RFC xxxx//EN">
There are several elements that can only occur at the start of the
document before any headers or text elements:
This element if present must follow immediately after the DOCTYPE declaration. It can be used to disable form filling:
<htmplus forms=off>
Another idea is to provide a VERSION attribute for specifying the version number of HTML+ in used by this document. This would provide an alternative to including the version number in the public name given with the DOCTYPE element.
These may be used to delimit the document declarations and document body with the HEAD and BODY elements respectively, e.g.
<HEAD>
<ISINDEX>
<LINK REL="Next" HREF="...">
etc.
</HEAD>
<BODY>
body elements go here
</BODY>
This element is used to define the title of the current document. and is often used as the window banner for window-based displays. There may be only one title in any node, and it should identify the content of the node in a fairly wide context. No markup is permitted within title text, although character entity references may be used for accented characters etc.
URL?word+word+word
This mechanism has to a large extent been superseded by the FORM element. There are still good reasons for keeping it in HTML+. In particular, when reading a long document, having the search field always visible, makes it much easier for people to enter search strings, than if they first had to scroll to the part of the document which included a search form.
The NEXTID element is used by browsers that automatically generate identifiers for anchor points. It specifies the next identifier to use, to avoid possible confusion with older (deleted) values, e.g. <nextid n="id56">. The identifier should take the form of zero or more letters followed by one or more digits. The numeric suffix should be incremented to generate successive identifiers.
The HREF attribute of the BASE element gives the full URL of the document, and is added by the browser when the user makes a local copy. Keeping the full URL is essential when subsequently viewing the copied document as it allows relative URLs to be resolved to their original references, e.g. <BASE HREF=URL>.
This provides a means of describing the relationship between this document and other documents, and has the same attributes as the <A> element (see section 5.2). A document can have multiple LINK elements. Typical uses are to indicate authorship, related indexes and glossaries, older or more recent versions etc. Another use is to indicate a stylesheet that contains the author's layout preferences, e.g. for headers and multi-columns displays. Links can also be used to indicate a static tree structure of documents with relationships such as "parent", "next" and "previous", e.g. <LINK HREF=URL REL="next">
The standard values for the REL attribute are (case insensitive):
<LINK IDREF="z36" REL="Sidebar" HREF="sidebar.html">
The IDREF attribute localizes the link to an element in the current document with a specific identifier (as defined with the ID attribute). In the absence of the IDREF attribute, the link is associated with the current document as a whole.
Other suggestions for LINK currently lie outside this proposal, pending further work. In some cases, LINK elements may be implied by the context in which this document was reached. This is explained in section 15.
Many classic works are available over the Internet, now that their copyright has expired. Downloading these as large documents is time consuming, and a better strategy is to split them up into smaller pieces. Other people have lots of paper documents and wish to make them available electronically. While it is easy to scan these documents in, the size of the images makes them tedious to transfer over the network. Once again, time can be saved by avoiding the need to download the whole document at once. HTML+ makes it easy to do this with explicit or implicit links between the pieces that make up the complete document.
A book might have the following pieces:
Generating a hypertext version of the index may prove time consuming, and it may be simpler to offer a full text search facility instead. The INDEX attribute can be used with many HTML+ elements to facilitate automatic generation of a conventional looking index, see section 13.
Implicit links are useful when you want to reuse a given subdocument in another independent book, and for non-HTML+ formats such as scanned page images. To define implicit links, you need to first create a HTML+ document such as a table of contents, and to make each entry into a hypertext link using the <A> element with the attribute REL="SUBDOCUMENT". When the user follows one of these links, the browser scans the current document to locate the next <A> element with the subdocument relationship. If it reaches the end of the document it looks for a LINK element with REL=NEXT. This procedure is used to imply a LINK element in the retrieved subdocument. A similar process is used to imply a LINK element with REL=PREVIOUS. The other links for the current document are simply inherited, i.e. any bookmarks, glossary or index links that hold for the table of contents, also hold for the subdocument.
The browser then retrieves the subdocument and merges the implied LINKs with any that are given explicitly. If the user now presses the "Next" button on the toolbar (or menu), the browser follows the implicit link to the next subdocument. The browser needs to look again at the parent document to find the new next subdocument. This mechanism is difficult to explain, but simple to write documents for. All that authors need to do, is to remember to include the subdocument relationship when defining hypertext links.
For a hundred page scanned document where each page is held as a separate file, the "table of contents" is going to be pretty dull, and there is little point creating it as an HTML+ node. Instead, you should use an HTTP server which passes the missing LINK elements as header fields for each page image. The suggested representation for these header fields uses the same attributes and syntax as the LINK element:
WWW-Link: REL="Next" HREF="http://info.cern.ch/...."
There could be several WWW-Link: headers, one for each implied LINK.
This idea puts the burden on the server to supply such links as
appropriate to each requested document.
I would like to thank the many people on the www-talk mailing list who have contributed to the design of HTML+ and to the management of HP Labs for their support during this work.
David Raggett, Hewlett Packard Laboratories, October 1993.
The HTML+ Document Type Definition (DTD). The preliminaries are taken from the HTML DTD and declares the character set as Latin-1, disables markup minimisation and sets limits for tag/attribute names to 34 characters, and attribute values to a maximum of 1024 characters.
<!SGML "ISO 8879:1986" -- Document Type Definition for the HyperText Markup Language Plus for use with the World Wide Web application (HTML+ DTD). These initial settings are take from the HTML DTD.NOTE: This is a definition of HTML with respect to SGML, and assumes an understanding of SGML terms. -- CHARSET BASESET "ISO 646:1983//CHARSET International Reference Version (IRV)//ESC 2/5 4/0" DESCSET 0 9 UNUSED 9 2 9 11 2 UNUSED 13 1 13 14 18 UNUSED 32 95 32 127 1 UNUSED BASESET "ISO Registration Number 100//CHARSET ECMA-94 Right Part of Latin Alphabet Nr. 1//ESC 2/13 4/1" DESCSET 128 32 UNUSED 160 95 32 255 1 UNUSED
CAPACITY SGMLREF TOTALCAP 150000 GRPCAP 150000
SCOPE DOCUMENT SYNTAX SHUNCHAR CONTROLS 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 127 255 BASESET "ISO 646:1983//CHARSET International Reference Version (IRV)//ESC 2/5 4/0" DESCSET 0 128 0 FUNCTION RE 13 RS 10 SPACE 32 TAB SEPCHAR 9 NAMING LCNMSTRT "" UCNMSTRT "" LCNMCHAR ".-" UCNMCHAR ".-" NAMECASE GENERAL YES ENTITY NO DELIM GENERAL SGMLREF SHORTREF SGMLREF NAMES SGMLREF QUANTITY SGMLREF NAMELEN 34 TAGLVL 100 LITLEN 1024 GRPGTCNT 150 GRPCNT 64
FEATURES MINIMIZE DATATAG NO OMITTAG NO RANK NO SHORTTAG NO LINK SIMPLE NO IMPLICIT NO EXPLICIT NO OTHER CONCUR NO SUBDOC NO FORMAL YES APPINFO NONE > <!DOCTYPE HTMLPLUS [ <!-- DTD for HTML+ Markup minimisation should be avoided, otherwise the default <!SGML> declaration is fine. Browsers should be forgiving of markup errors.
Common Attributes:
id the id attribute allows authors to name elements such as headers and paragraphs as potential destinations for links. Note that links don't specify points, but rather extended objects. index allows authors to specify how given headers etc should be indexed as primary or secondary keys, where "/" separates primary from secondary keys, ";" separates multiple entries --> <!-- ENTITY DECLARATIONS <!ENTITY % foo "X | Y | Z"> is a macro definition for parameters and in subsequent statements, the string "%foo;" is expanded to "X | Y | Z"
Various classes of SGML text types:
#CDATA text which doesn't include markup or entity references #RCDATA text with entity references but no markup #PCDATA text occurring in a context in which markup and entity references may occur. --> <!ENTITY % URL "CDATA" -- a URL or URN designating a hypertext node --> <!ENTITY % emph1 "I|B|U|S|SUP|SUB|TT"> <!ENTITY % emph2 "Q|CITE|PERSON|ACRONYM|ABBREV|EM|STRONG"> <!ENTITY % emph3 "CMD|ARG|KBD|VAR|DFN|CODE|SAMP|REMOVED|ADDED"> <!ENTITY % emph "%emph1;|%emph2;|%emph3;"> <!ENTITY % misc "RENDER|FOOTNOTE|MARGIN|INPUT|TEXTAREA|SELECT"> <!ENTITY % text "#PCDATA|A|IMG|IMAGE|%emph;|%misc;|BR|CHANGED"> <!ENTITY % paras "P|PRE|LIT|FIG"> <!ENTITY % lists "UL|OL|DL|MENU|DIR"> <!ENTITY % block "TABLE|FORM|MATH|NOTE|QUOTE|ABSTRACT|BYLINE|HR"> <!ENTITY % heading "H1|H2|H3|H4|H5|H6"> <!ENTITY % table "%text;|P|%heading;|%lists;"> <!ENTITY % math "BOX|%text;"> <!ENTITY % main "%heading;|%block;|%lists;|%paras;|%text;"> <!ENTITY % setup "(TITLE? & ISINDEX? & NEXTID? & LINK* & BASE?)">
<!-- Basic types of elements: <!ELEMENT tagname - - CONTENT> elements needing end tags <!ELEMENT tagname - O CONTENT> elements with optional end tags <!ELEMENT tagname - O EMPTY> elements without content or end tags
The content definition is: - an entity definition as defined above - a tagname - (brackets enclosing the above) These may be combined with the operators: A* A occurs zero or more times A+ A occurs one or more times A|B implies either A or B A? A occurs zero or one times A,B implies first A then B A&B either or both A and B (in either order) -->
<!ELEMENT HTMLPLUS O O ((HEAD, BODY) | ((%setup;), (%main;)*))> <!ATTLIST HTMLPLUS version CDATA #IMPLIED -- the HTML+ version number -- forms (on|off) on -- used to disable form filling -->
<!ELEMENT HEAD - - (%setup;) -- delimits document wide properties --> <!ELEMENT BODY - - (%main;)* -- delimits the document's body -->
<!-- Document title --> <!ELEMENT TITLE - - (#PCDATA | %emph;)+> <!ATTLIST TITLE id ID #IMPLIED -- link destination -- lang CDATA #IMPLIED -- ISO language abbreviation -- index CDATA #IMPLIED -- entries for index compilation -->
<!-- Document headers --> <!ELEMENT (%heading;) - - (#PCDATA | %emph;)+> <!ATTLIST (%heading;) id ID #IMPLIED -- defines link destination -- lang CDATA #IMPLIED -- ISO language abbreviation -- index CDATA #IMPLIED -- entries for index compilation -->
<!-- character emphasis --> <!ELEMENT (%emph;) - - (%text;)*> <!ATTLIST (%emph;) id ID #IMPLIED -- link destination -- lang CDATA #IMPLIED -- ISO language abbreviation -- index CDATA #IMPLIED -- entries for index compilation -->
<!ELEMENT (FOOTNOTE|MARGIN) - - (%text;)* -(FOOTNOTE|MARGIN)> <!ATTLIST (FOOTNOTE|MARGIN) id ID #IMPLIED -- link destination -- lang CDATA #IMPLIED -- ISO language abbreviation -- index CDATA #IMPLIED -- entries for index compilation -->
<!ELEMENT RENDER -O (EMPTY) -- how to render unknown elements --> <!ATTLIST RENDER tag CDATA #IMPLIED -- tag name -- style CDATA #IMPLIED -- comma separated list of styles -->
<!-- Paragraphs which act as containers for the following text --> <!ELEMENT P - O (L|%text;)+> <!ATTLIST P id ID #IMPLIED -- link destination -- align (left|indent|center|right|justify) left lang CDATA #IMPLIED -- ISO language abbreviation -- index CDATA #IMPLIED -- entries for index compilation --> <!ELEMENT L - O (%text;)+> <!ATTLIST L id ID #IMPLIED -- link destination -- align (left|indent|center|right|justify) left lang CDATA #IMPLIED -- ISO language abbreviation -- index CDATA #IMPLIED -- entries for index compilation -->
<!ELEMENT HR - O EMPTY -- Horizontal Rule --> <!ELEMENT BR - O EMPTY -- line break in normal text-->
<!ELEMENT PRE - - (TAB|%text;)+ -- preformatted fixed pitch text --> <!ATTLIST PRE id ID #IMPLIED -- link destination -- lang CDATA #IMPLIED -- ISO language abbreviation -- index CDATA #IMPLIED -- entries for index compilation -->
<!ELEMENT LIT - - (TAB|%text;)+ -- literal variable pitch text --> <!ATTLIST LIT id ID #IMPLIED -- link destination -- lang CDATA #IMPLIED -- ISO language abbreviation -- index CDATA #IMPLIED -- entries for index compilation --> <!ELEMENT TAB - O EMPTY -- tabs for imported text --> <!ATTLIST TAB at NUMBER #IMPLIED -- measured in widths of an M -- align (left|center|right|decimal) left -- tab alignment -->
<!ELEMENT QUOTE - - (P|%text;)* -- block quote --> <!ATTLIST QUOTE id ID #IMPLIED -- link destination -- lang CDATA #IMPLIED -- ISO language abbreviation -- index CDATA #IMPLIED -- entries for index compilation -->
<!ELEMENT ABSTRACT - - (P|%text;)* -- document summary --> <!ATTLIST ABSTRACT id ID #IMPLIED -- link destination -- lang CDATA #IMPLIED -- ISO language abbreviation -- index CDATA #IMPLIED -- entries for index compilation --> <!ELEMENT BYLINE - - (P|%text;)* -- info on author --> <!ATTLIST BYLINE id ID #IMPLIED -- link destination -- lang CDATA #IMPLIED -- ISO language abbreviation -- index CDATA #IMPLIED -- entries for index compilation --> <!ELEMENT NOTE - - (P|%text;)* -- admonishment --> <!ATTLIST NOTE id ID #IMPLIED -- link destination -- role CDATA #IMPLIED -- eg Tip, Note, Warning, or Error -- lang CDATA #IMPLIED -- ISO language abbreviation -- index CDATA #IMPLIED -- entries for index compilation -->
<!ELEMENT (ADDRESS|BLOCKQUOTE) - - (%text;|P)* -- needed by HTML -->
<!-- Lists which can be nested --> <!ELEMENT OL - - (LI | UL | OL)+ -- ordered list --> <!ATTLIST OL id ID #IMPLIED compact (compact) #IMPLIED lang CDATA #IMPLIED -- ISO language abbreviation -- index CDATA #IMPLIED -- entries for index compilation --> <!ELEMENT UL - - (LI | UL | OL)+ -- unordered list --> <!ATTLIST UL id ID #IMPLIED -- link destination -- compact (compact) #IMPLIED -- reduced interitem spacing -- plain (plain) #IMPLIED -- suppress bullets -- wrap (vert|horiz) vert -- multicolumn list wrap style -- lang CDATA #IMPLIED -- ISO language abbreviation -- index CDATA #IMPLIED -- entries for index compilation -->
<!-- List items for UL and OL lists --> <!ELEMENT LI - O (DL|P|%text;)+> <!ATTLIST LI id ID #IMPLIED src %URL; #IMPLIED -- icon for use in place of bullet -- lang CDATA #IMPLIED -- ISO language abbreviation -- index CDATA #IMPLIED -- entries for index compilation -->
<!ELEMENT MENU - - (LI)* -- plain single column list --> <!ATTLIST MENU id ID #IMPLIED lang CDATA #IMPLIED -- ISO language abbreviation -- index CDATA #IMPLIED -- entries for index compilation --> <!ELEMENT DIR - - (LI)* -- plain multi column list --> <!ATTLIST DIR id ID #IMPLIED lang CDATA #IMPLIED -- ISO language abbreviation -- index CDATA #IMPLIED -- entries for index compilation -->
<!-- Definition Lists (terms + definitions) --> <!ELEMENT DL - - (DT+,DD)+> <!ATTLIST DL id ID #IMPLIED compact (compact) #IMPLIED lang CDATA #IMPLIED -- ISO language abbreviation -- index CDATA #IMPLIED -- entries for index compilation -->
<!ELEMENT DT - O (%text;)+ -- term text -- > <!ELEMENT DD - O (P|UL|OL|DL|%text;)+ -- definition text -- > <!ATTLIST (DT|DD) id ID #IMPLIED lang CDATA #IMPLIED -- ISO language abbreviation -- index CDATA #IMPLIED -- entries for index compilation -->
<!ELEMENT CAPTION - - (%text;)+ -- table or figure caption --> <!ATTLIST CAPTION id ID #IMPLIED lang CDATA #IMPLIED -- ISO language abbreviation -- index CDATA #IMPLIED -- entries for index compilation -->
<!ELEMENT TABLE - - (CAPTION?, (TH|TD|TR)*) -- mixed headers & data --> <!ATTLIST TABLE id ID #IMPLIED border (border) #IMPLIED -- draw borders -- lang CDATA #IMPLIED -- ISO language abbreviation -- index CDATA #IMPLIED -- entries for index compilation -->
<!ELEMENT TH - O (%table;)* -- a header cell --> <!ATTLIST TH colspan NUMBER 1 -- columns spanned -- rowspan NUMBER 1 --. rows spanned -- align (left|center|right) center -- alignment in cell -- lang CDATA #IMPLIED -- ISO language abbreviation --> <!ELEMENT TD - O (%table;)* -- a data cell --> <!ATTLIST TD colspan NUMBER 1 -- columns spanned -- rowspan NUMBER 1 --. rows spanned -- align (left|center|right) center -- alignment in cell -- lang CDATA #IMPLIED -- ISO language abbreviation --> <!ELEMENT TR - O (EMPTY) -- row separator --> <!ATTLIST TR id ID #IMPLIED>
<!ELEMENT FORM - - (MH, (%main;)*) -(FORM) -- forms can't be nested --> <!ATTLIST FORM id ID #IMPLIED action %URL; #IMPLIED -- defaults for URL for current doc -- method CDATA #IMPLIED -- PUT, POST, DELETE etc. -- lang CDATA #IMPLIED -- ISO language abbreviation -- index CDATA #IMPLIED -- entries for index compilation -->
<!ELEMENT MH - - CDATA -- one or more RFC 822 header fields --> <!ATTLIST MH hidden (hidden) #IMPLIED -- hide mail headers from view -->
<!ELEMENT INPUT - O EMPTY> <!ATTLIST INPUT name CDATA #IMPLIED -- attribute name -- type CDATA #IMPLIED -- a wide variety of field types -- size CDATA #IMPLIED -- visible size of text fields -- min NUMBER #IMPLIED -- for range controls -- max NUMBER #IMPLIED -- for range controls or text fields -- value CDATA #IMPLIED -- attribute value (altered by user) -- checked (checked) #IMPLIED -- check boxes and radio buttons -- disabled (disabled) #IMPLIED -- if grayed out -- error (error) #IMPLIED -- if in error -- src %URL; #IMPLIED -- for certain fields e.g. IMAGEs -- align (top|middle|bottom) top -- for IMAGE fields only -- lang CDATA #IMPLIED -- ISO language abbreviation -->
<!ELEMENT TEXTAREA - - CDATA -- multi-line text fields --> <!ATTLIST TEXTAREA name CDATA #IMPLIED -- attribute name -- cols NUMBER #IMPLIED -- visible width in characters -- rows NUMBER #IMPLIED -- visible height in characters -- disabled (disabled) #IMPLIED -- if grayed out -- error (error) #IMPLIED -- if in error -- lang CDATA #IMPLIED -- ISO language abbreviation -->
<!ELEMENT SELECT - - (OPTION+) -- combo style selection lists --> <!ATTLIST SELECT name CDATA #IMPLIED -- attribute name -- several (several) #IMPLIED -- permits multiple selections -- error (error) #IMPLIED -- if in error -- lang CDATA #IMPLIED -- ISO language abbreviation -->
<!ELEMENT OPTION - - CDATA> <!ATTLIST OPTION selected (selected) #IMPLIED -- if initially selected -- disabled (disabled) #IMPLIED -- if grayed out -- lang CDATA #IMPLIED -- ISO language abbreviation -->
<!ELEMENT FIG - - (CAPTION?,(%text;)*)> <!ATTLIST FIG id ID #IMPLIED align (left|center|right|float) float -- position -- ismap (ismap) #IMPLIED -- server handles mouse clicks/drags -- src %URL; #IMPLIED -- link to image data -- index CDATA #IMPLIED -- entries for index compilation -- lang CDATA #IMPLIED -- ISO language abbreviation --> <!ELEMENT IMG - O EMPTY> <!ATTLIST IMG src %URL; #REQUIRED -- where to get image data -- align (top|middle|bottom) top -- top, middle or bottom -- seethru CDATA #IMPLIED -- for chromakey -- alt CDATA #IMPLIED -- description for text-only displays-- ismap (ismap) #IMPLIED -- send mouse clicks/drags to server--> <!ELEMENT IMAGE - - (A|%text;)*> <!ATTLIST IMAGE src %URL; #REQUIRED -- where to get image data -- align (top|middle|bottom) top -- top, middle or bottom -- seethru CDATA #IMPLIED -- for transparency -- ismap (ismap) #IMPLIED -- send mouse clicks/drags to server-- lang CDATA #IMPLIED -- ISO language abbreviation -->
<!-- proposal for representing formulae --> <!ELEMENT MATH - - (%math;)*> <!ATTLIST MATH id ID #IMPLIED> <!ELEMENT BOX - - ((%math;)*, OVER?, (%math;)*)> <!ELEMENT OVER - O EMPTY>
<!ELEMENT CHANGED - O EMPTY -- for change bars --> <!ATTLIST CHANGED -- one of id and idref is always required -- id ID #IMPLIED -- signals start of changes -- idref IDREF #IMPLIED -- signals end of changes -->
<!-- Hypertext Links from points within document nodes --> <!ELEMENT A - - (#PCDATA | IMG | EM | EMBED)*> <!ATTLIST A id ID #IMPLIED -- as target of link -- name CDATA #IMPLIED -- needed by HTML-- shape CDATA #IMPLIED -- points for shaped buttons -- href %URL; #IMPLIED -- destination node -- rel CDATA #IMPLIED -- forward relationship type -- rev CDATA #IMPLIED -- reverse relationship type -- methods CDATA #IMPLIED -- supported public methods -- effect CDATA #IMPLIED -- replace/new/overlay/embed -- print CDATA #IMPLIED -- reference/footnote/section -- title CDATA #IMPLIED -- when otherwise unavailable -- type CDATA #IMPLIED -- for presentation cues -- size NAMES #IMPLIED -- for progress cues -- lang CDATA #IMPLIED -- ISO language abbreviation --> <!-- Other kinds of relationships between documents --> <!ELEMENT LINK - O EMPTY>
<!ATTLIST LINK idref IDREF #IMPLIED -- starting point -- href %URL; #IMPLIED -- destination node -- rel CDATA #IMPLIED -- forward relationship type -- rev CDATA #IMPLIED -- reverse relationship type -- methods CDATA #IMPLIED -- supported public methods -->
<!-- Original document URL for resolving relative URLs --> <!ELEMENT BASE - O EMPTY> <!ATTLIST BASE HREF %URL; #IMPLIED>
<!-- Signifies the document's URL accepts queries --> <!ELEMENT ISINDEX - O (EMPTY)> <!ATTLIST ISINDEX href %URL; #IMPLIED -- defaults to document's URL -->
<!-- For use with autonumbering editors - don't reuse ids, allocate next one starting from this one --> <!ELEMENT NEXTID - O (EMPTY)> <!ATTLIST NEXTID N NAME #REQUIRED>
<!-- Mnemonic character entities for 8 bit ANSI Latin-1 ignore when using other character sets --> <!ENTITY iexcl "¡" -- inverted exclamation mark --> <!ENTITY cent "¡" -- cent sign --> <!ENTITY pound "£" -- pound sign --> <!ENTITY yen "¥" -- yen sign --> <!ENTITY brvbar "¦" -- broken vertical bar --> <!ENTITY sect "§" -- section sign --> <!ENTITY copy "©" -- copyright sign --> <!ENTITY laquo "«" -- angle quotation mark, left --> <!ENTITY raquo "»" -- angle quotation mark, right --> <!ENTITY not "¬" -- negation sign --> <!ENTITY reg "®" -- circled R registered sign --> <!ENTITY deg "°" -- degree sign --> <!ENTITY plusmn "±" -- plus or minus sign --> <!ENTITY sup2 "²" -- superscript 2 --> <!ENTITY sup3 "³" -- superscript 3 --> <!ENTITY micro "µ" -- micro sign --> <!ENTITY para "¶" -- paragraph sign --> <!ENTITY sup1 "¹" -- superscript 1 --> <!ENTITY middot "·" -- center dot --> <!ENTITY frac14 "¼" -- fraction 1/4 --> <!ENTITY frac12 "½" -- fraction 1/2 --> <!ENTITY iquest "¿" -- inverted question mark --> <!ENTITY frac34 "¾" -- fraction 3/4 --> <!ENTITY AElig "Æ" -- capital AE diphthong (ligature) --> <!ENTITY Aacute "Á" -- capital A, acute accent --> <!ENTITY Acirc "Â" -- capital A, circumflex accent --> <!ENTITY Agrave "À" -- capital A, grave accent --> <!ENTITY Aring "Å" -- capital A, ring --> <!ENTITY Atilde "Ã" -- capital A, tilde --> <!ENTITY Auml "Ä" -- capital A, dieresis or umlaut mark --> <!ENTITY Ccedil "Ç" -- capital C, cedilla --> <!ENTITY ETH "Ð" -- capital Eth, Icelandic --> <!ENTITY Eacute "É" -- capital E, acute accent --> <!ENTITY Ecirc "Ê" -- capital E, circumflex accent --> <!ENTITY Egrave "È" -- capital E, grave accent --> <!ENTITY Euml "Ë" -- capital E, dieresis or umlaut mark --> <!ENTITY Iacute "Í" -- capital I, acute accent --> <!ENTITY Icirc "Î" -- capital I, circumflex accent --> <!ENTITY Igrave "Ì" -- capital I, grave accent --> <!ENTITY Iuml "Ï" -- capital I, dieresis or umlaut mark --> <!ENTITY Ntilde "Ñ" -- capital N, tilde --> <!ENTITY Oacute "Ó" -- capital O, acute accent --> <!ENTITY Ocirc "Ô" -- capital O, circumflex accent --> <!ENTITY Ograve "Ò" -- capital O, grave accent --> <!ENTITY Oslash "Ø" -- capital O, slash --> <!ENTITY Otilde "Õ" -- capital O, tilde --> <!ENTITY Ouml "Ö" -- capital O, dieresis or umlaut mark --> <!ENTITY THORN "Þ" -- capital THORN, Icelandic --> <!ENTITY Uacute "Ú" -- capital U, acute accent --> <!ENTITY Ucirc "Û" -- capital U, circumflex accent --> <!ENTITY Ugrave "Ù" -- capital U, grave accent --> <!ENTITY Uuml "Ü" -- capital U, dieresis or umlaut mark --> <!ENTITY Yacute "Ý" -- capital Y, acute accent --> <!ENTITY aacute "á" -- small a, acute accent --> <!ENTITY acirc "â" -- small a, circumflex accent --> <!ENTITY aelig "æ" -- small ae diphthong (ligature) --> <!ENTITY agrave "à" -- small a, grave accent --> <!ENTITY amp "&" -- ampersand --> <!ENTITY aring "å" -- small a, ring --> <!ENTITY atilde "ã" -- small a, tilde --> <!ENTITY auml "ä" -- small a, dieresis or umlaut mark --> <!ENTITY ccedil "ç" -- small c, cedilla --> <!ENTITY eacute "é" -- small e, acute accent --> <!ENTITY ecirc "ê" -- small e, circumflex accent --> <!ENTITY egrave "è" -- small e, grave accent --> <!ENTITY eth "ð" -- small eth, Icelandic --> <!ENTITY euml "ë" -- small e, dieresis or umlaut mark --> <!ENTITY gt ">" -- greater than --> <!ENTITY iacute "í" -- small i, acute accent --> <!ENTITY icirc "î" -- small i, circumflex accent --> <!ENTITY igrave "ì" -- small i, grave accent --> <!ENTITY iuml "ï" -- small i, dieresis or umlaut mark --> <!ENTITY lt "<" -- less than --> <!ENTITY ntilde "ñ" -- small n, tilde --> <!ENTITY oacute "ó" -- small o, acute accent --> <!ENTITY ocirc "ô" -- small o, circumflex accent --> <!ENTITY ograve "ò" -- small o, grave accent --> <!ENTITY oslash "ø" -- small o, slash --> <!ENTITY otilde "õ" -- small o, tilde --> <!ENTITY ouml "ö" -- small o, dieresis or umlaut mark --> <!ENTITY szlig "ß" -- small sharp s, German (sz ligature) --> <!ENTITY thorn "þ" -- small thorn, Icelandic --> <!ENTITY uacute "ú" -- small u, acute accent --> <!ENTITY ucirc "û" -- small u, circumflex accent --> <!ENTITY ugrave "ù" -- small u, grave accent --> <!ENTITY uuml "ü" -- small u, dieresis or umlaut mark --> <!ENTITY yacute "ý" -- small y, acute accent --> <!ENTITY yuml "ÿ" -- small y, dieresis or umlaut mark -->
<!-- The END --> ]>
The proposed character entities for HTML+ and their corresponding character codes for Unicode and the Adobe Latin-1 & Symbol character sets.
[this table is only available in the <draft-raggett-www-html-00.ps> version]
Many thanks to Bob Stayton for volunteering his time and effort to prepare this table.
ANSI C Code for testing if a point lies within a polygon. This may be freely used provided the original copyright message is retained in full.
/* ** Reproduced with thanks from mapper 1.2 ** 7/26/93 Kevin Hughes, kevinh@pulua.hcc.hawaii.edu ** polygon code copyright 1992 by Eric Haines, erich@eye.com */
#include <stdio.h>
#define MAXLINE 500 #define MAXVERTS 100
#define X 0 #define Y 1
int pointinpoly(double point[2], double pgon[MAXVERTS][2]) {
int i, numverts, inside_flag, xflag0;
int crossings;
double *p, *stop;
double tx, ty, y;
for (i = 0; pgon[i][X] != -1 && i < MAXVERTS; i++)
;
numverts = i;
crossings = 0;
tx = point[X];
ty = point[Y];
y = pgon[numverts - 1][Y];
p = (double *) pgon + 1;
if ((y >= ty) != (*p >= ty))
{
if ((xflag0 = (pgon[numverts - 1][X] >= tx)) ==
(*(double *) pgon >= tx))
{
if (xflag0)
crossings++;
}
else
{
crossings += (pgon[numverts - 1][X] - (y - ty) *
(*(double *) pgon - pgon[numverts - 1][X]) /
(*p - y)) >= tx;
}
}
stop = pgon[numverts];
for (y = *p, p += 2; p < stop; y = *p, p += 2)
{
if (y >= ty)
{
while ((p < stop) && (*p >= ty))
p += 2;
if (p >= stop)
break;
if ((xflag0 = (*(p - 3) >= tx)) == (*(p - 1) >= tx))
{
if (xflag0)
crossings++;
}
else
{
crossings += (*(p - 3) - (*(p - 2) - ty) *
(*(p - 1) - *(p - 3)) / (*p - *(p - 2))) >= tx;
}
}
else
{
while ((p < stop) && (*p < ty))
p += 2;
if (p >= stop)
break;
if ((xflag0 = (*(p - 3) >= tx)) == (*(p - 1) >= tx))
{
if (xflag0)
crossings++;
}
else
{
crossings += (*(p - 3) - (*(p - 2) - ty) *
(*(p - 1) - *(p - 3)) / (*p - *(p - 2))) >= tx;
}
}
}
inside_flag = crossings & 0x01;
return (inside_flag);
}