Math in HTML (and CSS)

How to present math­emat­ical expressions using a language that has so little markup for them? You often need to resort to images, but if you need just some special symbols or simple ex­pressions, something could be done in HTML – perhaps assisted with style sheets (CSS).

The word “mathematical” is used in a rather broad sense here, covering different formalisms and symbols, including the symbols of physics, formal logic, etc. You might wish to take a look at Andreas Prilop’s nice document Mathematical formulas in HTML 4.0, which illustrates well what kinds of symbols and expressions are discussed here. And by looking at the HTML source there you can see how such things can be done.

What? No math?

Given the fact that HTML was originally developed at CERN, the European Laboratory for Particle Physics, it may sound odd that HTML has almost no markup for mathematical expressions and other special notations used in science. It’s not a surprise that you can’t do math in HTML; after all, it’s a markup language, not a programming language. But how are we expected to write physics reports or even modern biology papers without any mathematical notations?

There was once an HTML 3.0 draft, with a section titled HTML Math, suggesting relatively simple markup for some basic mathematics. But it’s all history; the draft expired in 1995. (There was also an earlier idea about HTML+, which would have had a different, more natural-looking math syntax.)

The modern trend is to regard things like mathematical markup as special “applications”, for which specialized languages are used; see W3C’s Math Home Page for information about such trends, including the MathML language. If you ask me, the language hopelessly mixes structure and appearance. For a more enthusiastic look at it, see the article MathML – What’s in it for us? by Janus Boye, and for a newer review of the situation, see The State of MathML : Mathematically Speaking (and Stuttering) by Pankaj Kamthan. But in any case, no matter what we think about it, MathML is not generally a practical solution on the Web at present; normal Web browsers don’t support it. For limited audiences which can be expected to have or to get suitable software, the MathML language perhaps would be useful, but I really can’t tell.

However, this does not mean that it would be impossible to write mathematical documents in HTML. There are difficulties and difficult decisions to be made. For relatively simple mathematical notations, HTML can be used rather well, especially if you use handle the toughest parts using images with adequate alt texts. See, for example, Stan Brown’s articles on math. Note that there’s the possibility of making an article available both in HTML format and in some other format, and this might be relatively easy if suitable tools can be found.

Alternative approaches – formats other than HTML

Thus, for documents where mathematical notations are needed a lot, other formats than HTML may turn out to be more practical. This might mean for example PDF, PostScript, or TeX format, or perhaps all of them, offered as alternatives. There are various other approaches, which may that require plugins; see Approaches to WWW Mathematics Documents by Ian Hutchinson. See also the link list Putting scientific articles on Web on the page Advanced CSS Rendering by George Chavchanidze.

The benefits of HTML in Web authoring are considerable, however, so it can be a tough decision. This document tries to help in making an informed decision as well as in implementing the HTML way, if that way is taken.

Even if you decide to publish your document in, say, PDF format only, you might still considering making its abstract available in HTML format too. Typically an abstract can be written with just a modest amount of mathematical notations. And the HTML version is not just universally accessible by people; it also “feeds” search engines, which help people to find your pages using keyword searches and for that purpose scan through the Web and index HTML documents (but generally skip PDF documents).

Avoiding the problem: simple linearized notation

Sometimes it is best to present mathematical expressions in linearized notation. For example, instead of trying to find a way of presenting the square root of 2 in the normal mathematical way, you might write just sqrt(2). For quotients, you’d use notations like (a+b)/(a-b). Instead of exponents you might use notations like a**b or a^b(a to the power b). It depends on intended audience whether you need to explain such notations, but normally you should explain any conventions that are not part of normal school mathematics.

Note that even in plain text, you can use the multiplication symbol × and do not need to resort to the asterisk (*) of computer jargon. See also other notes on using “normal” characters.

To indicate nesting of mathematical expressions, linearized notation uses parentheses. It is probably a good idea to use different types of parentheses, according to the usual mathematical convention: innermost, you use normal parentheses (); next level, you use square brackets []; and outermost you use curly braces {}. Example:

[ (x + y) ^ (1/3) ]  /z

A document containing such an expression should probably contain, near the beginning, a statement like “In this document, the circumflex character ^ is used to indicate exponentiation, i.e. raising to a power.”

Such an approach makes the document accessible to virtually all who have the necessary mathematical prerequisites, if you limit the character repertoire to ISO Latin 1. But naturally it’s a rather simplistic method. You might still consider using it as an alternative format, made available along with some more advanced but less accessible format(s), such as an image.

Formulas as images

Generating images from formulas

You can use some software, e.g. something TeX based (see also AMS TeX resources) or a mathematics program with graphic output format option, e.g. Mathematica, to produce visual representations of formulas as images. Often such software gives the result in PostScript format, but for Web use a GIF format is usually better, since it is much more widely supported in browsers by default. Various tools exist for converting from PostScript to GIF format. You could also consider using the Latex2HTML converter which can, among many other things, generate images in GIF format. (There’s another converter, TtH, which uses all kinds of tricks to convert mathematical expressions to HTML without using images. It applies very questionable methods like the Symbol font kludge. You might still get some useful ideas from its output and apply them more reasonably.)

Examples of using images

Such an approach is widely used on the Web. See, for example, the wonderful MathWorld pages. Note, by the way, than when you use mathematical terms, say binomial coefficient, on your page but cannot define all of them, it might be a very good idea to link to definitions and descriptions like those on MathWorld. Even if your terms are already known to 95 % of readers, you can give the 5 % a chance to find it out, and the others might need to brush up their knowledge too, or just check that the term really means what they think it does. See also Eric Weisstein’s Treasure Troves of Science collection, which is impressive, too, not only in content but also in the Web presentation of mathematical formulas. As regards to mathematics proper, e.g. S.O.S. MATHematics also has nice pages on several topics.

The technique: the img element

You would use the img element to embed an image into your document, and/or an a href element to create link to it. The latter method is often worth considering, especially for large formulas. The reader may prefer reading the text without distractions and looking at the formula (image) at the very moment he is prepared to do so. Moreover, he may prefer looking at it in a separate window (which is separately adjustable in size and positionable on the screen), or perhaps print it out (due to better resolution in print than on screen).

As a very simple example, I have used the simple markup
\int_{0}^{\infty}e^{x^2}dx
in TeX and generated a GIF image file from it, then just embedded the image into an HTML document using the following markup:

<p><strong>Assignment 42</strong>. Compute
<img src="integral.gif" align="middle" alt=
"the integral of exp(x**2) for x from 0 to infinity"></p>

This looks like the following on your browser:

Assignment 42. Compute

And here’s the same with an intentionally broken reference to an image:

Assignment 42. Compute

Generally, the more complicated formulas you need to present, especially if nonlinear in appearance, the more seriously you need to consider using images for the purpose, despite their drawbacks.

In principle, the object element could be used to embed data in different formats, including images, animations, and interactive presentations. However, support for object is limited and buggy. Support for its “brother”, the iframe element, is somewhat less buggy. In special cases, you might consider using iframe for large formulas mainly because iframe lets you specify an area where the data is to be presented so that a browser is expected to introduce scroll bars if needed. You would then need to include the normal img element as the content of iframe, to provide a fallback for browsers that don’t support iframe.

The plain text alternative: alt attribute

If you decide to use an image, you still have the original problem, in a modified form. Due to accessibility considerations, every img element must have an alt attribute that specifies the textual alternative. This means, in practice, that you need to write an alternative presentation of the expression in pure text form, with no HTML markup. On the other hand, you will do this for “fallback” use only, and you can e.g. write rather verbose explanations if needed, since the text will normally not be seen by people who see the image.

The purpose of the alt attribute is make the text comprehensible in a browsing situation where the image is not displayed. For some notes on the importance and practical use of alt texts, see my Guidelines on alt texts in img elements. In the simplest case, you would use a simple linearized notation as alt text.

A particular problem arises when such alt texts contain notational features that are not self-evident and are not otherwise used in the document. For example, suppose that expressions contain exponentiation, which is indicated using the usual two-dimensional formatting (an exponent appears raised, perhaps in smaller font) in image presentations, but a circumflex character ^ is used in alt texts. How can we inform people who need the alt texts, without disturbing people who see the images only? There’s a simple trick: use a “dummy” image, such as single-pixel transparent GIF, and put the explanations into its alt attribute, e.g.
<img src="transp.gif" alt=
"In this document, the circumflex character ^ is used
to indicate exponentiation, i.e. raising to a power.">
And you would put this element somewhere near the start of the document, before the first occurrence of an alt text that uses the convention explained.

If the image has been generated using TeX, you might also provide a link to the TeX version, since some people who cannot see the image for some reason might be able to understand TeX markup, or utilize it indirectly. Perhaps the image itself could be made into a link. In fact the MathWorld and Treasure Troves of Science pages often include the TeX notation directly as the alt text; this is useful but not as useful as giving plain text presentations there and providing links to TeX versions. In the document HTML Techniques for Web Content Accessibility Guidelines 1.0, section Markup and style sheets rather than images: The example of math recommends that if an HTML document has been generated from a TeX document, the original TeX (or LaTeX) document too be made available on the Web, since there are possibilities for auditory rendition of such versions.

That document also recommends that if a formula is constructed from several images, a single alt attribute should specify a textual alternative to the entire formula. Apparently, you would put it into one of the images and use alt="" for the other images.

Images in running text

Images are widely used for presenting formulas on the Web, and they are quite often the best practical way at present for large formulas to be presented as “blocks”. For symbols and short formulas in running text, “inline”, similar approach can be less pleasant, since the image does not adapt to text font size and face. Here’s a simple example:

The Greek letter is often used to denote summation, but from the character standards viewpoint, the n-ary summation symbol is a distinct character, though historically derived from the Greek letter.

If you change (on a graphic browser like IE or Netscape) the basic font size from the browser’s menu, you’ll see how the image remains the same size, instead of being adjusted according to the font size. And attempts to use style sheets to scale images are not very successful. Moreover, line spacing easily gets disturbed. See notes on such issues in my document about presenting the euro sign.

You could also write e.g. <img src="alpha.gif" alt="&#945;">, using a numeric character reference, and then on some browsers the document would look better with images off than with images on – but on many other browsers, users would see gibberish.

Using “normal” characters; esp. notations for physical quantities

Within the “normal” set of characters, namely the ISO Latin 1 character repertoire, which you can use pretty safely in HTML authoring, some characters need special attention as regards to use in mathematical notations. (As regards to typing them into your HTML documents, see How do I get a so-and-so character in my HTML? in WDG’s Web Authoring FAQ and section Typing characters in my character code tutorial.)

Unfortunately, on Macintosh platforms, several browsers still have serious problems with some ISO Latin 1 characters, and these characters include the superscripts 1, 2, and 3 and the vulgar fractions ½ ¼ ¾ as well as the multiplication sign ×. It’s up to you decide how serious this is, as compared with the possible improvements you might gain by using those characters.

Among the basic arithmetic operators, the plus sign + poses no problems. As a minus sign, the hyphen-minus character (-) can be used, though using the minus sign character would be more logical, and usually visually better (longer), but it belongs to “special characters” (with special problems). On the other hand, it avoids some line breaking problems that browsers have with hyphen-minus: we usually do not want e.g. a unary minus sign to have separated from its operand by a line break. (Browsers often break after hyphen-minus, but not minus sign.) For multiplication, there is seldom any reason to use the asterisk *, e.g. a*b (it’s a programming language idiosyncracy), since you can use the multiplication sign, e.g. a×b or perhaps the middle dot, e.g. a·b. When referring to vector operations, you could use × for a cross product and · for a dot product, of course. In such a context you might consider using the notation where for * indicates multiplication of a vector by a scalar, but that would require an explanation in a legend. For fractions and division, the solidus (slash) character / is commonly used, but you might also consider using the division sign ÷ in some cases.

In addition to the above-mentioned use as a multiplication symbol, the asterisk * has several uses as an operator symbol of some kind. Generally such uses are surrogate notations for various star-like symbols with more specific semantics. Since the asterisk is displayed in relatively small size and in a superscript position in most fonts, it does not look good when it should be binary operator. So if you use it that way, in lack of better characters, you might consider using markup that suggests that * be displayed in a monospace font; the simplest method is to use tt markup, e.g. <tt>*</tt>. On the other hand, for use e.g. as a star denoting an adjoint matrix, superscript style is better, and normally achieved (if achievable in a browsing situation) by not using any font markup for it. When using “special characters”, there is, in principle, a rich repertoire of various asterisk- and star-like characters available in Unicode. There is a large number of characters with “asterisk” in their name, including “asterisk operator”. Note that there are several Unicode characters with “star” in their name, including some that are classified as mathematical (general category: Sm, i.e. Symbol, Math), such as “star operator”.

Other operators include the less than and greater than signs (< and >). Since these characters are essential as tag delimiters in HTML, they should be “escaped” using the notations < and > when they are to be included into the document’s textual content, as in a<b. Similarly the ampersand (&), which might be used e.g. in logic as an and operator (connective), should be written as &.

There is nothing special about the equals sign (=); it can be typed as such. But the inequality symbol and the not equal to, less than or equal to, and greater than or equal to symbols are problematic; they do not belong to ISO Latin 1. If you have decided to use “special characters” (i.e. characters outside ISO Latin 1) despite their problems, then you would use the numeric references ≠ and ≤ and ≥ (appearance on your browser: ≠ ≤ ≥). Otherwise you would have to use some surrogates like =/, <= and >=. Some authors use =< and => instead of <= and >=, but there’s anyway the risk that one of the constructs be mistaken as an implication arrow or another arrow symbols. The not equals sign is the most difficult, since it has no widely recognized surrogate. Note that /= is a “divide and assign” operator in some programming languages! In some contexts, you might use the character pair != to denote inequality, especially if you expect it to be familiar to readers from their experience with programming languages like C, Perl, and JavaScript. For a general audience, however, the != symbol could be a mystery; there is hardly anything natural in using the exclamation mark to denote negation!

When expressing physical quantities, note the following rules of the SI system of units (see Guide for the Use of the International System of Units (SI) for more information):

• Unit symbols like m or s are written in Roman (upright) style, not in italics. In HTML, this normally means that you don’t use any specific markup for them. But if the symbol appears inside text that is affected by markup or CSS rules that make the browser use an italic font, such as inside an em element (which is typically presented in italics), then you should use e.g. something like the following:
  in HTML: <em>The measured time was only 42&nbsp;<span class="unit">s</span>.</em>
  and in CSS: .unit { font-style: normal; }
• Units formed from other units by multiplication should be written using either a middle dot (in HTML, that can be denoted by ·) or a space, e.g. N·m or N m. The middle dot is preferable for clarity.
• For multiplication of numbers and quantities, the multiplication sign × is preferred when a decimal point is used in numbers. When a comma is used as the decimal marker, the either the multiplication sign or the middle dot · can be used for multiplication. These rules are given in the ISO 31-0 standard, which gives preference to the use of a comma as a decimal marker, but it is debatable whether this is wise e.g. in documents in English; see the document ISO 31-0: a standard that may confuse by Stewart Clark. Examples: 4.2&times;10<sup>15</sup> and, in another usage, 4,2&middot;10<sup>15</sup> (renderings: 4.2×10¹⁵ and 4,2·10¹⁵ but note the problems with superscripts).
• Temperatures in Celsius degrees are written using the degree sign, with a space between it and preceding number. Example of HTML markup: 12 °C (displayed as 12 °C).
• When expressing angles, unit symbols for degrees, minutes, and seconds are written without spaces between the numerical value and the unit symbol. The theoretically correct characters for minutes and seconds would be prime and double prime, but being outside the ISO Latin 1 repertoire, they are usually replaced by the apostrophe ' and the quotation mark " (example: 30°22'8").
• With the exception above, there is a space between a numeric value and a unit symbol, e.g. “1 m” (not “1m” or “1-m”).
• When using the plus-minus sign ± (which can be presented as ±), as well as in other contexts, the notation should be such that “it is completely clear to which unit symbols the numerical values of the quantities belong”. This means e.g. 63.2 m ± 0.1 m or (63.2 ± 0.1) m (but not 63.2 ± 0.1 m or 63.2 m ± 0.1).
• As regards to numbers, see notes on grouping digits and “thinner spaces” and notes on exponential notations below.

Web browsers generally treat any space character as a possible line break point. This is often undesirable in notations like the one discussed here, e.g. between a numeric value and a unit denotation. Thus, some method of avoiding that should be used, e.g. using a no-break space between them, instead of a normal space. See section Line breaks as problems.

As parentheses you can use normal parentheses (), square brackets [], and braces {}. You might wish to use font markup (such as <big>{</big>) to make outer parentheses look bigger, to make the structure visually clearer.

Also note that ISO Latin 1 includes some other more or less mathematical characters beyond those in Ascii: the micro sign µ and the not sign ¬. But beware of the following: assuming that the sharp s ß would be the letter beta; confusing the ordinal masculine indicator º with the degree sign ° or taking either of them as superscript 0; thinking that left guillemet « and right guillemet » would mean ‘much less than’ and ‘much greater than’; or assuming that the letter O with stroke Ø would be an empty set symbol! Don’t be tempted by casual appearances of characters; there are reasons to be strict about the meanings of characters.

Line breaks as problems

Line breaks are often undesirable inside expressions, but Web browsers generally treat every space as a potential line break position. There are several ways to deal with this:

• Using the no-break space character (presentable using  ) instead of a normal space.
• Using the nonstandard but rather widely supported nobr markup around a string that should be kept together. Example: <nobr>a + b + c</nobr>. (You might avoid the problem by writing just a+b+c, but spaces give a more “airy” presentation.)
• Using the nowrap attribute in a td (or th) element. This is useful if it’s OK to prevent all line breaks inside a table cell (except line breaks explicitly requested using br tags).
• Using white-space:nowrap (or maybe white-space:pre) in CSS. Typically this means that you would use something like the following:
  in HTML: <span class="q">42 m</span>
  and in CSS: .q { white-space: nowrap; }

It is debatable whether it is more logical to use the CSS way than no-break spaces. In a sense, it is a structural property of an expression like “42 m” that its two parts belong closely together, so that in any normal presentation, there should be no line break between them, or any pause in speech presentation. On the practical side, no-break spaces surely work more reliably, partly because browser support for the white-space is still limited, partly due to general CSS caveats.

Note that the nobr markup is the only sure cure against IE’s tendency to treat every hyphen as a potential line break opportunity, even in a string like a-b or -a! But if you have decided to use “special characters”, then you might use the real minus sign, −, instead of hyphen, and that would avoid the hyphen problem. See Dashes and hyphens.

There are even more oddities in IE: it may also treat any of -()[]{}«»%°·\ as indicating a potential line break position (before or after, depending on the character). Thus, it may well split “sin(x)” to “sin” on one line and “(x)” on the next! Generally nobr is the only effective cure, as explained in Word division in IE, but we will discuss a special case later.

Grouping digits and using “thinner spaces”

The problem with separators

It is customary and recommendable to group digits in long numbers to groups of three digits. But the method of separating the groups depend on cultural conventions and even personal style. This typically means using spaces, commas, periods, or apostrophes as separators.

It is safest to use spaces, since the other alternatives could be misinterpreted. For example, in English 1,005 would mean one thousand and five and 1.005 would mean one and five thousandths; in French, and in several other languages, it’s just the reverse! We need to make some decision concerning the decimal separator, but for integers we can avoid the problem by using spaces: 1 005 is unambiguous.

This practice conforms to the ISO 31-0 standard, which says:

To facilitate the reading of numbers with many digits, these may be separated into suitable groups, preferably of three, counting from the decimal sign towards the left and the right; the groups should be separated by a small space, and never by a comma or a point, nor by any other means.

This raises two problems: First, the line breaking problem that we just discussed; but we saw that there are reasonable solutions to it. Second, you might regard spacing between digit groups as typographically excessive, if normal spacing (as between words) is used. ISO 31-0 in a sense agrees with you, by referring to small space.

Affecting the width of spacing

Although there are several space characters of specific width in Unicode (in the range U+2000 to U+200B in the General Punctuation block), using them is not a good idea, as a rule. In practice, they don’t work well, partly due to limitations in browser support for such “special characters” (to be discussed in the next section). And in principle, they are “compatibility characters” only.

But you can use normal space characters and specify some simple CSS rules that suggest reduced spacing between “words”, using the word-spacing property with a negative value. That property specifies the spacing to be used in addition to default inter-word spacing, so a negative value suggests a reduction of the spacing. A “word” is here any sequence of non-whitespace characters. The boring part of the matter is that you typically need to include extra span markup just to have some element with which the rule can be associated. You can hopefully find some nice program tool for generating the markup needed, so that you don’t need to type it all by hand.

In my opinion, word-spacing: -0.07em creates a fairly nice result for spacing between digit groups. It means a suggestion to reduce the normal spacing by 7 % of the font size, so it naturally adapts to whatever font size happens to be in use. This seems to make the digit groups separated visibly but not disturbingly. The following demonstrates first a long number without the effect of such a suggestion, then with that effect, naturally assuming that your browser supports this part of the CSS specification:

• 123 456 789 000 000 000
• 123 456 789 000 000 000

For the latter number, I used the following markup:
<span class="number">123 456 789 000 000 000</span>
and the following style sheet:
.number { word-spacing: -0.07em; white-space: nowrap; }
The white-space rule is unrelated to spacing but a good idea for other reasons, as explained above.

For related notes, discussing similar problems in text processing, see How to cope with international standards for the thousands separator by William S. Statler.

Spacing in expressions

The “excessive spacing” problem also arises in other contexts in mathematical expressions. It is often regarded as good style to use some spacing e.g. around mathematical operators, but not as big spacing as we get in typical browsing situations if we just use normal spaces.

In high-quality typesetting, e.g. when using TEX, spacing is controlled carefully, using advanced tools and techniques. We cannot expect to achieve the same using HTML and CSS, but we can aim at reasonable quality.

An expression like “a + b” is usually best written in HTML so that there are spaces around the operator “+”. This gives more flexibility, since we can then use word-spacing in a simple way. If the spaces were omitted, letter-spacing (which actually affects the spacing between all characters, not just letters) could be used in simple cases like this, but things would get much more complicated when variables consist of several characters (e.g., contain subscripts).

The following example shows the rendering of an expression with several operators, under different style sheets:

Thus, a word-spacing value like -0.07em creates an appearance that more or less resembles typical typesetting of mathematical expressions. A value of -0.2em tends to reduce spacing so that it almost corresponds to the rendering we would get if no space characters were used. The effects naturally depend on the font in use, but these observations apply to typical fonts like Times New Roman and Arial.

Using special characters

In mathematical notations we very often need special symbols, such as Greek letters or a symbol for infinity. In principle, you can use the full Unicode character reportoire in HTML. Unicode Technical Report #25, Unicode Support for Mathematics, says: “Starting with version 3.2, Unicode includes virtually all of the standard characters used in mathematics.”.

In practice, browser support is still rather limited. It may well happen that even if your browser is sufficiently new, you won’t see all the sample characters presented below but e.g. question marks or small boxes instead.

Using the special characters, you can often significantly improve the quality of presentation. But there are considerable risks. The table on the right is intended to illustrate the problems as well as the potential gain. So you need to consider whether it would be better to use a safe, though inferior, simplified textual presentation like “Lech Walesa”, “alpha Centauri”, and “nabla F”.

What may happen to special characters Nice appearance A failure

HTML 4.0 contains a relatively large set of named entities like α for various symbols, including Greek letters as used in mathematics. They are nicely presented in WDG’s document HTML 4.0 Entities. (There’s also a more compactly presented list by me: Character entity references in HTML 4.0.) However, they are just “named constants”, with definitions that use numeric character references. And since the latter are more widely supported (e.g. Netscape 4 supports them but not the named entities), there’s little reason to use the entities, except if you need to pay special attention to what happens on browsers that don’t support even the numeric references. It’s less disastrous that users see an intended alpha as α than seeing α or something worse. But although the entity names are intended to be mnemonic, some of them are rather cryptic; using ∑ for the n-ary summation symbol would probably work well (in the above-mentioned sense), but how many readers would intuitively understand what ∋ means? Note: If the entity is followed by a space or a line break, the semicolon can be omitted, thereby making the notation look slightly more natural. Technically, the semicolon can be omitted if the character immediately following it is not a letter (A–Z, a–z) or a digit or one of the following: -._:; (hyphen, period, underline, colon, semicolon).

Note that by HTML specifications, you are not limited to using those numeric character references for which there is a named entity in HTML 4.0. You can principle use any &#number; notation where number is the Unicode code position to which a character has been assigned.

As a practical point, note that Microsoft has defined WGL4 (or “Pan-European”) list of characters, containing some mathematical symbols too. If you use them only, you have relatively good odds of finding a large number of users equipped with fonts that can display the characters. See Using Special Characters from Windows Glyph List 4 (WGL4) in HTML by Alan Wood.

Netscape has better chances of getting things right if the document is announced to be in UTF-8 encoding (which means that all non-Ascii characters, even those in ISO Latin 1, must be written using numeric references or entities). For more about this, and other technical principles, see Using national and special characters in HTML. See also the document How to find an &#number; notation for a character, and note that you will probably be interested especially on the following Unicode blocks:

• Mathematical Operators, e.g. ∀ ∂ ∆ ∞ ∮ ≈ ⊥
• Letterlike Symbols, e.g. ℕ ℵ ℋ ℧
• Arrows, e.g. ←⇒

If you only need Greek letters in addition to Ascii characters, then there is the possibility of using an encoding which lets you enter Greek letters directly. You could use ISO 8859-7, which is relatively widely supported. See section Simpler ways for simpler needs: simple 8-bit encodings in the above-mentioned document. But note this would give you just Greek letters, not e.g. not equals sign, nabla operator, aleph, etc. ad ∞. Moreover, you would risk losing most of the upper half of ISO Latin 1, due to browser bugs.

Note that there are pitfalls in the area of characters. Never trust a smiling cat, or what a character looks like. For example, in modern character set standards, the mathematical symbol for n-ary summation (∑, ∑) is distinct from Greek letter capital sigma (Σ, Σ), although it is historically derived from it. Ditto for n-ary product symbol (∏, ∏) and capital pi (Π, Π). I used to think that someone might still consider using sigma as a surrogate, assuming it might be better supported, but Andreas Prilop kindly pointed out my mistake, concluding with the following: “you need only a browser that knows ‘Unicode big numbers expressions’ and Windows 3.1 [or newer] or any MacOS version, both without any Greek support, to display &#8719;”.

Surrogate notations

For characters that cannot be presented reliably enough but would be needed, different surrogates can be considered. The obvious, and often quite adequate, method is to use words or abbreviations, e.g. “infinity” or “inf” instead of the infinity symbol (∞).

Sometimes one could consider using a character or a sequence of characters in a way which tries to approximate the appearance of a real character which itself cannot be used reliably. There are strong reasons to avoid playing with characters too much, and one should not do things which seriously conflict with the meanings of characters. I’d hesitate using, say, “oo” as a surrogate for the infinity symbol. But there are some notations that one could use, at least if explained in a legend.

In particular, the logical connectives, corresponding to “and” and “or”, could rather safely be presented using /\ and \/, perhaps in reduced font size (/\ and \/). In fact, the reverse solidus \ has no fixed semantics that would be violated by such usage, and in fact it was originally introduced for use in these notations! Note that the Unicode characters for the connectives (∧ and ∨) are poorly supported at present.

A common surrogate for arrow symbols is the use of character pairs like <- or <=, though longer strings like ---> might make the meaning more obvious. See also notes on problems with some common comparison operators.

Note that some of the surrogate notations discussed here may suffer from line break problems on IE, unless precautions are taken by using nobr markup.

Since notations like /\ or ---> try to imitate the shape of the real characters they stand for, it can be useful to suggest some particular font, or a list of fonts in order of precedence, using the font face markup in HTML or the font-family property in CSS. I have written a test page that shows text in different fonts which are commonly available in Windows systems. For example, --> looks odd when Arial font is used, but --> in Tahoma looks pretty much like an arrow.

In practice, you could use a style sheet like the following:

.logop { font-family: "Times New Roman", serif }
.arrow { font-family: Tahoma, Symbol, monospace }
.darrow { font-family: "Times New Roman", serif }

<span class="logop"><nobr>/\<nobr><span>
<span class="arrow"><nobr>--></nobr><span>
<span class="darrow">==><span>

This is how they look like on your current browser: /\ --> ==>

Using font markup

One of the most common ways of trying to include Greek letters and mathematical symbols into Web pages is to use font face="Symbol", such as writing <font face="Symbol">c</font> to get the Greek letter gamma (γ). I will not explain here why that approach is fundamentally wrong; I refer to the excellent presentations Using FONT FACE to extend repertoire? by Alan J. Flavell and <FONT FACE> considered harmful at the Alis Babel site. Briefly, the trick appears to work in many situations, but that’s because of browser bugs. The invariable meaning of <font face="Symbol">c</font> is the letter c, so any correctly behaving browser will display it using some physical presentation (glyph) for that character.

In fact, you can make even e.g. Internet Explorer 4 or Netscape 4 behave correctly in this respect: just change the settings so that font face suggestions are ignored (On IE: View → Internet Options... → General → Accessibility..., and check “Ignore font styles specified in Web pages”; on Netscape: Edit → Preferences... → Appearance → Fonts, check “Use my default fonts, overriding document-specified fonts”.) After all, font face is a stylistic suggestion, just as font color is.

But there are some reasonable uses for font-level markup that could be applied in mathematical notations. In particular:

• You could use the b markup for symbols of vectors to make them appear in bold face. But consider it as a presentational suggestion only, making sure that the text itself indicates the meanings of symbols, and considering bolding just as extra clue.
• Similarly, you could use i or var markup for variables and other symbols which are conventionally displayed in italics, as in f (x) or sin x. The var markup may sound more logical for variables, but it’s questionable whether var was meant for mathematical variables; its original definition (in HTML 2.0) says that it “indicates a placeholder variable”. IE 3 oddly displayed var in monospace font, but current browsers use italics. See below for problems that italics may cause. Note: the constant e (= 2.718…) and and the imaginary unit i are often written in italics, but according to the ISO 31-11 standard, they shall be written in upright style.
• You can combine those elements to present vector variables: <b><i>x</i></b>, which displays as follows on your browser: x
• You might wish to change font size for some characters. The simplest way is to use the small and big elements. But note that if you use sub and sup for subscripts or superscripts, the characters will by default be smaller than normal, on many browsers (but not all), so further size reduction may easily make the text unreadable. But if you like, you could e.g. make digits after a decimal point appear in smaller font (as in 42.123 – consider then putting the decimal point too inside the small markup). If you wish to emphasize a formula like E = mc², you can use big markup or the font-size property in CSS, in addition to the logical em or strong markup (commonly rendered in italics and in bold, respectively, by default).

Since browsers often tend to put characters too close to each other when a character in italics is immediately followed by a non-italics character, as in f(0), you might consider using a no-break space character between them, e.g. f (0), using markup like <i>f</i>&nbsp;(0). As a side effect, this trick seems to prevent an undesired line break before “(” on IE. But this is really an ugly trick, and it might result in poor appearance on a browser which behaves more reasonably by default, leaving enough space, so that the trick would make the spacing excessive. Moreover, Macintosh Netscape 4.x adds a space after italics, so that even <i>f</i>(0) causes a “hole”, and an added no-break space of course makes the problem even worse.

Perhaps the best way to deal with the italics issue is to add some empty space after any element rendered in italics. You could use either margin or padding property for this. Using padding is probably better, since some day someone might set a background color for the element. (The background extends to the padding but not to the margin.) If you need the spacing just for an individual expression, you could use markup like <i style="padding-right: 0.2em">f</i>(0) for an expression like f(0). Or you might even write a general style sheet rule that sets a right margin for all inline elements that are commonly rendered in italics. You might explicitly set right margin to zero, since it is imaginable that some browsers deal with the problem by using some default right margin, and you don't want a cumulated effect. Example:
i, em, cite, dfn, var { padding-right: 0.15em; margin-right: 0; }

Fractions

For fractions like 6/7, the common linearized notation is usually the best, especially within running text. Attempts to create genuinely two-dimensional appearance, with a horizontal line and the numerator above it and the denominator below it, would require relatively complicated techniques and will be discussed later in the section Towards two-dimensionality. Here we consider “pseudo-twodimensionality”.

If the only fractions in your document are vulgar fractions ½ ¼ ¾, you might consider using the ISO Latin 1 characters for them, e.g. as entity references ½, ¼, ¾. But if you need other fractions too, this is not a good idea since it would be odd if different fractions have essentially different appearances. In Unicode there are a few more fraction characters (namely for 1/3, 2/3, 1/5, 2/5, 3/5, 4/5, 1/6, 5/6, 1/8, 3/8, 5/8, 7/8), in the Number Forms block, but that would not enrich the repertoire much, and they don’t work very widely, as explained in the Special characters section.

There are some risks with the “vulgar fractions”, even though they are ISO Latin 1 characters. In addition to the problems with some Mac browsers, there seem to be some problems on systems where the ISO Latin 9 (ISO-8859-15) code is used. That code is very similar to ISO Latin 1 but differs from it in a few code positions, including those that are allocated to vulgar fractions in ISO Latin 1. When ISO Latin 9 gains popularity, people can’t always configure their systems properly, and this may result in situations where “strange” characters appear in place of the vulgar fractions.

You might use a linear notation with sup markup for the numerator and the sub markup for the denominator. The main problem is then that an expression like ⁵/₈ tends to cause uneven line spacing, due to the poor quality of implementation of superscript and subscript style in most browsers.

It seems that the ideal solution would be to use the fraction slash character which should, according to the Unicode standard, solve the problem for numeric fractions in an elegant way. That would mean something like 1⁄2 in HTML. A program which is capable of presenting fractions two-dimensionally should do that, and otherwise the appearance should fall back to linear notation. But I’d be very surprised to see any current browser handle that the intended way, and many of them would fail to implement even the fallback part!

Just to demonstrate what the different approaches yield on your current browser with its current settings, here is a table of different presentations for 5/8:

The fraction slash character is often more slanted than the normal slash (solidus) character. This is intended to correspond to special rendering where the numbers around it are in reduced size and vertically positioned in a manner that reflects a traditional way of writing fractions. However, browsers generally do not make use of the special semantics of the fraction slash that way. As a result, the fraction appearance is not good; it’s even worse than the presentation that we get by using a normal slash, since the fraction slash may (almost) touch the characters before and after it. Although this could be alleviated by setting letter-spacing, it’s more natural to try to imitate the traditional fraction appearance. The last row of the table above illustrates this. The style sheet used is the following:

.above, .below { font-size: 70%;
                 font-family: Verdana, Arial, sans-serif; }
.above { vertical-align: 0.7ex; }
.below { vertical-align: -0.3ex; }

There can be line breaking problems with the “/” character as well as the fraction slash, though currently on minority browsers only. To stay on the safe side, you could use markup like <span class="frac">5/6</span> for fractions and use the style sheet rule .frac { white-space: nowrap; }.

Underlines, overlines

To underline something, you could use the u element in HTML. However, underlining is widely taken as indicating a link on the Web. Links want to be links, and you should avoid doing anything that might make something look like a link if it isn’t. But if underlining a symbol is part of an established tradition in some field, go ahead and use the u element.

It is more common to use overlining in mathematics, e.g. to indicate an average. You can’t overline in HTML. In a style sheet you could suggest overlining, using the declaration text-decoration: overline. However, as the property name says, it’s assumed to be decoration, not part of the content proper, and in any case style sheets are for suggestions only; you should expect style sheets to get ignored fairly often. Presentationally, note that the overline appears rather high above the symbol.

Overlining something like x might be adequate if the context or explicit explanations make it clear what is meant even if the overline does not appear. For casual overlining a single symbol, you could use an embedded style sheet as follows:
<b style="text-decoration:overline"><i>x</i></b>.

For roots, you might suggest overlining to make it more evident what belongs “under the root”, i.e. to produce a sort of vinculum:

√(a²+b²)

This uses simple markup where the expression in parentheses is enclosed between <span style="text-decoration:overline"> and </span>. Note that things get distorted on many browsers if there are exponents written using sup under the root.

In our example, the parentheses are redundant when overlining is applied. I have experimented with tricks which would put the parentheses inside span elements with style sheets suggesting the suppression (display:none) of them in presentation. But Netscape 4, for example, supports the suppression but not the overlining.

What about roots other than the square root? There are Unicode characters for the cubic root and fourth root symbol, though they are less widely supported than the square root symbol. For a general root, you might put the radical index right before the radical symbol, in superscript style. Besides, you could use CSS to suggest reduced spacing between those characters. This would mean HTML markup like the following:
<span class="radic"><sup><var>n</var></sup>&#8730;</span><span class="radicand"><var>x</var></span>
with CSS like the following:
.radic {letter-spacing:-0.15em; }
.radicand {text-decoration:overline; }
This looks like the following in your current browsing situation: ⁿ√x.

Instead of text-decoration: overline, you might set a top border for the radicand, e.g. .radic { border-top: solid 1px }. This seems to produce reasonable presentation even when there are exponents and subscripts (sup and sub elements) in the radicand, as the following example illustrates:

Arrays and tabulations

HTML tables are intended for presenting data which is tabular. We will not discuss here the tabulation of numeric data in general, since the basic HTML constructs are simple and the fine tuning, using attributes in HTML markup and/or style sheets, is beyond our scope. But it needs to be noted that numeric data should normally be right-aligned, which is not the default alignment in HTML tables, so you often need the align="right" attribute (in td or tr elements). It would often be desirable to align numeric data on the decimal point, but this is in practice not possible in the way defined in the HTML 4.0 specification. Instead, some tricks are needed, such as using a monospace font and right padding with no-break spaces so that the items in a column have the same number of characters to the right of the decimal point.

For a matrix, the conventional notation in mathematics is to use large parentheses around. This would be rather difficult in HTML and would work well for very small matrices only (cf. to methods discussed in the Towards two-dimensionality section below). It’s probably best to use a different presentation which makes matrices have an appearance which is suitably distinctive, such as a special but not too striking background color for cells. You might write, say, <table class="matrix"> for any table which presents a matrix, and include a style sheet rule like
table.matrix td { background: #fda none; color:#000; }
This results in something like the following on your browser (when a cell spacing of 4 pixels and centering of cell contents has been suggested too):

In the example above, the table representing a matrix has been embedded into an outer table so that we have been able to associate a symbol with the table. Similar techniques can be used e.g. when you wish to present the sum of tables; you would write an outer one-row table which contains the matrices in its cells and a plus sign in a cell of its own between them. The following example illustrates this:

Subscripts, superscripts, and exponents

Style or essence?

The HTML language has the sub and sup elements for subscripts and superscripts. But they should primarily be regarded as stylistic suggestions only, rather than as essential parts of the notation. (See my notes on the intended use of sub and sup.) Naturally they can be valuable for “styling” math, too. To quote the descriptions of sub and sup in WDG’s HTML 4.0 Reference, replacing their markup examples with their appearance on your browser:

Since SUB is inherently presentational, it should not be relied upon to express a given meaning. However, it can be useful for chemical formulas and mathematical indices, where the subscript presentation is helpful but not required. For example:

• Chemical formulas include H₂O (water) and C₂₁H₂₇NO (methadone).
• Let x = x₁ + x₂ + ... + x_n.

Since SUP is inherently presentational, it should not be relied upon to express a given meaning. However, it can be useful for mathematical exponents where the context implies the meaning of the exponent, as well as other cases where superscript presentation is helpful but not required. For example:

• The rent is due on the 1^st of each month.
• An example of a quadratic polynomial is 3x² + 5x - 7.

Superscripts are often used for footnote references in print media. But in mathematical texts, such practice is best avoided in order to remove any risk of confusing such usage with exponentiation or other mathematical superscripting. Besides, such footnote references don’t work well on Web pages in general, as explained in the document Footnotes (or endnotes) on Web pages.

Superscripts and subscripts as two-dimensionality

Two-dimensionality in formulas will be discussed later, but here we mention some possibility of using superscripts and subscripts to simulate notations that should really be written above and below a symbol. The following example (which also uses special characters) shows the markup for an infinite sum and the resulting appearance on your browser.

&#8721;<sub><var>i</var>=0</sub><sup>&#8734;</sup>
<var>x<sub>i</sub></var>

That means summation of x_i (with i as subscript) from i=0 to infinity. In browsing situations where the infinity symbol is correctly displayed, the main problem on most browsers is that the infinity symbol does not appear above i=0 but to the right of it (in superscript style though). In the worst case, the reader might misunderstand the upper limit as an exponent of the lower limit! So it is perhaps better not to use a superscript at all but put the limits into a subscript, e.g. as i=0,…,∞ (which makes use of the horizontal ellipsis character; midline horizontal ellipsis would be better, but it’s less widely supported) giving the following appearance: ∑_i=0,…,∞ x_i.

The infinity symbol ∞ might appear in fairly small size. In general, special symbols easily become unreadable when font size is reduced, so you might consider setting the font size larger than normal. In the above example with HTML markup for a formula and the formula itself side by side, the font size for the formula has been set to 125%.

The presentation of a summation expression could be tuned in different ways, some of which will be discussed in the sequel. But generally they lead to rather complicated constructs, and the complexity may cause problems on different browsers, current and future. However, some simple superscript positioning problems can be addressed relatively easily. Let us take the example of just positioning a simple one-character superscript above a one-character subscript.

In chemistry, sometimes both subscripts and superscripts are used, for example in formulas for ions. Consider the formula
NO<sub>3</sub><sup>−</sup>
where letter O has both subscript 3 and superscript –. The latter is the minus sign, and the Ascii hyphen is a particularly poor surrogate here due to its shortness; such problems were discussed in the section on special characters. It seems that the stylistically preferred notation for ions has the superscript in the same horizontal position as the subscript. See, for example, the Ions page in Eric Weisstein’s World of Chemistry, which uses images to create such appearance.

The markup mentioned above by default creates an appearance where the superscript is on the right of the subscript (O₃⁻). Changing the order of the superscript and subscript would not help much. But we can try to affect the horizontal placement by using a negative margin. Since, in general, the notation for an ion always has a superscript and may or may not have a subscript, it seems practical to put the sup element first and move the subscript to the left. This would mean markup like
<span class="ions">NO<sup>&minus;</sup><sub>3</sub></span>
(or maybe with div instead of span) and a style sheet like the following:

.ions { line-height: 1.8; }
.ions sub { margin-left: -1ex; }
.ions sup { vertical-align: 1ex; }

The vertical alignment of the superscript has been set to a rather large value, to deal with the specifics of the expression. In general, creating good appearance for variables with both a subscript and a superscript is rather challenging: fine-tuning is needed, and the rendering will still greatly depend on the font used. Beware that widths of characters vary by font, so a horizontal shift created by margin-left or some other method might be adequate for some fonts and poor for others.

The margin-left property effectively shifts the subscript to the left. The line-height property is useful for defeating some IE bugs – and fairly natural, since you are using quite some height here, more than we can expect to be available by default. Note that if an element in class ions contains a lone superscript, you would need to take extra measures, since the CSS code above postulates that a sup element appears immediately after a sub element.

From the HTML perspective, the basic problem in situations like this in that the sub and ^sup elements have been defined in a rather presentation-oriented manner rather than structurally. When you write <sub>i</sub>, you're saying that “i” is a subscript but not what it is associated with. In a case like “a_i²”, “i” is a subscript for “a” whereas “2” is a superscript (exponent) for the expression consisting of “a” with subscript “i”. There is no way to express this structural relationship in HTML. Using extra parentheses, like “(a_i)²”, deviates from common mathematical notations and looks somewhat clumsy, but it makes the meaning unambiguous and clear.

Uneven line spacing

As you may have noticed even from the simple examples above, subscripts and superscripts tend to mess up line spacing especially on IE. For example, a superscript expression like A^T makes the line have more than normal vertical spacing above it. The reason is that subscripts and superscripts may increase the vertical space needed for a line, and browsers quite naturally increase height of a line box (making it larger than the value of the line-height property).

There doesn’t seem to be any complete cure to this esthetic problem, but reducing the font size of the superscript or subscript usually helps. Robert G. Eldridge has pointed out that uneven line spacing can be prevented by putting the sub or sup element inside small markup. (It might matter which way the two elements are nested; making small the outer element seems to work more often.) Example: 10<small><sup>9</sup></small>. But the size reduction might make the text hard to read, especially on browsers that already use reduced font size for subscripts and superscripts. Thus, it is best to use CSS to suggest modest font size reduction for subscripts and superscripts. It is usually best to suggest a sans-serif font in this context, since such fonts are usually more readable than serif fonts when the font size is small. For example, you could use the following CSS rule:

sub, sup { font-family: Arial, Helvetica, sans-serif;
           font-size: 65%; }

On a browser that has CSS support enabled, you will then see that superscript expressions such as 10⁹ or A^T will not increase line spacing, or increase it rather unnoticeably. In fact, all subscripts and superscripts (except those in the example above) in this document have font size set to 80% on CSS-enabled browsers, so the problem probably did not appear in its worst appearance.

Setting the font size of sub and sup elements helps to avoid browser inconsistencies. Browsers have quite some variation in the default size of subscripts and superscripts. By setting some specific size, as a percentage of the basic font size, we are in the better position to estimate how subscripts and superscripts really affect layout.

On similar grounds, we might set the vertical alignment. Some browsers put subscripts just a little below the vertical level of base text, whereas some other browsers put them far below. The following might result in a reasonable compromise between conflicting goals, in simple cases at least:

sub { vertical-align: -0.6ex; }
sup { vertical-align: 0.8ex; }

Here’s a simple test for your browser: a subscripted quantity A₈ with the browser’s default vertical rendering, and the same quantity A₈ with vertical-align set to -0.6ex. Similarly, here’s a superscripted quantity A⁸ with the browser’s default vertical rendering, and the same quantity A⁸ with vertical-align set to 0.8ex.

Edward Welbourne has pointed out that the various line-spacing hacks for inline sub and sup might benefit from specifying that they only apply in paragraphs. That way, subscripts and superscripts in formulas displayed as separate blocks, tables and the like would not be affected (and could be handled by other rules). For example, in the test case above, the selectors sub and sup would be replaced by p sub and p sup.

By default, IE puts a subscript (as in H₂O) at a rather low position, so that the top of the subscript characters are almost at the level of the text baseline. This is odd, especially since according to Microsoft’s document Latin 1 – Figure Design Standards, “inferior numbers” (i.e., Unicode characters that represent digits as subscripts), “the most useful for text and scientific notation is an alignment that descends below the baseline approximately half the inferior numeral’s height”. On the other hand, Mozilla by default puts a subscript rather high. By setting vertical-align of sub to -0.6ex for example, we make a subscript (as in H₂O) appear in more natural position, and this also tends to help with the line spacing problem.

The problem of uneven line spacing can mostly be avoided if subscripts and superscripts are used only in formulas presented as separate “blocks”, not that well in running text. Moreover, superscripts work reasonably near the start of a paragraph and subscripts work near the end of a paragraph, but that’s a rather special case.

Special problems with exponents

But there is a quite different problem, especially when superscripting needed for exponentiation, which is not just a stylistic feature of course. The same applies to using superscripts e.g. in denoting the transpose of A by A^T (i.e., A immediately followed by T in superscript style). It really makes a difference if 10⁹, which is intended to mean 10 to the power 9, actually gets displayed as 109.

It is true that the most browsers render superscripts properly. But they often fail to handle nested superscripts (or subscripts) well. And that means that exponentiation in an exponentiation may get lost in graphic presentation, too. For example, some versions of Internet Explorer render a<sup>b<sup>c</sup></sup> the same way as a<sup>bc</sup>. Here is test for your browser: a^bc (the letter c should be a superscript of b).

The preceding may show the nested superscript in rather small font. This would be the effect of nested font-size reduction to 80%. When nested superscripts as in a^bc or e^f(x)n are needed, it is perhaps best to reduce font size just to e.g. 93% (as in this paragraph, if style sheets are enabled). This in turn tends to make line spacing uneven. One approach (perhaps observable in this paragraph) is to set the line-height property (in CSS) to a relatively high value like 1.6. Moreover, it might be a good idea to set line-height globally (for the body element) to a value like 1.3, since this helps with some of the smaller problems of uneven line spacing and may improve readability in general.

Avoiding superscript problems

There are various ways to avoid the problems with superscripts by using other notations:

• For some superscripts, there are separate characters which correspond to normal characters in superscript style. Except for superscript 2 and superscript 3, which are rather often needed of course, this approach means using special characters with limited browser support, so it’s not a very good solution. (Well, it would work fine in a text which needs just things like m² or m³ for square and cubic meter; see however notes on Mac problems even for these.) Moreover, even by using the Unicode block Superscripts and Subscripts you wouldn’t extend the superscript repertoire much: the other digits and the characters +-()n.
• Exponentiation is rather often expressed using a surrogate notation which uses an exponentiation operator like ** or ^, as in many programming languages. It depends on the intended audience whether notations like 10**9 or 10^9 need to be explained and which of them is better. Assumably non-technical audience guesses the meaning of 10^9 better, but on the other hand the circumflex character ^ varies in shape and might not suggest the idea of “to the power of” very well.
• You might also use function notation such as exp(x) instead of e^x, in some cases. For a general power, a notation like power(a,b) could be used, but the author should indicate whether this is the b^th power of a or the a^th power of b (since there are different practices on this).
• For numbers, you could replace the use of a notation like 42.5×10⁹ by a notation like 42.5E9, borrowed from programming languages. This might work reasonably in documents read by people with programming background or acquainted with scientific calculators.
• For physical quantities, you can use SI prefixes so that you won’t need an exponential notation for a number. For example, you could replace 42.5×10^-6 s by 42.5 µs. This isn’t really a surrogate; rather, it would be a better notation even if exponents worked without problems.

The superscript and subscript problems can also be seen as special cases of a wider problem: how to present mathematical expressions in the conventional two-dimensional format?

Equation numbers

In mathematics, it is common to number equations and put the number on the right of an equation, in parentheses or brackets, as follows:

Several approaches have been proposed to achieve such layout using just CSS and no presentational markup. However, the CSS methods (whether based on floating or on positioning) seem to suffer from various problems on current browsers. Some methods work well if the equation fits on one line but lead to confusion when it is divided over two or more lines. Since we wish to create pages that adapt to varying canvas widths (“fluid design”), a simple table is the practical solution:

<table class="eq" summary="Equation and its number." width="100%">
<tr>
<td>the equation</td>
<th align="right" valign="bottom">(number)</th>
</tr>
</table>

If you regard such a table as a deprecated “layout table”, consider its markup, specifically the summary attribute and the use of th (table header cell) element for the equation number, which logically acts as a header for the row (the equation).

You can get rid of the presentational attributes width, align and valign by using corresponding CSS properties. If you like prevent the equation number from appearing in bold, you should either replace (somewhat illogically) the th element by a td element, or use the font-weight property in CSS. As a whole, this could mean the following style sheet:

.eq { width: 100%; }
.eq th { text-align: right;
         vertical-align: bottom;
         font-weight: normal; }

The following equation has been formatted with such a style sheet (and its HTML markup is “pure”):

Towards two-dimensionality

For simplicity, let us assume that we wish to present the expression x divided by a-b in the conventional two-dimensional format. In this trivial case, the linearization x/(a-b) would do just fine, but in more complicated cases, two-dimensionality would greatly improve the clarity. Using an image is one possibility, and if the linearized version isn’t too complicated and you include it as the textual alternative, it might work fine. But let’s see some other possibilities.

One might present the expression as two-dimensional preformatted text and include it using the pre element. This would be rather simple in our trivial case:

  x  
-----
a - b

In more complicated cases, you could use a sort of Ascii art like the following:

         b           
         /   f(x)    
         | ------- dx
         /  1 + x    
         a           

If you suggest a background color for pre elements, note that Netscape 4 uses that colors according to the lengths of the lines, not in a rectangular manner. You might consider padding the lines to equal length, using trailing spaces.

Several mathematical programs can format expressions that way for you, and you could just cut and paste them. Note that some markup, such as i for italics, is allowed within pre elements. And you need not be limited to Ascii; you could even use the special characters outside ISO Latin 1, in principle, though with special problems. Example (where the integral sign may or may not display correctly):

         b
              f(x)
         ∫  ------- dx
             1 + x
         a

In any case, the visual quality of this method cannot be very impressive. Moreover, it creates accessibility problems, since it’s gibberish unless seen in the exact preformatted way.

A table might be used to make an expression appear two-dimensionally. Such an approach could be seen as avoidable “use tables for mere layout”, though in a sense a table construct would reflect the structure of data, e.g. in

<table cellspacing="0" cellpadding="0">
<tr><td align="center"><i>x</i></td></tr>
<tr><td valign="middle"><img src="1px.gif" alt="divided by"
 width="100%" height="1"></td></tr>
<tr><td align="center"><i>a</i> - <i>b</i></td></tr>
</table>

x

a - b

Reasonable appearance might be achieved that way, with perhaps tolerably graceful degradation in text-only media: a simple character cell browser like Lynx would basically display it as
x
divided by
a - b
which might be understandable. But designing and writing suitable table markup would be rather awkward for nontrivial expressions.

It would be simpler and more natural to have a table with two rows only, using a bottom border for the first cell. The border would create a suitable horizontal line. However, in text-only presentation and in nonvisual presentation, the data would appear as
x
a - b
which can be difficult to interpret. This could be partly addressed by using a summary attribute for the table, e.g. <table summary="This is a fractional expression, with the numerator in the first cell, the denominator in the second">.

Let’s see what we could do with the integral above. Using a bit contrived table markup, we might get something like the following:

b
∫	f (x)	dx
	1 + x
a

In any simple text presentation, it would look rather awful, though. You might consider providing a separate link to an alternative presentation, for such reasons.

For a rather common case of a definition that is most naturally presented in two lines, this approach might work tolerably, for simple definitions:

Returning to simple examples, let us consider how we might present (a-b)/x two-dimensionally using style sheets, specifically the display property in CSS1 (cf. to ideas about removing redundant parentheses above). We would start from the simple linear notation (a-b)/x. We would put the parentheses and the slash each inside a span element containing that character only, and we would also use span for the numerator and denominator. Then, using class names assigned to the span elements, we would suggest in CSS the suppression of the display of those characters, presenting both the numerator and the denominator as a block, and underlining the numerator. This means markup like the following:

<span class="nom"><span class="lin">(</span><i>a</i> -
<i>b</i><span class="lin">)</span></span><span
class="lin">/</span>
<span class="den"><i>x</i></span>

.lin { display: none; }
.den, .nom { display: block;  width:100%; text-align:center }
.nom { text-decoration: underline; } 

This is what looks like on your browser:

And it degrades to (a - b)/x in non-CSS browsing situations.

We might still add
.den { line-height: 0.65; }
to reduce the spacing between the line and the denominator, so that the expression would look more natural. The value 0.65 is a compromise between good values for Netscape and IE; on IE, it doesn’t improve things much, and a smaller value would be better; but on Netscape, a smaller value tends to chop off the top of the text in the denominator. It gives the following appearance on your browser:

Note that if the denominator is wider than the numerator, you would like to overline the denominator instead of underlining the numerator. But unfortunately Netscape 4 does not support overlining, so you would have to invent something else, if you wish to cover it too.

We could consider other approaches too, such as using positioning with style sheets instead of tables. But it probably suffices to conclude with the following note:

In HTML, a rich set of mathematical symbols and some other basic notations can be used, but currently with accessibility problems that users need to solve. Two-dimensional presentation of expressions via HTML markup is currently trickery and handcraft, and quite often it is better to use images for such purposes.