IS-622 : Logical Markup and the HTML family of Markup Languages

Background

Long before the World-Wide Web came into existence (1990), and virtually at the same time that the Arpanet was created (1969), Charles Goldfarb both created the term "Markup Language" and invented SGML, the "Standard Generalised Markup Language" (itself based on GML, IBM's "Generalised Markup Language") on which the HyperText Markup Language HTML, the eXtensible Markup Language XML, and their bastard offspring the eXtensible HyperText Markup Language XHTML are all based. Although (for reasons which will shortly become clear) we will be concentrating today on HTML (and, in particular, on its most recent instantation in pure form, HTML 4.01), it is worth placing it in context by discussing the whole family of markup languages and – in particular – SGML, the language on which it is based.

From Author to the Printed Page

If we go back in time to a point where neither computers nor phototypesetters existed, but where typesetting (the production of printed material) was commonplace, an author, writing a book, would – almost without exception – have neither an interest in controlling how it should look when it appeared in print, nor (even if he/she did have some interest in the matter) any satisfactory means of communicating his/her wishes to the compositor – the person who would actually carry out the typesetting. Rather, the author would indicate – either through the use of visual clues/cues or through a pre-agreed system of annotation – the structure of the book (that is, the author would identify the parts, chapters, paragraphs, sentences, headings and so on), and the compositor – working from a specification supplied to him/her by the book designer (who worked for the publishing house) – would lay out the author's text according to the designer's specification. In so doing, the compositor would use one combination of font and font-size for the main text, either the same or a different font at a larger size for headings, and so on. In addition, he/she would ensure that all lines of text at a given size were separated by the same amount of vertical white space, that all paragraphs were uniformly indented, that no two consecutive lines were hyphenated, that no paragraph would either start or end with a single line and a page break, that no visual "rivers" interfered with the legibility of a page, and so on ; many other hallmarks of high-quality typesetting were similarly honoured. Indeed, compositing was such a skilled task (and the quality of the final book so dependent on the skill of the compositor) that good compositors were like gold-dust, and the very best could command high salaries indeed.

Computer-based Typesetting

Even when computers and photypesetters replaced traditional hot lead typesetting, authors still had little or no say in the final appearance of their prose; all publishing houses continued to employ book designers (as they still do, to this day), and the author's rôle was restricted to supplying the text and – as before – to indicating its underlying structure using visual clues/cues or a pre-agreed system of annotation. A few, however (and Professor Donald E. Knuth, of Stanford University, is without doubt foremost amongst these) realised that despite the apparent superiority of the equipment, the results were markedly inferior to those which had previously been achievable using considerably more primitive equipment. This was, in part, caused by the reduced involvement of the compositor, but was also caused by the equipment's potential not being anything like fully realised, as the software used to drive the phototypesetter was simply incapable of emulating the skill of a traditional compositor. Knuth, in particular, was so incensed by this deterioration in standards that he instructed his publishers not to go ahead with their planned reprint of one of his books, since he was determined that any reprint should at the very least be as least as pleasing to the eye as the original edition. He then devoted a not-inconsiderable portion of his life to designing and developing a typesetting system called T_EX, a font-design system called MetaFont, and some 70+ fonts, all with the single aim of ensuring that the second edition of "The Art of Computer Programming" should not be in any way inferior to the first !

T_EX

In T_EX, what Knuth actually designed and implemented was something that is both a programming language and a markup language : that is, within a single language, it was possible both to indicate the structure of a document and – at the same time – to indicate not only how that structure is to be mapped to a final printed form but also to indicate the necessary steps by which that mapping should be performed. Whether that was a wise decision remains debatable, but what is without doubt is that T_EX was so far ahead of any previous markup language for printed documents that its predecessors (Runoff, Roff, Nroff, Troff, Script, Scribe, ...) have virtually disappeared without trace.

HTML

Just over a decade after Knuth started working on T_EX, Tim Berners-Lee (generally acknowledged to be the inventor of the World-Wide Web) created the HyperText Markup Language HTML. Whereas T_EX was intended to facilitate the markup of text destined to become printed copy, HTML was intended to facilitate the markup of text destined to be displayed in a web "browser" (Mosaic was one of the first of these, but it has disappeared without trace and has been replaced by the ubiquitous -- if flawed -- Internet Explorer and its rivals Mozilla, Firefox, Seamonkey, Opera, Konqueror and their ilk). Whereas T_EX uses a leading backslash ("\") to indicate the start of a command, following the Runoff model which used a leading period (".") for the same purpose, HTML adopted the SGML reference syntax and used angle-brackets ("<" and ">") to indicate the start and end of a "tag". And whereas TeX used braces ("{" and "}") to restrict the range of the effect of a command (or to indicate the beginning and end of a parameter to a command), HTML followed the SGML model of indicating the beginning and end of an element using the "<tag> ... </tag>" notation.

T_EX & HTML Compared

But these syntactic differences were superficial : the fundamental difference between TeX and HTML is that TeX is a programming language that can be used for document markup, whilst HTML is a document markup language with no programming functionality whatsoever. What this means in practice is that HTML serves only to indicate the structure of the document in which it is used; a computer program (which is, in reality, a web browser) then interprets this markup and maps the structure onto a final, on-screen, form.

The Rôle of HTML

In his original design of HTML, Tim Berners-Lee stuck fairly rigorously to this distinction : he saw the rôle of HTML as being solely concerned with indicating a document's structure, and although he foresaw that those preparing web pages (as they were to become called) would want to have some influence over the documents final on-screen appearance (and thus he provided some low-level styling tags such as "<i>" (italics) and "<b>" (bold)), he was also quite purist in his approach and the result was therefore aimed primarily at document markup rather than document styling.

HTML Evolves

Sadly his purist intentions were soon forgotten : when Mosaic evolved to become Netscape, the Netscape team added many more styling tags to the once lean-and-mean HTML, and as Microsoft became involved through their creation of Internet Explorer, they too added yet more styling features to the language. By the time that HTML had evolved through HTML 2.0 and HTML 3.2, the original design goals were lost in the midst of time, and the language was bloated virtually beyond recognition.

Cascading Style Sheets (CSS)

In parallel with this, however, two key players were working quietly in the background. Håkon Wium Lie and Bert Bos, working within the ægis of the World-Wide Web Consortium, were quietly inventing something that would fundamentally alter the means by which web pages were styled. Rather than using HTML tags such as <font>, with its myriad parameters, Wium Lie and Bos proposed a quite different language, that of Cascading Style Sheets (CSS), which – if universally adopted and supported – would allow all of the styling elements to be removed from HTML, and thereby permit the latter to return to its primary rôle of document markup rather than document styling.

HTML & CSS : The Perfect Partnership

Despite the not-inconsiderable reluctance of the browser manufacturers to lose their much-loved styling extensions to HTML, the logic of CSS was unassailable, and by general agreement HTML 4.0 (soon to become HTML 4.01, when it was realised that the vital "name" attribute had been unintentionally lost from the "<img>" (image) element) replaced the earlier HTML 3.2, eliminating many of the styling features that had caused the latter to become so bloated. CSS is now universally supported in all modern browsers (admittedly some -- such as Mozilla -- do a better job of implementing it faithfully than do others such as Internet Explorer), and the web community as a whole are now united in their agreement that the combination of HTML and CSS is infinitely more powerful (as well as far more logical) than HTML on its own could ever have been.

XML

It would be nice to be able to stop here and declare that HTML 4.01 and CSS are the only two languages that one currently needs to know in order to write web pages that conform to the most recent standards, but sadly this is not the case. In 1996, the World Wide Web Consortium (W3C) began work on an eXtensible Markup Language (XML), and XML 1.0 was released on February 10, 1998. These developments stemmed from the computer industry's need to develop a simple yet extensible mechanism for the textual representation of structured and semi-structured information. The design inspiration for XML came from two main sources: Standard Generalized Markup Language (SGML) and HTML, both of which have already been mentioned, and the objectives were to jettison much of the baggage of SGML whilst at the same time creating a language that, unlike HTML, was not fixed but which could be extended to meet the needs of the user. And whilst the takeup for SGML was fairly limited, XML (perhaps because its time had come) was widely accepted with enthusiasm as the markup language, not only for today but for the future. Indeed, most document management systems now available, and many other document handling systems as well, use XML as the very basis of their existence.

XHTML

But just as SGML eventually led to HTML, so XML gave birth to XHTML (the eXtensible Hypertext Markup Language), and it is with XHTML that our problems really start. HTML, because of its simplicity, is universally accepted and understood by all web browsers; XHTML, on the other hand, whilst conceptually more elegant and more attractive, remains very much a niche product. Despite that fact that a very large number of web pages claim to be XHTML, most of these same pages are served in such a way that they appear to be HTML, even though the languages are not strictly interchangeable. And since this situation is so widespread, browser manufacturers are virtually forced to interpret these pages as if they were HTML, quietly bodging their way around the few subtle differences that would, if not concealed, cause the vast majority of these "XHTML served as HTML" pages to display incorrectly. And so we have a situation in which the World-Wide Web Consortium (the W3C) publically advocates the universal adoption of XHTML (and announce it, on their web site, as being the current instantation of HTML), whilst the more aware members of the web community maintain that HTML 4.01 is remains the language of choice (it is, without doubt, still the lingua franca of the web), that true support for XHTML is still far too scarce, and that XHTML, whilst undoubtedly a Good Idea [tm], is simply an idea for which the world is not yet ready ...

Markup

Document markup, and document markup languages, form such a fundamental rôle in successful web page creation that it is important that the concepts should be properly explained before we go on to consider HTML in detail. Consider the following

Semantic Markup : Describe what it is, not how it looks !

If you were asked to describe this document to someone else, what sort of language would you use ? Would you say (for example) that it consisted of a rectangle, with some lines of text at top-right, some more lines of text lower and to the left, a single line left aligned, a block of text fully justified, and three more lines left aligned ? Or would you say that it was basically a letter, starting with the address of the sender, then the name and address of the intended recipient, then an opening salutation, the body of the letter (consisting, in this case, of a single paragraph), a closing salutation, an "X" (the traditional mark for someone who is illiterate), and finally the name of the sender ? I would suggest (and it is only a suggestion, I may be wrong) that you would be more inclined to use the latter description than the former, since we are all used to describing the content of a document but are rarely (except in exceptional circumstances) expected to describe its appearance.

And so it is on the web : when we "mark up" a document, we use language that describes the content (the function, the rôle) of each element, rather than its (intended) physical appearance. We can later (if we wish) influence how the document should look (how it is to be rendered, to use the more technical term) by providing a style sheet that suggests the intended appearance of one or more elements, but this latter task can be thought of as the icing on the cake : for the cake to be edible, all that is necessary is to accurately describe its content and then to cook it (to display it in a browser).

Metanotions, abstractions, tags and tagging

How then to go about this task of marking up a document ? We'll start by introducing the concept of a metanotion, which you might like to think of as an abstraction. If we agree that metanotions are indicated as such by enclosing them in angle brackets ("<" and ">"), then we might say that the whole example is an instance of <Letter> (that is, in less formal English, "the example is a letter"). We might then break down <Letter> into its component parts : in the example above, <Letter> is composed of (in order of their appearance)

The syntax of HTML

In other words, each element of the document (including the document as a whole) is tagged ("marked up") by enclosing it in a pair of tags ("metanotions") that describe the semantics (the "meaning", the "significance", the "function", the "rôle") of the element so enclosed. (Note that the closing tag is identical to the opening tag, modulo the inclusion of a single forward slash "/" immediately after the opening angle-bracket). And whereas in our example above we have only two levels of nesting (the outermost <Letter> element, within which are a series of sub-elements <From-address> to <Signatory>), in real life the nesting is frequently considerably more complex than this, with (for example), <Body> being divided into a series of <Paragraphs> and so on. (As an aside, although many have argued that stopping at the level of <Paragraph> is inadequate, and at the very least tagging should continue down to the level of <Sentence>, if not <Word>, there is as yet little support for the idea, and it is highly unlikely to be adopted in the foreseeable future).

So now we understand the syntax of an HTML document, it is time to focus on the actual tags that can be used. Given that HTML is rarely if ever used for writing letters such as the example above ('though sadly it is frequently ab used in order to make e-mail messages unnecessarily ornate), it will (I hope) come as little suprise to you to learn that the tags we used in the example above are not the tags of which HTML is actually composed.

HTML tags and elements

In fact, although HTML contains some specialised tags, it is (as it was intended to be) more of a generalist language, with tags suitable for the vast majority of documents that are ultimately destined for the web. Just to give some simple examples, it includes headers (<H1> to <H6>, in decreasing order of importance), paragraphs (<P>) , lists (subdivided into unordered lists <UL> and ordered lists (<OL>), tables (<TABLE>), images (<IMG>)., and so on. And bearing in mind that the very essence of the web is that documents link to each other (that is, one can click on some text or an image in one document and be immediately transported to another document, possibly fetched from half way across the world), it should come as no surprise that HTML also includes an address element (<A> : this is formally termed an anchor element, but the term is so devoid of meaning that I invariably refer to it as an address element, even though there is a real address element with entirely different semantics) that lies at the very heart of document linking. Finally it is worth mentioning that the designers of HTML quite clearly foresaw that no matter how many tags were included, someone would always find an element that didn't quite sit comfortably in any of them, and therefore included two totally generic tags, division (<DIV>) and spanned region (<SPAN>) with no pre-ascribed semantics and which could therefore (in conjunction with the class attribute that will be discussed towards the end of the document) be used to tag any element for which a more descriptive tag did not exist.

In addition to these primary tags, there are a number of secondary tags that can occur only within one or more of the primaries. For example, within both unordered and ordered lists (<UL>, <OL>), each list item element must be tagged using list item tags (<LI>) ; and within tables, each row of the table forms a distinct element that must be tagged using table row tags (<TR>), within which there can occur both table header (<TH>) and table data (<TD>) elements.

Rather than enumerate all of the elements of HTML, I summarise them below in tabular form : those shewn in bold and/or red are those on which we will focus today; the remainder are either deprecated (grey italics), or are too specialised or too low-level to warrant more than a passing mention. Hyperlinks (in the online version !) are to the HTMLHELP web site from which the following table is derived.

The importance of nesting

Note that whenever two or more container elements are open simultaneously (in the last line, <P> is opened followed by <A>, and both lie within the outer <DIV>), it is essential to close them in the reverse order to that in which they were opened. That is, one must always write <DIV> ... <P> ... <A> ... </A> ... </P> ... </DIV>, and never <DIV> ... <P> ... <A> ... </DIV> ... </P> ... </A>; this is referred to as nesting, and containers must always be properly nested.

From page fragment to page

Now a confession is in order : the HTML shewn above is not complete. Although it forms a valid page fragment, it is not a valid page in its own right. A few additional tags/elements are required, as shewn below :

Let's work through the additions.

The page starts with a single line that is subtly different from all the rest : it starts "<!" rather than "<" or "</", and contains what is termed a DOCTYPE directive, the rôle of which is to indicate unambiguously in which dialect of HTML the document is written. All of our documents will start with a Doctype directive identical to the one shewn here, and will therefore conform to the most recent definition of HTML before XHTML was introduced (that is, HTML 4.01). In addition, the reference to "strict.dtd" indicates that our pages will use no deprecated elements (those shewn in grey italics in the table of HTML elements above).
Next comes the <HTML> tag, which with its matching </HTML> tag encloses the entire document apart from the Doctype directive.
Immediately following this occurs the <HEAD> tag, which is closed two lines later. The <HEAD> element itself is composed (in this example) of a single <TITLE> element (the closure is on the same line as the opening tag), and exactly one <TITLE> element is necessary and sufficient : it would be an error to have either no <TITLE> or two more more <TITLE>s. Other elements that can occur in the <HEAD> region (but which do not feature in this example) include <BASE>, <LINK>, <META><SCRIPT>, and <STYLE>. The contents of the <HEAD> region are never displayed in a browser, but the region plays a vital rôle nonetheless.
Following the closure of the <HEAD> element, the <BODY> element starts, and it should by now be apparent that the entire page fragment which was initially asserted to be the raw HTML for the example page forms, in fact, the contents of the <BODY> element. The <BODY> element is closed immediately prior to the closure of the <HTML> element (i.e., on the penultimate line).

Adding semantic value

The code shewn above is both necessary and sufficient for the creation of a complete and valid web page, but what may not yet be obvious is that the page would not look very much like the rendered example above. For example, the image would not be offset to the right, but would occur at the top left of the document, forcing everything else downwards. The various occurences of the Linnaean binomial Amanita muscaria would not be in italics (as they should : Linnaean binomials are always set in italics by long-established convention), and the various characteristics that are intended to assist the reader in identifying a fungus as being an instance of Amanita muscaria would not stand out by being set in red (nor would the common name be set in blue, or the distribution in green). To achieve these features (which are solely concerned with appearance and layout, and which have nothing to do with the structure of the document per se), we will need CSS (Cascading Style Sheets), but CSS is not discussed until next week. In the meantime, we can add markup to the document to denote which elements are Linnaean binomials, which are characteristics, which are distributions, which are common names and so on, but we cannot actually affect their appearance until we know a little about CSS. So here is the final example of document markup for this week, the new features of which are explained below.

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

<html>

<head>

<title>Amanita muscaria</title>

</head>

<body>

<div>

<h1><span class="Linnaean-binomial">Amanita muscaria</span></h1>

<h2>Brief description </h2>

<p><span class="Linnaean-binomial run-in">Amanita muscaria</span> is the common, bright red <span class="Common-name">fly agaric</span> of <span class="Distribution">northern Europe and Asia</span>. Its <span class="Characteristic">orange-red to scarlet cap</span> is 90 - 145 mm wide. The <span class="Characteristic">volva</span> is distributed over the cap as <span class="Characteristic">white or yellow warts</span>.</p>

<p>The <span class="Characteristic">gills</span> are <span class="Characteristic">free to narrowly adnate</span>, <span class="Characteristic">crowded to subcrowded</span>, and both in mass and in side view. The <span class="Characteristic">short gills</span> are <span class="Characteristic">truncate</span>.</p>

<p>The <span class="Characteristic">stipe</span> is <span class="Characteristic">60 - 210 x 8 - 22 mm</span> and has a <span class="Characteristic">skirt-like annulus</span> and <span class="Characteristic">notable bulb</span> of rather variable shape (up to <span class="Characteristic">46 x 45 mm</span>). <span class="Characteristic">Rings of volval materia</span>l commonly encircle the top of the bulb and the base of the stipe.</p>

<p>The <span class="Characteristic">spores</span> measure (7.4-) 8.5 - 11.5 (-13.1) x (5.6-) 6.5 - 8.5 (-9.8) µm and are <span class="Characteristic">broadly ellipsoid</span> (<span class="Characteristic">infrequently subglobose</span> or <span class="Characteristic">elongate</span>) and <span class="Characteristic">inamyloid</span>. <span class="Characteristic">Clamps</span> are very common at bases of basidia.</p>

<p>Photographic credits : Dan Lieberman <<a href="mailto:Dan@Iafrica.Com">Dan@IAfrica.Com</a>></p>

</div>

</body>

</html>

The <IMG ...> element now forms the content of an <A> element; it is therefore transformed into a hyperlink which, if clicked on, will take the reader to the page from which the photograph was taken. The address of the hyperlink appears as the value of the HREF attribute of the <A> tag.
The image is given inline styling that will cause it to (a) float the the right of other material, thereby avoiding wasting vertical white space, and (b) be set off by a small amount of horizontal white space from any material appearing to its left. This inline styling is, in fact, the first visible occurence of CSS, and further discussion thereof is deferred until next week.
All instances of Amanita muscaria are converted to <SPAN> elements, the CLASS attribute of which is set to "Linnaean-binomial". A CSS definition of "Linnaean-binomial" will later ensure that all Linnaean binomials are set in italics.
All identifying characteristics are converted to <SPAN> elements, the CLASS attribute of which is set to "Characteristic". A CSS definition of "Characteristic" will later ensure that all identifying characteristics are set in red.
The common name for Amanita muscaria ("fly agaric") is converted to a <SPAN> element, the CLASS attribute of which is set to "Common-name". A CSS definition of "Common-name" will later ensure that all common names are set in blue.
The distribution of Amanita muscaria is converted to a <SPAN> element, the CLASS attribute of which is set to "Distribution". A CSS definition of "Distribution" will later ensure that all distributions are set in green.

And that's it! There really is nothing more to the example than has now been explained, modulo the CSS that is necessary in order to accomplished the desired visual effects. Once you understand this example, and feel confident that you can use it as the basis for marking up web pages of your own, you will have made an excellent start as a web publisher : in Professor Knuth's own words, "go forth, and create masterpieces of the publishing art !"

Epilogue

Mention was earlier made of the importance of a page being valid ; that is, in fact, one of two criteria that must be met if you are genuinely to create masterpieces of the publishing art, the other being that of accessibility. Since neither of these criteria are particularly well understood (even less, widely practiced), it is worth going into them in some detail.

Validity

A web page is valid if it conforms 100% to the dialect of HTML specified in its DOCTYPE directive. As this is non-trivial to check by hand, it is best to make use of the W3C ("World-Wide Web Consortium") validation service at http://validator.w3.org/. Either visit this page and complete the form, or take advantage of the fact that the validator can access your document directly by invoking it through the rather more complex form http://validator.w3.org/check?uri=The URL of your web page. For example, this page has the URL http://training.rhul.ac.uk/Resources/Documentation/Web-publishing/IS-622/, and it can therefore be validated by invoking the validator through the address http://validator.w3.org/check?uri=http://training.rhul.ac.uk/Resources/Documentation/Web-publishing/IS-622/

The results of the validation exercise are simply "pass" or "fail"; it is not meaningful to think in terms of minor errors and major sins – a single error is sufficient for the page to fail validation. However, considerable thought has been given to ensuring that errors are reported in a meaningful and helpful way, so if you do find errors in a page that you have created, the validator should also provide quite good guidance as to how these might best be eliminated.

Accessibility

Far harder to define than validity is accessibility. For a web page to be accessible, it has to be capable of being comprehended by anyone who is reasonably fluent in the language in which it is written, regardless of whether they are blind, partially or normally sighted, regardless of whether they choose to view any embedded graphics, regardless of whether or not they have JavaScript and/or Java enabled, and so on. The page must even be accessible if they do not use a mouse! Needless to say, this criterion is far harder to codify than the criterion of validity, and it is probably true to say that it is a far harder criterion to meet, if every last detail of the accessibility requirements are to be observed. None the less, there are a few very simple rules which, if observed, will make your pages infinitely more accessible than most. These are :

Use semantic markup : select elements and choose class names that accurately describe the content to which they apply.
Never use an image where text will suffice
Never use an image without providing a brief textual description of it as the value of its ALT attribute
Never use a table to present non-tabular data (i.e., never use a table simply to implement layout)
Remember that some colour pairs are far less readily distinguished than others; red/green, for example, is poorly distinguished by about one in twenty of the population, so when specifying foreground and background colours (CSS, next week), choose colour pairs that provide a high contrast.
Remember that visual acuity diminishes with age : text that you can read at the age of twenty may appear a grey blur to someone of sixty or more. Ensure that the user can choose the size at which text is rendered, and do not display text at a size which could reasonably be expected to be unreadable by an older person.
If you use scripting (discussed in two weeks' time), use it only to add value to a page, never to provide fundamental functionality.

IS-622 : Logical Markup and the HTML family of Markup Languages

Background

From Author to the Printed Page

Computer-based Typesetting

T_EX

HTML

T_EX & HTML Compared

The Rôle of HTML

HTML Evolves

Cascading Style Sheets (CSS)

HTML & CSS : The Perfect Partnership

XML

XHTML

Markup

Semantic Markup : Describe what it is, not how it looks !

Metanotions, abstractions, tags and tagging

The syntax of HTML

HTML tags and elements

HTML in real-life use : a sample page

Amanita muscaria

Brief description

The page decomposed

The importance of nesting

From page fragment to page

Adding semantic value

Epilogue

Validity

Accessibility

IS-622 : Logical Markup and the HTML family of Markup Languages

Background

From Author to the Printed Page

Computer-based Typesetting

TEX

HTML

TEX & HTML Compared

The Rôle of HTML

HTML Evolves

Cascading Style Sheets (CSS)

HTML & CSS : The Perfect Partnership

XML

XHTML

Markup

Semantic Markup : Describe what it is, not how it looks !

Metanotions, abstractions, tags and tagging

The syntax of HTML

HTML tags and elements

HTML in real-life use : a sample page

Amanita muscaria

Brief description

The page decomposed

The importance of nesting

From page fragment to page

Adding semantic value

Epilogue

Validity

Accessibility

T_EX

T_EX & HTML Compared