This note surveys support for display of Hebrew script in several Web browsers. In particular we do not review the ability to send Hebrew input via forms. We also survey HTTP content negotiation features that may be helpful in receiving content that the browser can process well.
The following features were tested
title element, and alternative text to images.accept-language and accept-charset HTTP request headers.You may also like to read the Very quick overview of standards related to Hebrew and the Web, for clarification of the above.
All tests so far were conducted under English Windows 95 with Hebrew enabled. However, the results should be similar without the Hebrew support in the operating system. I intend to put an online test suit, to enable further testing by others.
Internet Explorer has the best support for Hebrew among the browsers tested. It displays correctly documents in Hebrew written according to the standards, and in addition makes educated guesses that allow it to render the majority of poorly written documents as their authors intended. It has rather annoying bugs concerning the title element and alternative text to images.
Internet Explorer also has a controversial feature of placing the scroll bar on the left in right-to-left documents. This is rather confusing as users consider the scroll bar as part of the user interface of the browser and not a part of the document. The confusion is increased as many Hebrew documents are encoded visually with left-to-right directionality. So some Hebrew documents have their scroll bars on the right.
Tango has support for bi-directionality, and will also render correctly visually encoded documents, if they are labeled with ISO-8859-8. However, it is quite far from following the standards. In particular it does not support overriding the bi-directional algorithm.
The evaluation version that I tried in April 1999 was dated 1997, which indicates that development of this browser has effectively stopped. As a somewhat oldish browser it does not support the div element, which many visually encoded document use to align text to the right.
On the other hand, Tango has several advantages over Explorer. One is its ability to input Hebrew characters (in forms) even on non-Hebrew aware systems. (I did not test this feature). Another is its modest system requirements.
The various versions of Lynx that I tested gave uniform results. Lynx dos not support the bi-directional algorithm but renders very well visually encoded documents. Like the two browsers discussed above its support for character references is excellent as well. Lynx also supports the Accept-Charset HTTP request header which allows users to show their preferences for visually encoded documents.
Unfortunately, many visually encoded documents in Hebrew use left-to-right tables to arrange text in columns. This mixes the order of the text in Lynx that shows the cells' content in a sequence and not side by side. Another inconvenience is that in visually encoded documents the tabbing order between links is incorrect for links that lie on the same line.
Netscape is very disappointing for its support of the Hebrew script. It does not recognize the ISO-8859-8 encoding and its variants, and does not support character references. Support for BiDi in Mozilla is in progress.
Visually encoded documents in ISO-8859-8 may be viewed in Netscape by using the "Hebrew hackers' font". This font pretends to be a Latin font but has glyphs of Hebrew characters as if it is a font of ISO-8859-8.
This method has severe disadvantages that include the inability to render correctly accented Latin characters in a Hebrew document. Another great disadvantage of the "Hebrew hackers' font" is that these fonts are of generally poor quality and may cause damage to one's eyesight if used often.
Opera's support for Hebrew is non-existent. The "Hebrew hackers' font" trick works for it too. In order to toggle quickly between this font and the settings for Latin based scripts, one can use a short user's style sheet that assigns the hackers' font.
n.a. stands for "not applicable"
charset parameter)| Explorer 5.0 | Tango 3.3.1 | Lynx 2.7.2 and 2.8.1 | Netscape 4.51 | Opera 3.51 | |
|---|---|---|---|---|---|
| ISO-8859-1 | yes | yes | yes | yes | yes |
| ISO-8859-8 | yes | yes | yes | no | no |
| ISO-8859-8-i | yes | yes | no | no | no |
| Windows-1255 | yes | yes | yes | no | no |
| UTF-8 | yes | yes | yes | yes | no |
Explorer 5.0 and Tango 3.3.1 recognize the five different character encoding tested. Lynx does not recognize ISO-8859-8-i which is identical to ISO-8859-8 but is used to label logically encoded documents. Netscape 4.51 does not recognize any of the 8-bit encoding that allow a single byte coding of Hebrew characters, and is therefore quite useless for interpreting documents whose main language uses the Hebrew script. Opera 3.51, as an HTML 3.2 browser, supports only ISO-8859-1.
| Explorer 5.0 | Tango 3.3.1 | Lynx 2.7.2 and 2.8.1 | Netscape 4.51 | Opera 3.51 | |
|---|---|---|---|---|---|
| direct | yes | yes | yes | yes | n.a. |
| decimal | yes | yes | yes | no | no |
| hexadecimal | yes | yes | yes | no | no |
Explorer 5.0, Tango 3.3.1, and Lynx support Hebrew characters both encoded directly in the the encodings that allow for that, as well as using numerical references. Netscape 4.51 supports directly encoded Hebrew characters in UTF-8. In the same encoding it supports also numerical references. Opera 3.51 does not support Hebrew characters at all.
| Explorer 5.0 | Tango 3.3.1 | |
|---|---|---|
| Applies bi-directional algorithm | yes | yes |
| Supports bi-directionality override | yes | no |
| Assumes ISO-8859-8 means visual | sometimes | yes |
Only Explorer 5.0 and Tango 3.3.1 support the bi-directional algorithm. Explorer's implementation is more complete as it supports overriding the algorithm with the bdo element as well as with Unicode's BiDi override characters.
Many documents in Hebrew are written visually in ISO-8859-8 in a non-standard way, namely without overriding the bi-directional algorithm explicitly as the HTML specification requires. Explorer guesses the author's intentions. For example, if a document labeled with ISO-8859-8 starts with <html dir="rtl">, it will process the document according to the standards. Tango 3.3.1 always assumes that ISO-8859-8 means visual, and assumes left-to-right directionality to all characters. In documents labeled with ISO-8859-8 it gives some honor to the dir attribute as far as alignment of text and position of list item markers, etc.
| Explorer | Tango | Lynx | Netscape | |
|---|---|---|---|---|
| <title>text</title> | no | yes | yes | no |
| <img alt="text"> | no | yes | yes | yes |
| <link title="text"> | n.a. | n.a | yes | n.a. |
Explorer 5.0 and Netscape 4.51 rely too much on the operating system in displaying the content of the title element. Explorer 5.0 has bugs in the bi-directional algorithm in alternative text to images.
| Explorer | Tango | Lynx | Netscape | Opera | |
|---|---|---|---|---|---|
| Accept-Language | yes | yes | yes | yes | no |
| Accept-Charset | no | no | yes | no | no |
With the exception of Opera 3.51 all browsers tested support the accept-language HTTP request header. Lynx allows for full configuration of this header. Tango thinks that the code for Hebrew is iw, so users should choose a user defined code he.
Among the browsers tested only Lynx supports configuration of the accept-charset request header. Users may use that to request documents encoded in ISO-8859-8 rather than in ISO-8859-8-i in order to show their preferences for visually encoded documents. Netscape sends an Accept-Charset header in requests but does not allow its configuration.