Previous chapter Next chapter Table of Contents

© Martin Bryan 1997 from SGML and HTML Explained published by Addison Wesley Longman

Chapter 13
The HyperText Markup Language

The HTML document type definition (DTD) is the most common example of the use of SGML in electronic publishing. This chapter provides a detailed explanation of the roles of the elements provided in the strict variant of Version 4.0 of the HTML DTD that is shown in Chapter 12.

This chapter is split into the following sections:

The use of forms in an HTML environment is covered in the next chapter.

13.1 Identifying HTML DTD versions

Documents coded using the elements defined in strict variant of Version 4.0 of the HTML DTD should be preceded by a document type declaration of the following form:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
            "http://www.w3.org/TR/PR-html40/strict.dtd">

Note, however, that the inclusion of a fixed system identifier in this declaration requires a reference to be made to the version of the DTD stored at the W3C web site. This forced reference to a destination outside the authoring system may well lead to problems if on-line access is not possible, so it would be better if the system identifier were removed so that the document type definition reads:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">

Unfortunately this variant of the document type declaration fails to identify which variant of the DTD has been used to create the document, but as different public identifiers are provided for other variants of the DTD use of this short form can be deemed to refer to the strict variant.

Note: When the strict variant of the HTML 4.0 DTD is being used the <HTML> start-tag cannot be qualified by the version attribute used on earlier versions of HTML to identify the version of the DTD that applied to the file.

The optional <HTML> start-tag that follows the document type declaration can be assigned attributes that identify the language and writing direction that apply to the majority of the data in the document. In its fullest form the document start-tag could have the form:

<HTML lang="en-GB" dir="ltr">

Note: The codes used to identify languages within HTML documents must conform to the rules laid down in Internet RFC 1766, Tags for the Identification of Languages (http://ds.internic.net/rfc/rfc1766.txt)

Figure 13.1 provides a graphical illustration of the main structural elements of the HTML DTD. It should be noted, however, that this simplified tree diagram does not fully illustrate the recursive nature of the HTML DTD.

Simplified Tree of HTML DTD

Figure 13.1 Relationship of main structural elements in HTML 4.0 DTD

13.2 The HTML Header

Each HTML document can start with a <HEAD> element that has embedded within it:

The optional <HEAD> start-tag can be assigned lang and dir attributes if the information in the header is in a different language from that of the body of the document. In addition, a profile attribute can be used to identify a file containing all or part of the metadata that describes the document. In its fullest form the start-tag takes the form:

<HEAD lang="en-US" dir="ltr" profile="http://www.echo.lu/oii/en/profile.htm">

If the <head> start-tag is present, the header must contain a single title element, for which the start-tag (<TITLE>) and end-tag (</TITLE>) are compulsory. Text placed between these tags will be displayed by the browser as the window title, and will be used as the title of the file in any history or bookmark record. Like all other text containing HTML elements, the lang and dir attributes can be added to the start-tag to clearly identify the language and writing direction of the title.

Note: Titles must be specified in the local code set and should not, therefore, include SGML entity references to accented characters. To ensure that titles work in all environments they should be restricted to ASCII alphanumeric and basic punctuation characters.

If the anchors in the file are defined using relative URLs that reference files in a directory other than the one containing the current file, the referenced directory should be identified by entry of a start-tag of the form <BASE href="URI">, where URI is a fully resolved URL that identifies the directory containing the referenced files. The URI should always begin with a scheme specification, e.g. http:, and be followed by a network location, e.g. //www.echo.lu, and a pathname identifying a route to a directory at that location, e.g. /oii/en. A typical entry is <BASE href="http://www.echo.lu/oii/en">.

Note: Some browsers also require the addition of a filename component, but this is not part of the HTML specification.

The <BASE> element can also be assigned a target attribute whose value indicates the default frame to be used for displaying the contents of linked files. However, it should be noted that the use of frames is not supported by the strict variant fo the HTML 4.0 DTD as they cannot be used on all WWW browsers.

As the <BASE> element has been declared to be an EMPTY SGML element it can have no textual contents and, therefore, will have no end-tag.

Each <STYLE> element will normally contain information coded using the World Wide Web Consortium's (W3C) Cascading Style Sheet (CSS) specification for the formatting rules to be applied to the document. More than one set of style options can be provided in the header, either to provide alternative display styles or to apply different styles to different parts of the document.

The <SCRIPT> element allows ECMAScript, JavaScript, Visual Basic and related scripts to be used to control the way in which embedded HTML objects are presented to users.

Both the <STYLE> and <SCRIPT> elements use the CDATA keyword as their content model. This is intended to prevent users from embedding markup tags, or character sequences that could be mistaken for HTML markup tags, within the script or style sheet data. Use of this keyword means that the element finishes the first time the end-tag close (ETGC) delimiter (</) is encountered. The delimiter must be immediately followed by the name of the last element to be opened (STYLE or SCRIPT and a tag close (TAGC) delimiter.

A simple example of a Java script is:

<SCRIPT type="text/javascript">
// CursorOver() and OnClick() are functions used to display text
// in the status bar when the mouse is near a given link
function CursorOver ()
{	window.status="Click for more information" }
function OnClick ()
{	window.status="Please wait while we retrieve the relevant file" }
</SCRIPT>

As early browsers cannot process scripts, a <NOSCRIPT> element has been added to Version 4.0 of the HTML DTD to allow a textual alternative to a script defined within the body of a document to be defined. The <NOSCRIPT> element will normally be positioned immediately after the <SCRIPT> element it serves as a replacement for. For example, the following element could be defined as an alternative to the above script:

<NOSCRIPT>Please wait while we retrieve the relevant file.</NOSCRIPT>

Note: Details of the coding of styles and scripts is beyond the scope of this book. References to the formal specifications of ECMAScript and the W3C Cascading Style Sheets specifications are provided at the end of this chapter.

The <META> element can be used to assign meta-data to a file. Each <META> element sets up a name/value pair, defined using attributes called name and content, which contain information that can be used to identify or manage the file when it is stored within a filestore. Where the information defined is of a type normally transmitted in an HTTP message header the name of the equivalent HTTP field can be specified as the value of an http-equiv attribute in place of assigning a name to the property. Where the metadata is coded acccording to a formally defined scheme, such as the Dublin Core (DCORE) proposal, the scheme attribute can be used to identify where it is derived from. Examples of the use of meta-data include:

<META scheme="DCORE" name="Creator" content="Bryan, Martin">
<META scheme="DCORE" name="Publisher" content="The SGML Centre">
<META http-equiv="Expires" content="Fri, 08 Mar 1996 23:59:59 GMT">
<META http-equiv="Keywords" content="SGML,HTML" lang="en">

On some browsers the <META> element can also be used to set up what are known as client pull scenarios whereby calling a file automatically invokes the display of a second page after a specific period of time. For example, if the header contains the following <META> element:

<META http-equiv="refresh" content="120;URL=timeout.gif">

the browser will automatically switch to a timeout image 120 seconds after first displaying the page.

The <LINK> element allows pointers to other files to be stored as part of the header of a file. The <LINK> element is typically used to identify related indexes and glossaries, older and younger versions of the files, available translations and associated resources such as style sheets. As the <LINK> element has been declared to be an EMPTY element it has a start-tag but, unlike the <A> element used to identify anchors in the body of the text, can have no textual contents or end-tag. The following attributes can be associated with the <LINK> start-tag:

Note: The optional target attribute, used to identify which frame the linked data should be displayed in, should not be used with the strict version of the HTML 4.0 DTD, which does not support the use of frames.

Typical examples of the use of <BASE> and <LINK> elements include:

<BASE "http://www.myco.org/pub/subject/en/">
<LINK href="bibliography.html" title="Bibliography" rel=author rev=wrote media="print">
<LINK href="../sp/file234.html" title="Espanol" rel=alternate hreflang="es">
<LINK href="../fr/file234.html" title="Francais" rel=alternate hreflang="fr">
<LINK href="../de/file234.html" title="Deutsch" rel=alternate hreflang="de">
<LINK href="index.html" rel=index class=subject style="color: teal" type="text/html">

13.3 Text Blocks in the HTML Body

The header of each HTML file must be followed by one or more of the elements defined as valid text block elements, which can, optionally, be enclosed within a <BODY> element. The following attributes can be associated with the <BODY> element:

Note: With the strict variant of the HTML DTD you cannot specify a background image, or the colours to be used for text or links, which must be defined as part of style information.

A typical use of the attributes associated with the <BODY> element would be:

<BODY id=form-123 class=insure lang="en-GB" 
      onLoad="CheckSecurity()" onUnload="CheckContents()" >

When the %block; parameter entity, and the embedded %heading;, %list; and %preformatted; parameter entities have been expanded, the model for the <BODY> element becomes:

<!ELEMENT BODY O O (P | H1 | H2 | H3 | H4 | H5 | H6 | OL | UL | PRE |
                    DL | DIV | NOSCRIPT | BLOCKQUOTE | FORM |
                    HR | TABLE | FIELDSET | ADDRESS ) +(INS|DEL) >

Note: The coding of most of these elements will be covered in the following sections of this chapter. The role of the <FORM> and <FIELDSET> elements will be explained in the next chapter.

Note especially the inclusion exception, +(INS|DEL). By defining these element as inclusions, the model allows these elements to be used both between text blocks and within them to identify text that has been edited. The model for the INSert and DELete elements is:

<!ELEMENT (INS|DEL) - - (%flow;)*   -- inserted text, deleted text -->
<!ATTLIST (INS|DEL)
  %attrs                            -- %coreattrs, %i18n, %events --
  cite        %URL       #IMPLIED   -- info on reason for change --
  datetime    %DateTime; #IMPLIED   -- when changed: ISO date format -->

The cite attribute can be used to record the Unique Resource Locator (URL) of a document that explains the reason for the change. The datetime attribute can be used to record the time at which the insertion or deletion was made in the form of an ISO 8601 conformant date (using the YYYY-MM-DDThh:mm:ssTZD version of the date format). A typical example might be:

<P>In <ins cite="http://www.w3.org/TR/WD-html40-970708" datetime="1997-07-08T14:22:33+01:00">Version 4.0</ins><del cite="updates.htm" datetime="1997-07-08T14:22:33+01:00">Version 3.2</del> of the HTML DTD ...

13.3.1 Headings

Six levels of heading are defined by the %heading parameter entity, numbered from H1 to H6. The HTML DTD places no restrictions on the order in which these headings are used but does require that the user enter both a start-tag and an end-tag, e.g.</H1>, for each heading.

Note: Users expect authors to apply some logic to their selection of appropriate heading levels, but the DTD does not enforce the use of such logic.

Headings may contain the elements defined in the %inline parameter entity. These elements may also be included at any point within the body of the document. %inline is defined as:

<!ENTITY % inline "#PCDATA | %fontstyle | %phrase | %special | %formctrl">

The first keyword, #PCDATA, indicates that parsed character data (text) can be entered as the contents of elements using this parameter entity as their content model. Details of the use of elements that can be embedded within heading and other forms of text, as defined in the subsequent parameter entities, are provided in later sections of this chapter and, in the case of %formctrl, in the next chapter.

The start-tags for headings can be qualified by use of the generic attributes defined in the %attrs parameter entity. For example, to set a centered heading in a special (spot) colour you would enter the heading as:

<H1 id=MainHead style="color: blue alignment: center">Using Centered Headings</H1>

13.3.2 Space delimited text blocks (%block)

The definition of the %blocklevel parameter entity is:

<!ENTITY % block "P | %heading | %list | %preformatted | DL | DIV | NOSCRIPT |
                  BLOCKQUOTE | FORM | HR | TABLE | FIELDSET | ADDRESS" >

These elements create blocks of text that are normally separated from surrounding blocks by white space.

The paragraph element, <P>, is the main container for text within the body of an HTML-encoded file. Paragraphs may contain any of the elements identified by the %inline parameter entity.

A typical minimally coded HTML file has a heading containing just a title, followed by a body part consisting of a set of headings and associated paragraphs:

<HTML><HEAD><TITLE>HTML Example 1</TITLE>
<BODY lang="en-GB">
<H1>Using HTML</H1>
<P>This page gives readers some useful clues in the use of HTML.</P>
<H2>Creating Links To Other Files</H2>
<P>One of the most potent features of HTML is its ability to interconnect files.</P>

13.3.3 Lists

Only two forms of list are identified through the %list parameter entity in the strict variant of the HTML 4.0 DTD. Ordered (numbered) list, <OL>, and unordered (bulletted) list, <UL>, elements can be used to identify lists made up of one or more paragraphs of text. The elements indentified through %list; contain a sequence of one or more list items, <LI>, which can contain any of the elements identified by the %flow; parameter entity, which combines the elements in the %block parameter entity with those defined in the %inline; parameter entity. It should be noted that this model allows ordered and unordered lists to be nested to any level required.

The generic attributes identified by the %attrs parameter entity can be associated with all the items in a list by using them to qualify a <OL> or <UL> start-tag.

Note: When using the strict variant of the HTML 4.0 DTD users can no longer request that a list should be displayed in a compact format, without spacing between list items, by adding a compact attribute value to the start-tag of any list and are not permitted to use the type attribute to identify the type of bullet or number to be associated with each entry in the list. Control of the presentation of list items can now be achieved through the style attribute.

Note that, within HTML, lists cannot be embedded within paragraphs, but must always be treated as siblings of preceding and (non-nested) following paragraphs. This leads to a degree of illogicality in HTML documents, as the following example illustrates:

<HTML>
<HEAD><TITLE>HTML Example 2</TITLE>
<BODY lang="uk-GB">
<P>In this paragraph there is a list containing the following items:
<OL id=list-1 style="list-style-type: decimal">
<LI>A numbered list containing four items
<LI>An embedded alphabetically numbered list containing three subitems:
    <OL id=list-1-1 style="color: red list-style-type: lower-alpha">
    <LI>Subitem 1
    <LI>Subitem 2
    <LI>Subitem 3</OL>
<LI>An embedded unordered list that has square bullets:
    <UL id=list-1-2 style="color: blue list-style-type: square">
    <LI>bulleted item 1
    <LI>bulleted item 2
    <LI>bulleted item 3</UL>
<LI>A bulleted list with items that contain multiple paragraphs:
    <UL id=list-1-3 style="list-style-type: disc">
    <LI>This is a multiple paragraph list item.
        <P>This is the second paragraph of the first item
    <LI>This is the second item in the list, which does not have a second
        paragraph.</UL></OL>
<P>This is the second, and last, paragraph of the example.</BODY></HTML>

It should be noted that the indenting of the markup is purely to help users understand the nesting levels. It will be ignored by an HTML browser. It should also be noted that the last two end-tags are not compulsory, but have entered to clearly indicate the end of the example.

When this list is displayed on a browser it will appear as follows:

In this paragraph there is a list containing the following items:

  1. A numbered list containing four items
  2. An embedded alphabetically numbered list containing three subitems:
    1. Subitem 1
    2. Subitem 2
    3. Subitem 3
  3. An embedded unordered list that has square bullets:
    • bulleted item 1
    • bulleted item 2
    • bulleted item 3
  4. A bulleted list with items that contain multiple paragraphs:
    • This is a multiple paragraph list item.

      This is the second paragraph of the first item

    • This is the second item in the list, which does not have a second paragraph.

This is the second, and last, paragraph of the example.

Warning: It will be some time before most browsers support the Cascading Style Sheed version 2 options (first published on 4th November 1997) shown in the examples above.

As can be seen from the above example, the list that logically belongs with the first paragraph is formatted as a separate block, as is the embedded paragraph. This lack of context sensitivity often gives lists, and especially paragraphs within lists, a disconnected appearance.

A special kind of list, known as a definition list (<DL>), is provided for lists that consist of term/definition pairs. A definition list consists of a set of defined terms, <DT>, and their definitions, <DD>. The order in which these are entered is not controlled by the HTML DTD. Whilst defined terms can only be specified using the elements identified by the %inline; parameter entity, their definitions can include any of the elements defined in the %flow; parameter entity as well.

A typcial example of a definition list might contain the following entries:

<DL><DT>SGML</DT><DD>Standard Generalized Markup Language</DD>
<DT>HTML</DT><DD>HyperText Markup Language</DD></DL>

These would be presented by the browser as:

SGML
Standard Generalized Markup Language
HTML
HyperText Markup Language

13.3.4 Preformatted and quoted text

The %preformatted parameter entity within the definition of %block identifies elements in which line breaks are to be retained as entered. Only one type of preformatted element, <PRE>, is allowed in Version 4.0 of the HTML DTD.

The <PRE> element used to capture preformatted text can contain most forms of in-line text, but those textual elements which would require the use of smaller or larger characters, such as subscript or superscript characters, and images or other forms of embedded objects are specifically excluded. This restriction is necessary because preformatted text is normally displayed using a fixed width font that resembles the output of a typewriter, or a computer printout. The alignment of the displayed characters would, therefore, be affected if the size of the type changed, or arbitrarily shaped objects could be embedded within the text. Because <PRE> elements can have parsed character data (#PCDATA) they are permitted to contain entity references to accented characters, and to characters that would otherwise be treated as markup characters.

The <BLOCKQUOTE> element allows blocks of quoted text to be indented on the left and right, and separated from surrounding text blocks by white space. As the <BLOCKQUOTE> element can contain any element that can occur within the body of an HTML document it is very useful for showing examples of the presentation of HTML elements. When smaller pieces of text are to be inserted within a text block the quote element,<Q>, can be used. Both of these elements can be assigned a cite attribute whose value is the URL of the file from which the text is quoted, provided this is available on-line in addition to the normal of set of generic attributes identified by the %attrs parameter entity.

13.3.5 The <DIV>ison element

One problem with earlier HTML DTDs was that they provided no mechanism for identifying the relationship between headings and associated text. Because headings can be used in any order, and there is no constraint that any text be associated with a heading, there was scope for confusion, as the following example shows:

<HTML><HEAD><TITLE>HTML Example 4</TITLE>
<BODY>
<H1>Creating Chaos out of Order</H1>
<P>This example shows how easy it is to get paragraphs out of step with headings.</P>
<H2>Order, Order</H2>
<P>This paragraph is obviously associated with the preceding heading.</P>
<H3>An Example</H3>
<PRE>This is an example of HTML data</PRE>
<P>Is this paragraph part of the example, or does it belong with the
"Order, Order" heading?</P></BODY>

The <DIV> element, for which both the start-tag and end-tag must be present, can be used to clarify such situations, as the following example shows:

<HTML><HEAD><TITLE>HTML Example 5</TITLE>
<BODY><DIV>
<H1>Creating Chaos out of Order</H1>
<P>This example shows how easy it is to get paragraphs out of step with headings.</P>
<DIV>
<H2>Order, Order</H2>
<P>This paragraph is obviously associated with the preceding heading.</P>
<DIV><H3>An Example</H3>
<PRE>This is an example of HTML data</PRE></DIV>
<P>Is this paragraph part of the example, or does it belong with the 
"Order, Order" heading?</P></DIV></DIV></BODY>

The first of the </DIV> end-tags makes it clear that the example ends at the end of the preformatted block. The second </DIV> indicates that the division that began with the <H2> heading also includes the final paragraph. The last </DIV> closes down the division that shows the text associated with the main title of the document.

The <DIV> element is particularly useful for maintaining relationships within SGML-coded files that have been converted to HTML for tranmission over the WWW. In addition to allowing the normal generic attributes to be associated with all of its embedded elements the following link-related attributes can also be assigned to divisions:

Note: The use of these attributes is not adequately explained in the 11th November draft of the HTML 4.0 specification.

The following example shows how generic attributes can be used to qualify divisions:

<HTML><HEAD><TITLE>HTML Example 6</TITLE>
<BODY lang=en-uk><DIV class=Chapter id=Ex6-1 align=left>
<H1>Creating Chaos out of Order</H1>
<P>This example shows how easy it is to get paragraphs out of step with headings.</P>
<DIV class=Section id=Ex6-1-1>
<H2>Order, Order</H2>
<P>This paragraph is obviously associated with the preceding heading.</P>
<DIV class=Example id=Ex6-Ex1 style="alignment: center"><H3>An Example</H3>
<PRE>This is an example of HTML data</PRE></DIV>
<P>Is this paragraph part of the example, or does it belong with the
"Order, Order" heading?</P></DIV></DIV></BODY>

In this case the heading for the example, and the example itself, will be centred, the rest of the text having the default left alignment.

This example would be displayed as:

Creating Chaos out of Order

This example shows how easy it is to get paragraphs out of step with headings.

Order, Order

This paragraph is obviously associated with the preceding heading.

An Example

This is an example of HTML data

Is this paragraph part of the example, or does it belong with the "Order, Order" heading?

13.3.6 Other elements defined as blocks

Horizontal rules, <HR>, can only be inserted between text blocks, not within them. This means that they cannot, for example, be placed between the items in a list. The following attributes can be associated with a rule:

In practice only the style and class attributes are likely to be regurarly used, along the following lines: <HR style="alignment: center noshade height: 4px width: 50%"> or <HR class="halfwidth">.

The <ADDRESS> element should be used to enter addresses and related information. Addresses may consist of the elements identified by the %inline parameter entity. Addresses are typically displayed in italic with a left indent. An address would typically be encoded as:

<ADDRESS>Martin Bryan<BR>
The SGML Centre<BR>
29 Oldbury Orchard<BR>
Churchdown<BR>
Glos. GL3 2PU<BR>
U.K.</ADDRESS>

and displayed as:

Martin Bryan
The SGML Centre
29 Oldbury Orchard
Churchdown
Glos. GL3 2PU
U.K.

13.4 Embedded Text

The elements covered in this section may be embedded within text contained within paragraphs and other text containing elements whose model includes the %inline parameter entity. When the parameter entities referenced in the model provided in the %inline parameter entity are expanded you end up with a content model of the form:

( #PCDATA | TT | I | B | BIG | SMALL | EM | STRONG | DFN |
  CODE | SAMP | KBD | VAR | CITE | ABBR | Q | SUB | SUP |
  A | IMG | MAP | OBJECT | BR | SCRIPT | SPAN | BDO |
  INPUT | SELECT | TEXTAREA | LABEL | BUTTON )

Except where otherwise stated, the model for the contents of these elements is defined using the %inline parameter entity, so each of the elements can be used recursively. For this reason it is essential that both start-tags and end-tags are entered for all embedded elements other than the empty tags for line breaks, <BR>, and images, <IMG>.

The #PCDATA at the start of the model group indicates that parsed character data can occur at any point in an element assigned this model. If a line break is required at a particular point in a line a <BR> start-tag can be entered. This element has been defined as an empty element so must contain no content and have no end-tag. The <BR> element can have the core attributes (id, class, style and title) associated with it.

The emphasis, <EM>, element, or its font-based equivalent for the use of an italic typeface, <I>, can be used to highlight phrases within a paragraph. Where a stronger degree of emphasis is required the <STRONG> element, or its font-based equivalent for the use of a bold typeface, <B>, can be used. By embedding these elements inside one another you can produce strongly emphasized text, which will normally be displayed using bold italic characters.

References to book titles that are to be printed in italics should be marked up using the citation element, <CITE>. Version 4.0 of the HTML DTD has reintroduced a tag for defining new terms using the <DFN> element, and added a special element, <ABBR> for identifying abbreviations for which normal spell-checking rules should not be applied, or which speech synthesizers may need to handle in a special way. The generic attributes for defining the language (lang) and title can be used to control the way in which acronyms are presented to users verbally, as the following example shows:

<ABBR lang="fr" title="Société Nationale de Chemins de Fer">SNCF</ABBR>

Embedded quotations can be clearly identified using the new <Q> element.

Warning: Use of these last three elements, like that of all the elements that are new, will not be differentiated within older versions of HTML browsers.

To indicate that in-line text is to be presented using fixed width characters it can be marked up as computer code, <CODE>, sample text, <SAMP>, or keyboard characters, <KBD>. Alternatively the font-based equivalent for the use of a fixed width typewriter typeface, <TT>, can be used. Computer coding can also have components that are identified as a variable, <VAR>. This element is normally presented in italic.

Version 4.0 of the HTML DTD introduced two elements that are particularly important for those creating scientific texts:

The following example illustrates the use of the main textual elements in the HTML DTD. To emphasize that the end-tags for many text block elements are optional they have been omitted where appropriate.

<HTML><HEAD><TITLE>Using HTML Text Elements</TITLE>
<BASE href="http://www.echo.lu/icons">
<LINK href="mailto:mtbryan@sgml.u-net.com" rel=author>
<META http-equiv="Keywords" content="HTML, elements, examples">
<META name="Copyright" content="The SGML Centre">
<BODY>
<H4>Using HTML Text Elements</H4>
<P>Paragraphs can have <EM>emphasized</EM> and <I>italic</I> text, <STRONG>strongly
emphasized</STRONG> and <B>bold</B> text, and <EM><STRONG>both</STRONG></EM> options
to produce <B><I>bold italic</I></B> text.</P>
<P>In <CITE><ABBR lang="en" title="Standard Generalized Markup Language">SGML</ABBR> and <ABBR lang="en" title="HyperText Markup Language">HTML</ABBR> Explained</CITE> by Martin Bryan, you will find a
paragraph with <CODE>computer coding</CODE>, <SAMP>sample text</SAMP>, <KBD>keyboard
codes</KBD> and <VAR>variables</VAR> displayed, together with text presented using
the <TT>typewriter</TT> typeface.</P>
<P>For scientific text it is important to be able to enter <DFN>chemical
formulae</DFN> such as <BIG>H<SUB>2</SUB>O</BIG> and <DFN>mathematical
formulae</DFN> such as <SMALL>x<SUP>2</SUP></SMALL>.</P>
<HR>
<PRE>This is preformatted text.
The line breaks in it are those entered by the user.
It is often displayed using fixed width characters.</PRE>
<BLOCKQUOTE>
This is an example of a block quote containing, hopefully, an <Q>embedded
quote</Q>.
<P>
It contains two paragraphs of text.
</BLOCKQUOTE>
</HTML>

This file would be displayed as:

Using HTML Text Elements

Paragraphs can have emphasized and italic text, strongly emphasized and bold text, and both options to produce bold italic text.

In SGML and HTML Explained by Martin Bryan, you will find a paragraph with computer coding, sample text, keyboard codes and variables displayed, together with text presented using the typewriter typeface.

For scientific text it is important to be able to enter chemical formulae such as H2O and mathematical formulae such as x2.

This is preformatted text.
The line breaks in it are those entered by the user
It is often displayed using fixed width character

This is an example of a block quote containing, hopefully, an embedded quote.

It contains two paragraphs of text.

Warning: Do not be surprised if your browser does not display abbreviations and quoted text correctly as only the latest versions of WWW browsers will be able to process the new elements introduced by the experimental DTD.

Where a specific style, as defined in a specification defined in a styleattribute, is to be applied to a contiguous sequence of in-line text elements, the elements can be enclosed within an <SPAN> element. This element can also be used to associate a unique identifier (id), an element class (class) or language (lang) and writing direction (dir) specifications with a sequence of text and embedded in-line elements.

Note: Quite why a span can be treated as a linked element in the strict variant fo the HTML 4.0 DTD eludes me, no explanation of this behaviour being provided in the accompanying text.

Where embedded text is in a language other than that specified for the enclosing element the Bidirectional Over-ride, <BDO>, element can be used to identify text for which the containing element's writing direction is to be changed. For the <BDO> element the dir attribute is compulsory. Its value must be either ltr it the text is to be presented from left-to-right on the screen, or rtl it the text is to be presented from right-to-left. Optionally the language of the text can be speficied using the lang attribute.

13.5 The Role of HTML Anchors

The most important of the embedded elements in the HTML DTD is the anchor element, <A>. Anchors are used to name points within a file that other documents can point to, and to identify hotspots within the text that users can click on to move to another part of the same file, or to open another file.

The definition of the anchor element in the strict variant of Version 4.0 of the HTML DTD is:

<!ELEMENT A - - (%inline;)* -(A) -- anchor -->
<!ATTLIST A
  %attrs;                          -- %coreattrs, %i18n, %events --
  charset     %Charset;   #IMPLIED -- char encoding of linked resource --
  type      %ContentType; #IMPLIED -- advisory content type --
  name         CDATA      #IMPLIED -- named link end --
  href        %URL;       #IMPLIED -- URL for linked resource --
  hreflang %LanguageCode; #IMPLIED -- language code --
  target   %FrameTarget;  #IMPLIED -- render in this frame --
  rel         %LinkTypes; #IMPLIED -- forward link types --
  rev         %LinkTypes; #IMPLIED -- reverse link types --
  accesskey   %Character; #IMPLIED -- accessibility key character --
  shape       %Shape;     rect     -- for use with OBJECT SHAPES --
  coords      %Coords;    #IMPLIED -- for use with OBJECT SHAPES --
  tabindex     NUMBER     #IMPLIED -- position in tabbing order --
  onfocus     %Script;    #IMPLIED -- the element got the focus --
  onblur      %Script;    #IMPLIED -- the element lost the focus --
  >

The content model for the anchor element shows that it can contain any of the elements defined in the %inline parameter entity, including parsed character data. An anchor cannot, however, contain headings, paragraphs or other blocks of text, or nested anchors, as the exclusion definition at the end of the declaration makes clear.

Note: Many HTML browsers do not enforce this exclusion, or the rules about not nesting text blocks, as many existing HTML files ignore these rules.

While the contents of a division, and individual paragraphs, lists, etc., that have been assigned an SGML unique identifier, id, can be pointed to by an HTML anchor, no mechanism is provided for identifying arbitrary sets of text blocks within HTML.

To name part of a text block so that it can be pointed to from elsewhere in a document the text should be placed within an anchor element assigned either a name attribute or a unique identifier, id. As the name attribute is defined using the CDATA keyword, SGML places no restrictions on the lengths of anchor names, and permits them to contain spaces. The rules for URLs, however, do not permit spaces, requiring that any spaces in the string be replaced by %20 to indicate the hexadecimal value of the space code. When an id is used this must conform to the SGML's rules on the contents of name characters, which cannot include a %, and must conform to HTML's name length limits.

A named anchor would typically have the form:

<P>The role of <A name="anchors">HTML anchors</A>...

To reference a named anchor from elsewhere in the same file requires the use of an anchor with a URL fragment identifier as the value of its href attribute, e.g.

... in the section on <A href="#Anchors">The Role of the A Element</A>.

Note that the name must, in this case, be preceded by a # symbol to identify it as an IETF fragment identifier. As this character is not part of the standard set of SGML name characters the href attribute has also been declared as containing character data (CDATA), rather than a name, in the definition for the %URL parameter entity.

Note: The HTML anchor element does not use the SGML ID/IDREF mechanism to identify and reference elements. There is, therefore, no way of confirming that a reference to an HTML fragment identifier within the same document is a valid one.

To reference data in another file stored in the same directory as the file containing the reference the relevant file name can be entered as the value of the href attribute, e.g.

... shown in <A href="annex-a.html">Annex A</A>.

Where the referenced file is an HTML file that contains named anchors the relevant anchor name can be entered as a fragment identifier after the file name, e.g.

... shown in <A href="chapter5.html#clause5-2">Clause 5.2</A>.

Where the referenced file is stored in a directory which is a subdirectory of the parent directory of the directory containing the referenced file, the relevant directory can be specified using a relative path of the form:

... provide the text in <A href="../sp/file134.html">Spanish</A>.

WARNING: It is important that PC users note that URLs require that the divider between the directory name and the file name is a Unix-conformant forward slash, rather than a PC-conformant backward slash. Macintosh users should take care not to use colons in file or directory names. When referencing files on VMS systems care must be taken to avoid the use of square brackets or periods within file and path names.

Where the text is held in another directory of the same file server, the full path name of the relevant directory can be specified, e.g.

... in <A href="/pub/1995/statement-13-04">our earlier statement</A>.

Where the document is stored on another system the URL should start with scheme and network location identifiers, e.g.

... as described by Bryan in
<A href="http://www.sgml.u-net.com/book/sgml-10.htm#LINK">
<CITE>Using Multiple SGML Document Structures</CITE></A>.

Other schemes, such as anonymous FTP or Gopher, can also be used to request the transmission of files. When the requested files are not coded in HTML there should not be a fragment identifier at the end of the URL as these can only be identified within HTML documents. Typical examples of this anchors calling non-HTML documents include:

... in <A href="ftp://ftp.cwi.nl/pub/audio/AudioFormats.part1">Part 1</A> and
<A href="gopher://kupe.itu.ch:70/11/.1/itudoc/public/gophermenus/.1/.itu-t/
.rec/.x/.x200-499/.22320">ITU X.400</A>.

Anchors share the following optional attributes with the <LINK> element:

In addition the Version 4.0 DTD introuduces the following new optional attributes for anchors:

The intrinsic event generic attributes defined in the %events; parameter entity are typically applied to HTML anchors and other forms of hot spots. The options that are apporpriate for anchors are:

Note:. Browsers that support the use of these attributes will not be commonly available before the end of 1997.

Two additional control attributes can also associated with anchors:

Note: These attributes have traditionally be used only for the active components of forms, where users are permitted to use the Tab key to move from field to field. Their association with anchors is rather dubious, as is indicated by the fact that their description in the specification fails to recognize their use in conjunction with anchors. The relationships between onfocus and onmouseover and onblur and onmouseout are unclear.

Using the commonly available attributes, anchors can be extended to have the following form:

<a name         = "InternetProtocols"
   title        = "Internet Communication Protocols"
   href         = "http://www.echo.lu/oii/en/net.html"
   rel          = "Background"
   onmouseover  = "CursorOver()"
   onclick      = "OnClick()">CLICK HERE</a>

To see the effect of this link when browsing this chapter using an HTML browser place your cursor on "CLICK HERE".

13.5.1 Link relationships

The latest version of the HTML 4.0 Specification does not say much about the use of the rel and rev attributes (and what it does say tends to be self-contradictory). Earlier versions of the specification have suggested the following possible values for the rel and rev attributes associated with anchors and links:

13.5.2 Link Management in an HTML Environment

Whilst the <A> element is the most important element in the HTML DTD it is also the one that leads to the most problems as systems are normally unable to validate, or otherwise manage, entered URLs. It is, therefore, important to develop strategies for testing the currency of links created between documents within a managed set, and between locally controlled documents and external data sources.

If you can afford the time, and have suitably-trained staff, the safest method of checking links from anchors is by traversing them and checking that the results are as expected. This latter can be a problem if the staff concerned do not fully understand the role of the link as it is possible that the anchor or file pointed to does exist, but no longer points to the data originally being linked to because someone has changed the contents of the referenced file. (HTML anchors provide no mechanism for recording the creation date/time of the version of the file being used when the link was created.)

It is generally a fairly simple matter to write a program that can check the validity of anchors whose addresses reference local data sources. Normally this will involve splitting the anchor at the # symbol, if it is present, and checking that the data to the left of the symbol is a valid filename on the local system and that the data to the right of the symbol identifies an anchor that has been named within the referenced document.

Checking the validity of data stored on other systems is a much more complicated affair, and yet is the area in which errors are most likely to occur. In general those creating links to files have no control over their contents, or where, or for how long, they will be stored at the identified location. To check that a referenced file is still available over the network the checking program must issue a request for the file. If the file is not immediately available one of the following HTTP status messages is likely to be returned by the HTTP server:

Whilst the first 8 of these messages suggest that the file being referenced no longer exists at the specified location, or is now only available to a known set of subscribers, the other error messages simply indicate that it has not been possible to access the file for the time being. With the exception of message 502, most of these errors could be removed by requesting the file at a later time, perhaps using a different configuration.

Checking the validity of fragment identifiers within externally stored files is much more difficult than checking those within locally held files as the fragment identifiers can only be checked by requesting the file, storing it locally and then processing the fragment identifiers using the programs created for checking fragment identifiers in local files. This process is, of course, entirely dependent on being able to obtain access to the requested files. Correction of any errors, however, can only be done at the end of the calling anchor as it is not possible to correct retrieved files and then update their source.

13.6 Images and Maps

If an image is to be embedded within text, or entered as a component of the body of the text between paragraphs, it must be specified just as a start-tag because the <IMG> element is declared as being an EMPTY element. The attributes that can be associated with images in Version 4.0 of the DTD are:

It should be noted that any caption assigned to an image through a title attribute may not be displayable by older browsers. For this reason captions for images are often entered as separate paragraphs of text, which can contain embedded markup to emphsize text, etc.

If the ismap attribute is present the image must be embedded within an <A> element whose href attribute identifies a server-based program that can process a CGI search query for image maps. This construct represents a set of hyperlinks. When the user clicks on a pixel of an image that has been identified as a server-side image map by addition of the ismap attribute value, the browser computes the URL of the file identified by the containing anchor, appends a ? to this, and then adds the x and y coordinates of the pixel. This query is then sent to the server's search program, which will normally return the contents of another file for presentation to the user.

Where support for client-side image maps is provided by the browser being used, a <MAP> element can be used to identify a set of active areas (hotspots) within each image. Each <MAP> element must be assigned a name that can be used to reference the map from an anchor in addition to the standard attributes for defining a unique identifier (id), class, style and title, and intrinsic events.

The <MAP> element contains a number of <AREA> elements, each of which identifies part of the image. The <AREA> element is an EMPTY element, so it has no contents or end-tag. It must, however, have one or more of the following attributes:

Where the shape attribute has the value of circle the coords attribute should contain three comma separated numbers. The first two numbers indicate the x and y coordinates of the circle's centre point with respect to the top left hand corner of the image, expressed as a number of pixels. The third number indicates the radius of the circle, expressed in pixels.

Where the shape attribute has the default value, rect, the coords attribute must have four comma separated numbers, which identify the x and y coordinates of the top left and bottom right corners of the rectangle required.

When the value of the shape attribute is poly the coords attribute will contain n pairs of comma separated x and y coordinate values, where n indicates the number of sides to the polygon.

To see the effect of these rules consider the following example:

<IMG src="oii-logo.gif" alt="OII Logo" usemap="#OII-map">
<MAP name="OII-map">
<AREA shape=circle coords="16,16,13" href="http://europa.eu.int"
      alt="About the European Union">
<AREA shape=rect coords="28,2,52,29"
      href="http://www.echo.lu/oii/en/oii-info.html"
      alt="About the Open Information Interchange initiative">
</MAP>

This example would appear on the screen as:

OII Logo About the European Union About the Open Information Interchange iniative

If you click on the circle of stars in the electronic version of the file you will be taken to the European Union's home page. If you click on either of the letter I components of the image you will be taken to the home page of the European Union's Open Information Interchange initiative.

13.7 Tables

The following elements and attributes are used for encoding tables when using the strict variant of the HTML 4.0 DTD:

The following file shows an example of an HTML table coded using the extended definitions provided by the new DTD:

<TABLE border="10" cellspacing="2" cellpadding=6 rules=groups frame=hsides>
<CAPTION>Relationship between HTML and other table models</CAPTION>
<THEAD><TR valign=bottom align=center><TH></TH>
<TH>HTML Tables</TH>
<TH>US CALS Tables</TH>
<TH>Swedish CALS Tables</TH>
<TH>ISO 12083 Tables</TH></TR>
<TBODY>
<TR align=center valign=middle>
<TH align=left>Outermost element</TH>
<TD COLSPAN="2">&lt;TABLE&gt;</TD>
<TD>&lt;TABELL&gt;</TD>
<TD>&lt;TBL&gt;</TD></TR>
<TR align=center valign=middle>
<TH align=left>Table header element</TH>
<TD COLSPAN="2">&lt;THEAD&gt;</TD>
<TD>&lt;KOLHUVUD&gt;</TD>
<TD>&lt;TH&gt;</TD></TR>
<TR align=center valign=middle>
<TH align=left>Table body identifier</TH>
<TD COLSPAN="2">&lt;TBODY&gt;</TD>
<TD>&lt;TABELL.BLOCK&gt;</TD>
<TD>&lt;TBY&gt;</TD></TR>
<TR align=center valign=middle>
<TH align=left>Table row identifier</TH>
<TD>&lt;TR&gt;</TD>
<TD>&lt;ROW&gt;</TD>
<TD>&lt;RAD&gt;</TD>
<TD>&lt;ROW&gt;</TD></TR>
<TR align=center valign=middle>
<TH align=left>Table cell identifier</TH>
<TD>&lt;TH&gt; or &lt;TD&gt;</TD>
<TD>&lt;ENTRY&gt;</TD>
<TD>&lt;CELL&gt;</TD>
<TD>&lt;C&gt;</TD></TR></TABLE>

This table could be presented by an HTML browser as:

Relationship between HTML and other table models
HTML Tables US CALS Tables Swedish CALS Tables ISO 12083 Tables
Outermost element <TABLE> <TABELL> <TBL>
Table header element <THEAD> <KOLHUVUD> <TH>
Table body identifier <TBODY> <TABELL.BLOCK> <TBY>
Table row identifier <TR> <ROW> <RAD> <ROW>
Table cell identifier <TH> or <TD> <ENTRY> <CELL> <C>

Note: The current model for tables also satisfies the older model, which only allowed for captions and table rows because all of the other elements are omissible.

13.8 Objects

For the strict variant of HTML 4.0 the new <OBJECT> element, which works with both Java and other program control languages such as Microsoft's ActiveX OLE-compliant services, replaces the old Java-specific <APPLET> element.

The <PARAM> element is used to pass name/value pairs to the program identified by <OBJECT> elements. This empty element can have the following attributes associated with its start-tag:

The <OBJECT> element provides a set of attributes suitable for controlling a wide range of applications, including those coded using Java. The element can contain embedded parameter specifications,in the form of <PARAM> elements, and text that can replace the object if it cannot be processed locally. Any type of body content element can be used within the explanatory matter, including other objects that could form a suitable replacement for the one specified. The following attributes can be associated with the <OBJECT> element:

* Option likely not to be available in final recommendation.

The following example shows how an HTML <OBJECT> element could be used to rotate some displayed text:

<OBJECT classid="clsid:99B42120-6EC7-11CF-A6C7-00AA00A47DD2"	
id=twist1 width=170 height=200 vspace=0 align=center>
<param name="Angle" value="315">
<param name="Alignment" value="2">
<param name="BackStyle" value="0">
<param name="Caption" value="The SGML Centre">
<param name="FontName" value="Times New Roman">
<param name="FontItalic" value="1">
<param name="FontBold" value="1">
<param name="FontUnderline" value="1">
<param name="FontStrikeout" value="0">
<param name="FontSize" value="20">
</OBJECT>

This will be displayed as rotated text on a browser that does supports the <OBJECT> element or as a warning message on browsers that do not. Your browser displays it as:

Warning: This example will not show rotated text if your browser does not support the use of ActiveX or HTML Objects

References

Dublin Core Metadata Element Set Reference Description (http://purl.org/metadata/dublin_core_elements)

ECMA-262:ECMAScript: A general purpose, cross-platform programming language (http://www.ecma.ch/stand/ecma-262.htm)

HTML 4.0 Specification (W3C Proposed Recommendation, 7th November1997: http://www.w3.org/TR/PR-html40/)

Internet Draft Proposal, Cascading Style Sheets (http://www.w3.org/pub/WWW/TR/WD-css2.html)

Internet Draft Proposal, Proposed Extension to HTML : Client-Side Image Maps (http://ds.internic.net/internet-drafts/draft-seidman-clientsideimagemap-02.txt)

Internet RFC 2045, Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies (http://ds.internic.net/rfc/rfc2045.txt)

The Java Language Specification (http://java.sun.com/docs/books/jls/html/index.html)

JavaScript Authoring Guide (http://home.netscape.com/eng/mozilla/Gold/handbook/javascript/index.html)