On the use of some MS Windows characters in HTML

This document mainly discusses the following characters, which were risky to use in HTML documents for a long time and may still pose problems in some contexts:

The above-mentioned characters belong to the MS Windows character set, or Windows Latin 1, but not to the ISO Latin 1 (ISO 8859-1) character set. Many of them are punctuation marks (at least in a broad sense), like “smart” (curly) quotes.

The original MS Windows character set was later extended by adding the euro sign (€) as well as to Z and z with caron (Ž and ž).

This document is largely historical, but I have preserved it since there are many links to it and since it describes an interesting piece of history. Moreover, there are still situations (mostly non-HTML), where the character repertoire is limited to ISO Latin 1, so you may need workarounds for the characters discussed here.

Content

• The nature of the problems
• The characters
• Why do these characters appear on Web pages?
• Ways to present the characters
• Suggested substitutes

The nature of the problems

In the early days of the Web, authors who worked in a Windows environment often created problems to some users by using the MS Windows characters mentioned above. Typically, if an author naively typed a trademark symbol, a browser running on Unix or some other non-Windows system could display a blank instead of the trademark symbol, or something worse.

There was nothing wrong with the characters discussed here. They have their legitimate uses, and they are, as characters, part of many other character repertoires too, such as Unicode and ISO 10646. The problem was that it was not possible to use them completely reliably in HTML.

The main reason why the characters discussed here caused problems is that various attempts to present them created an illusion of working. When you created an HTML document and either consciously or unconsciously used, for example, the trademark symbol, you probably saw it correctly on your browser, and so will many others. But a large number of other people will see just a blank, or even have their display messed up by some control function. The images on the right are screen captures on Windows and on Unix computers, respectively. The situation has changed now, since browsers running on Unix were adapted to deal with the problem.

This is what you may get: This is what many others get:

Although the trademark symbol, for example, probably looks somewhat better than the result of using a replacement (like HTML markup <SUP>(TM)</SUP>, which looks like the following on your current browser: ^(TM)), the gain was rather small as compared with the damage caused when the vendor-specific method of presenting the symbol did not work at all, i.e. infor­ma­tion was lost. In some cases this did not matter much, while in others it was quite serious (see the examples). The effects varied; usually the problem character got replaced by a space, but other things could happen, too. (Bob Baumel’s document on special characters contains some examples of different behavior.)

The warnings applied to any cross-platform transfer of data. However, when data is transferred to a known system – instead of being made accessible from any platform – one can often use a suitable character code conversion program. For example, when transferring text data from Windows to Macintosh, one can handle some of the characters discussed here, if one correctly converts from the Windows encoding to the Mac encoding.

The above-mentioned problems have practically disappeared as regards to HTML authoring. Browsers generally behave so that if a document is declared to be ISO Latin 1 encoded but actually contains the MS Windows characters discussed here, browsers interpret the data as MS Windows encoded. But new problems have emerged, such as the following:

• automatic translation software may fail to recognize the quotation marks (and apos­tro­phes) correctly as punctuation and treat them as special symbols instead (so that e.g. “don’t”, when written with a typographically correct apostrophe, will not be recognized properly but left untranslated)
• speech-based browsers may have difficulties with the characters, since they generally recognize a limited repertoire of characters and read the rest by saying their names
• the text browser Lynx, when unable to display the characters themselves, presents their Ascii equivalents; while this is often adequate, it causes problems since the replacements should often be language-dependent (as explained later in this document) but Lynx uses a fixed replacement table.

The characters

The following table lists the characters we are discussing, i.e. the original Windows characters which are not ISO Latin 1 characters. The Windows and ISO 10646 names as well as code numbers are given, Windows code in decimal and ISO 10646 code in hexadecimal. The column “# ref.” contains the numeric character references (containing the Unicode code number in decimal) that can be used in HTML.

Notes:

• “quot. m.” is an abbreviation for “quotation mark”, used here to keep the table narrow enough
• The official spelling of ISO 10646 and Unicode names for characters is upper-case only. Here, as usual, mixed case is used for readability.
• What we call ”the Windows character set” here is officially registered at IANA as windows-1252. Unofficial synonyms include cp-1252 and WinLatin1.
• The Windows names for the characters listed in the table have been taken from the document Windows 3.1 Character Set written by Scott W. Adkins.
• The correspondence between the Windows and Unicode code positions as given in the above-mentioned document and listed here is the same as in the cp1252 to Unicode table (in the Online Data by the Unicode consortium).

Why do these characters appear on Web pages?

There are of course some reasons why the characters were are discussing were included into the “Windows character set” (as well to some other character repertoires). People who need a character tend to use it if they can. And many people are accustomed to using programs like MS Word where a large character repertoire is available. They usually just use any way of inserting special characters they need. (On MS Windows systems, a rather universal way of inserting the characters under discussion is the so-called Alt-nnnn method.) Normally they are satisfied when they see the characters presented on paper. So far so good.

The problem is that the internal encoding of the characters can be interpreted in different ways if the data is transferred to or processed in different programs and systems. For instance, if you use on Windows Alt-0151 to insert an em dash into a file and that file is transferred, without conversion, to a Unix system, anything may happen, Unix systems typically use some ISO 8859 encoding nowadays, and that means that the octet (byte) with value 151 in decimal is in the range reserved for control characters. Problems may occur even if you don’t transfer the file to a different computer. If you use e.g. the type command on the file at the DOS level, you might see something like ú (letter u with acute accent) instead of em dash!

On the Web, people use different browsers on different systems. Therefore, anything you put onto the Web is thereby “virtually” transferred to a huge variety of systems. Consequently, an HTML document for the Web should not contain anything that works on some operating systems only, no matter how common they are. Well, that was the situation for many years.

The problematic characters are often produced by different programs, such as HTML editors or converters. Naturally, they shouldn’t behave that way, but many of them actually do. It’s often a good idea to check that output from such tools does not contain any octets (bytes) in the range 128…159 decimal (200…237 octal). (A very simple C program could do that, for example.)

Ways to present the characters

The following table summarizes the most common attempts to present in HTML the characters we discuss here. For concreteness, the table shows examples of presenting a particular character, the em dash.

Presenting a character as “raw data” simply means that the character is presented as an octet (byte) or a sequence of octets according to the encoding used for the document. This is how most characters are actually presented in HTML documents. There is nothing mystical about it. (If you type characters from a keyboard using an editor, what normally happens is that you actually enter characters as “raw data” in some encoding; in some cases, you use some special methods for entering characters when they cannot be directly typed.)

The problem with the “raw data” method for the characters discussed here was that it works only for those browsers (and other user agents) that can handle data in the specific encoding used. There is a very a large number of registered character encodings (and many unregistered encodings, too). One can hardly expect Web browsers generally handle whatever encoding an author has decided to use. In the early years of the Web, the ISO 8859-1 encoding was the only encoding that could reasonably be expected to be known to any browser. Although the Windows encoding is very widely used, browsers running under other than Windows systems did not always support it. On the other hand, browsers running in Windows environment usually treat documents according to the Windows encoding, if the server does not specify the encoding or if the encoding is specified to be ISO 8859-1.

In principle, if the “raw data” method is used, the server should send an HTTP header which specifies that the encoding used. When octets are to be interpreted according to the Windows encoding (e.g. octet 151 means em dash), the server should send
Content-Type: text/html;charset=windows-1252
However, for reasons explained above, such headers usually don't make browsers process the data any better than they would be default.

The problem with notations like — was that their meaning was undefined, i.e. anything could happen. In practice, users mostly saw an em dash, but they might alternatively have seen perhaps a space, perhaps nothing – or perhaps the screen got messed up. After all, in ISO Latin 1, code positions 128…159 have been reserved for eventual use as control codes ("control characters"), and they might actually be used that way in some environments.

At present, practically all browsers support the following three methods, which have been defined in HTML specifications since the 1990s:

• Use a (numeric) character reference of the form &#n; where n is the code number, in decimal, of the character in Unicode and ISO 10646.
• Use a hexadecimal character reference of the form &#xn; where n is the code number of the character in the hexadecimal (base 16) number system.
• Use a “symbolic” entity reference of the form &name; which is defined for some characters, including those we are discussing here. There is a handy reference HTML 4.0 Entities by WDG; see its section on Special Entities for most of the characters discussed here.

If you decide to use characters like em dashes, en dashes, and “smart” quotes, make sure you use them properly, according to the rules of the natural language you write. It’Ms easy to go wrong here, since there have been breaks in typographic traditions, when those characters have been (and still largely are) avoided when producing texts on computers. For dashes in particular, see some usage notes in Dashes and hyphens.

Notes on tricks for the em dash

For the em dash character in particular, different tricks have been suggested and used. This character looks so simple that people have thought that there must be a way to fool browsers into displaying something like that even if the character itself is not available.

As regards to the em dash in particular, Andreas Prilop has mentioned an interesting possibility:
<TT>-</TT>
(He also mentions <FONT FACE="Symbol">-</FONT>; although that might give an even wider glyph, it relies on the user's system having a font with a particular name, whereas the TT element is universally supported.) This particular method essentially consists of using a hyphen (-) as surrogate for em dash but with a presentation suggestion to display it using a font where the glyph for hyphen is expected to be wider than a normal hyphen. Although it often creates a good presentation, it has been said that in the hyphen character of some monospace fonts looks bad especially in the midst of normal text.

Yet another approach is to use two consecutive hyphens, with a style sheet suggestion to reduce the spacing between them, hoping that they will look like a dash. This would apply to situations where “--” is an acceptable surrogate for a dash. For some odd reason, some versions of Internet Explorer were immune to the style rule in this particular case, unless you used the nobr markup. Here is what your browser presents when the construct <nobr class="dash">--</nobr> is used with the style sheet .dash { letter-spacing: -0.1em; }: --.

Various other hacks have also been suggested, such as using a few no-break spaces within a STRIKE element to "construct" an em dash! I have prepared a small test file containing examples of and annotations on such attempts as well the above-mentioned methods.

Suggested substitutes

Whenever you need a character and can’t use it, you need to consider substitutes. For the characters discussed here, relatively good substitutes can be found. As described in this document, these substitutes are hardly needed any more in HTML authoring, but they might be needed otherwise.

Notes:

• To simulate ellipsis, you might wish to use CSS in order to suggest a presentation of “...” that resembles typographers’ ellipsis, i.e. where the dots have somewhat more spacing between them than what you normally get. E.g., you could have
  <style type="text/css">
.ellip { letter-spacing: 0.08em; }
</style>
and
  <span class="ellip">...</span>
• If dagger would be used as the symbol of year or date of death, due to its cross-like appearance, the suitable substitute is of course a word like “died” or abbreviation like “d.” in the language used, or perhaps the symbol “+” (used in some contexts)
• If o/oo is used as a substitute for permile (more correctly “per mille”, which means “per one thousand”) then perhaps one should similary use o/o instead of % for stylistic uniformity. Please note that a speech generator, unless programmed to handle o/oo in a special way, would probably read it pronouncing “o” as a letter and “oo” as a word (or as two letters)! A more logical alternative to o/oo might be to use zero instead of o and try to make the presentation better-looking by using SUP and SUB:
  <SMALL><SUP>0</SUP></SMALL>/<SMALL><SUB>00</SUB></SMALL>
  (This looks like the following in your current browsing situation: ⁰/₀₀). The main problem with this is that on many implementations, the use of SUB and SUP causes uneven vertical spacing between lines; using SMALL too seems to help a bit. There’s also the possibility of using just 0/00 with FONT SIZE="1" markup for the digits, giving the following appearance on your browser: 0/00. In any case, it is best to put a no-break space between a number and a per mille symbol or its substitute; otherwise there's the risk that something intended to denote one thousandth looks like 10/00.
• For s Hacek, the officially recommended substitute in Finnish is sh (which of course is to be written as Sh if it would be S Hacek, or as SH in uppercase-only text). In Czech texts presented in ISO Latin 1 on the Web, it seems to be usual to simply omit the diacritic, thus presenting s Hacek as s.
• For the bullet character, asterisk (*) or hyphen (-) would be a suitable surrogate in typical cases; the letter o is often used, but this implies the risk of being read as “oh” (especially by automatic speech generators). But consider whether you need the bullet character at all. Usually the “need” for it arises from illogical markup which tries to construct a bulleted list, instead of just using adequate markup: the UL element
• As regards to substitutes for dashes, there are different practices in different languages, and perhaps even different recommendations. For the English language, according to Grammar, Punctuation, and Capitalization; A Handbook for Technical Writers and Editors by Mary K. McCaskill, the recommendation is:

  In typewritten material, the em dash is represented by two hyphens with no space around them, and an en dash is represented by a hyphen.

  and it seems natural to apply this to material where em and en dash cannot be used. (For example, for the Finnish language, there is an official recommendation which deviates from English practice: a single hyphen is used as a replacement, in many cases surrounded by spaces.) You might consider using font-level markup to suggest that a hyphen used as a surrogate for dash be displayed in a particular font (to make it look more like a dash).
• Y dieresis is needed very rarely if ever. The lower case y dieresis (ÿ) is in ISO Latin 1, probably because it it is used in French in some names like L'Haÿ; the dieresis (trema) there indicates, as usual in French, that each vowel keeps its own pronunciation. In such usage, ÿ cannot occur at the beginning of a word, so an uppercase Y dieresis would appear in French names only if they are written in all caps and preserving the diacritics. In HTML authoring, caps-only is hardly needed, since one can (and should) should use logical markup (like H1 and STRONG) instead. On the other hand, it has been reported that y dieresis is used as a ligature for ij in Dutch. This probably means that ÿ is used as a surrogate for a real ij ligature (which exists in Unicode). Thus, anyone intending to write a Dutch word using a ligature for IJ should really type just IJ. (In situations where support to Unicode could be relied on, the real IJ ligature, U+0132, could be used.)

The article Window[s] Characters and HTML, based on an early version of this document, was published in Boardwatch in June 2000. The tone of this document was changed, as support to the use of these characters became essentially wider. In 2017, this document was revised to use largely past tense.

If you found this document useful, you might wish to check other documents on character problems in Web authoring by the same author.

Note to Finnish readers: Tämä dokumentti on laajennettu versio suomenkielisestä dokumentistani Mikrojen merkistöjen aiheuttamista ongelmista Webissä.