Back to Unicode. Even Unicode needs room to expand. The Basic Multilingual Plane (BMP, also known as Plane 0) has codepoints 0 through FFFF hex (0 through 65,535) and contains, ignoring various special mathematical characters, historical quirks, and just plain oddities, most of the current alphabets and symbols in use today, even including the vast array of Chinese kanji. But of course there’s more room needed once historical alphabets and other special character sets are also considered. Supplementary planes such as Plane 1 are simply sets of 65,535 code points following Plane 0 (some of us refer to these as astral planes ). Using hexadecimal notation, it’s easy to spot Plane 1: all Plane 0 codepoints use four hexadecimal digits; all Plane 1 use five, etc.

Here is an example of a Plane 1 character: 𝔊 which renders as 𝔊 (marks a septaugint reference). In case anyone viewing this is having trouble, here’s an image:

To set things up to view this can be an interesting process. First of all it’s necessary to find a unicode font that supports plane 1 characters. Not all such will actually show the above, for example Code2001, an otherwise excellent unicode font, does not include historical Greek musical notation however Cardo works nicely. Just because a font is unicode based does not mean it will be “complete” (such a font would be staggeringly large). In particular, when choosing among unicode fonts, pay attention to which version of unicode is being supported, and what the target languages are. Plane 1 characters start to appear in Unicode versions 3.2 and up.

Second, the operating system might need slight adjusting to see Plane 1. I’m talking, of course, about Windows, XP and earlier versions. This page discusses how to do the registry edits necessary both for the operating system and for IE6 .

Linux/*nix, Mac, and Vista are all presently able to handle Plane 1 without modifications. My understanding is that for Windows Me and anything prior to NT, it’s hopeless.

Third, applications in general and browsers in particular may need slight tweaking to see Plane 1 characters. As usual, IE6 is the worst offender in this regard requiring not just setup but also a registry edit. In general, once the browser is set up with a Plane 1 aware font, it’s good to go. Firefox, Safari, Opera, and Konqueror all fall under this category.

A few notes: IE6 needs to be set to user-defined encoding plus the extended font needs to be listed under User Defined (rather than any of the specific regions listed, which refer back to non-unicode encodings as discussed in part 1). Opera actually reverses from the general MO of other browsers: under Tools->Preferences->Advanced->International Fonts, it’s possible to set a particular unicode font to a particular language (going by Unicode’s code blocks). This is the direction other browsers should no doubt take in the future.

In the course of putting together the encodings (called code points) in Unicode, a number of decisions had to be made regarding the current existing encodings, particularly well known and/or well established ones. In some cases, even though the Unicode Consortium has a particular policy regarding some encode vs render issues, there are inconsistent inclusions due to this grandfathering of prior established encodings and (to be quite honest) outright mistakes on the part of the Consortium. The question of precomposed characters versus combining characters is a classic one.

As a simple example, let’s take the greek letter alpha — ά — with an acute accent. Should this be represented as ᾅ or as ᾅ? (See here and here for the code charts.) In other words, should a single fixed code point be used to represent something that’s really a combination of a letter and an accent, or should there be a code point for the letter and a code point for a combining accent which is then combined with the previous letter?

My two cents worth is that since the concept of an accent applies to more than one character, it is an independent concept, and thus combining is the way to go. Not to mention more economical — with this approach, to add an accent to any other character requires only one additional code point in the charts. Implementing it the other way means for each character that might be accented, a second code point must be reserved — and as that cannot possibly be comprehensive, it will be by nature reserved to “legal” or “existing” combinations at the very least. So why are both present? That’s the grandfather clause at work, since the concept of combining characters postdates the establishment of many of the old encodings. But philosphically, the Unicode Consortium’s wise enough to agree with me

Now suppose a web developer needs to represent some manuscript online. The texts may themselves contain “mistakes” which are intended to be reproduced as is. For example, in (ancient) Greek, an epsilon will never be combined with a circumflex due to the rules of the language. But perhaps an idiosyncratic author did so anyway, or a manuscript is badly marked up, etc. If the only encoding at hand for ancient Greek contained only the “legal” stuff, I’d be out of luck if I needed to show this. Given this, clearly the use of combining diacritics makes every sense. While there is no precomposed character for epsilon-with-circumflex, I could still use ε͂ to represent this — ε͂̂ …

But wait! That’s not quite the end of the story! Not all browsers are good about combining diacritics. It’s actually something of an artform, and the positionings will depend whether the base letter is small or caps, and whether there are other diacritics also being combined with it. Frankly, most browsers don’t cope so well. So to get a usable display in as many cases as possible, I find it worth scanning ahead in the text to find all the associated diacritics and checking for the existence of a precomposed character before attempting to do it through building it up.

Test Case

Let’s take an interesting example here:
That is an alpha with a rough breathing, an acute accent, and an iota subscript.
If the alpha is uppercased, it looks like this:
Notice how the positioning of the iota subscript changes when alpha is capital, and both the breathing and the accent sidle a little to the side to get out of the base letter’s way.

I’m going to demonstrate how this pair of letters looks in precomposed versus combining notation in assorted browsers and operating systems. First of all here’s the table I used to build up my examples. The first column has the precomposed character for each of the above images. The second has the base character plus the combining diacritics for the above images. The diacritics are in “proper” order. This order is particular to each language, and in this case the order is supposed to be breathings-accents-iotas and that is what drives the order you see in the final representation — the breathing will always be to the left of an accent, and so on. The third column has the diacritics in reversed order. This is a very interesting situation that I don’t believe has yet been well enough assessed. I don’t even know that it should be: just as it’s reasonable to expect words to only make sense if their letters are ordered properly, it could be just as reasonable to expect diacritics to be listed in proper order. On the other hand, it might be reasonable for some programs (especially a word processor) to order them properly — these are computers and can churn out a few more CPU cycles, after all. I found it very interesting how badly handled this third column was, so I included it for interest’s sake.

There are several things to note here. First of all, particular diacritics, depending on the language of course, have particular positions. Some combine below, some along the top, some to either side and some as “overstrikes.” In addition, if there are multiple diacritics that are positioned similarly there is usually an order of precedence. Finally, if the letter is capitalised, that often affects the placement of the diacritic. In the images above (and in the table, if your browser is working correctly) the iota subscript moves to the side of the capital alpha.

First up on the chopping block: Internet Explorer (IE6 and IE7):

	IE6 (SP2)	IE7 (beta 3)
Windows XP SP2 w/Cardo
Windows XP SP2 w/regedits & w/Cardo
Vista (beta 2) w/Cardo	n/a

I will admit I was surprised at how well Internet Explorer did here when it’s usually so miserable at dealing with odd things, especially internationalization issues. However, do notice that it’s clear MS didn’t consider the case where the combining characters might not be “in order”. In the third column, the diacritics along the top haven’t been properly spaced from each other, nor are they shifted slightly in the capital letter version. And the iota fails to adjust to the capital letter.

Moving along to Firefox and Opera, we have the following table:

	Firefox (1.5)	Opera (9)
Windows XP SP2 w/Cardo
Windows XP SP2 w/regedits & w/Cardo
Vista (beta 2) w/Cardo
Linux (Ubuntu 6.06) w/Cardo
Mac 10.4.7 w/Cardo

What I find very interesting is how the registry edits for Windows XP improve both Firefox and Opera’s ability to display combining characters properly. However, this ability immediately disappears in the tricky third column.

I’m surprised by Opera’s complete failure to try combining the characters on the Mac, especially since it did combining in both Windows and Linux. Note that it simply listed each after the base letter in the order given in the table. Opera lets you define which font you want to use for the ‘Greek and Coptic’ and the ‘Greek Extended’ blocks. Now, I’ve set Cardo as my default font for everything, so that should override anything that’s there. “Should” being the operative word. Here’s the problem: I go to Preferences –> Web Pages –> Normal Font and I select Cardo there. However, this doesn’t seem to affect the display of Greek text in Mac Opera. This is odd, since it does affect the display of Greek in Linux and Windows Operas. I can instead change the display of Greek text in MacOpera by going through Preferences –> Advanced –> Fonts –> International Fonts and there selecting ‘Greek’ as the ‘writing system’. However, Cardo is not listed here. And since ‘Greek’ is actually Opera’s name for the ‘Greek and Coptic’ set, to make sure I can render all of Polytonic Greek correctly I also have to select ‘Extended Greek’ as the writing system. Cardo is not listed there either. Why is it not listed there when it’s clearly installed and is available system-wide? I do not know.

Let’s check the last two browsers of interest: Konqueror and Safari:

	Konqueror (3.5.2)	Safari (2.0.4)
Linux (Ubuntu 6.06) w/Cardo		n/a
Mac OS 10.4.7	n/a

I’m giving Konqueror bonus points for the creativity it shows in vertically stacking the rough breathing and accent. Unfortunately, it’s completely invalid on technical merits. The iota subscript isn’t even underneath the base letter, either. Konqueror needs to completely fix this aspect of their rendering engine. Surprisingly, though (and I say that because Konqueror and Safari both share the KHTML rendering engine) Safari comes out a winner here, rendering the combining characters correctly.

So what I see here is IE6 (shockingly enough), IE7, and Safari handling the combining characters the best. I say that because both of them are able to render the test cases properly without any outside modifications. Firefox’s correct rendering on Windows with regedits but not on any other operating system, nor on Windows without regedits leaves me to believe the credit lies not with the browser but with whatever effect the registry edits has on Windows. Still it did a decent job and it handled the reordered combining letters no worse than the properly ordered combining letters. Opera was neck to neck with Firefox for all the same reasons, but fell behind for its odd handling of the test cases on the Mac.

Konqueror and Safari wind up being the most puzzling since they use the same rendering engine. In theory, then, if one works, so should the other. I may try to rustle up other versions of Konqueror on other Linux distributions and if anything else might be going on.

Microsoft’s Registry Edits

Microsoft details up to three registry edits that are necessary to to set up Windows NT, 2K and XP for unicode functionality. (Vista comes already set up, and does seem to actually work.) The first edit is the most important. It enables Uniscribe support which is what Windows applications use in order to be able to render Unicode characters. It’s responsible for rendering input text, for substituting character variations according to context, and for ordering displayed text based on text flow direction.

The second registry edit adds support for the supplementary plane characters in IE (which I will cover in the next post). The third adds the ability (in Win XP only) to specify a default font for supplementary plane characters.

Presumably the first edit is what enables Firefox and Opera to be able to handle combining diacritics. I’m at a loss to explain IE6’s behavior, unless a fairly recent patch to it enables the same thing. Unfortunately, I don’t have an earlier unpatched IE6 to test that theory out with (if I’m correct, such an earlier version of IE6 would need this registry edit to display properly). Installing certain language packages will also install the Uniscribe module “behind the scenes,” but as I had the same language packs before and after adding the registry edits, that doesn’t explain this either.

The full instructions for doing the registry edits may be found here.

Excellent Resources

For much more informative commentary, check these pages out:

• Benefits of the Unicode™ Character Standard
• Character Sets And Code Pages At The Push Of A Button
• More about the character concept (the entire article is excellent as well)
• Combining Diacritical Marks

In the beginning was ASCII, at seven bits. And it was good, until someone noticed a few missing characters. In this way, ASCII with eight bits was born. But alas! There were even more characters to be respresented. And thus began the exodus in search of ways to show these missing characters.

And the way split and conmingled between encoding and rendering. After all, since no encoding existed for some characters, those attempting to render them on the screen made up their own encodings as they went. And things continued in this sorry mess for years, until Unicode was born…

Of course at this point, now various different programs such as mailers, forums, word processors, internet browsers and even programming languages all are in the process of being updated to understand unicode. It’s a giant bear of a mess along many fronts, although I do believe Unicode is the way forward, the essential problem is that it’s been introduced at this point instead of at, say, the point ASCII originally came on the scene. But no matter, things will sort themselves out. Over the years and years, but hey.

So what, exactly, am I talking about? In order to represent the alphabet, two things are needed. First is a kind of representation that says which character we’re talking about. So for example (decimal) 65 is used to represent the letter ‘a’. The second kind of thing is whatever is used to render ‘a’. It could be a, or a or a. These two things are the encoding and the rendering of a given character. Conceptually these two properties of a character should be distinct. In practice, of course, it’s not always been that cleanly handled, and there are some issues where the lines are legitimately blurred.

The problem was, of course, that the original encoding table (ASCII) was much too limited to handle languages other than English. To address this, a number of ISO 8859’s were developed to cover additional characters such as ß or ñ and other marks and symbols such as © and £. However, since rendering (or typography) was not considered in these representations. a number of legacy fonts developed that used additional proprietary (and conflicting) encodings for additional information not covered in the standards. And in all of this, languages that did not even use the Latin alphabet (such as Greek, Russian, Arabic, Hebrew, Japanese, Chinese, and so on and on) were definitely ill-represented overall. In most cases there are several possible representations and standards to use, which results in a nightmare for anyone trying to represent extended or other character sets in programs that make use of them. (Which basically potentially includes any program which ever tries to communicate with its user in anything other than international symbols, but I digress.)

Unicode

The idea behind Unicode is to create one giant encoding standard for all of this (leaving the typography alone and up to whatever rendering a particular program wishes to use, or whatever font set the user has installed). Sounds simple enough although even this idea is fraught with complexity and inconsistencies. For example Unicode absorbed many of the original encoding standards in order to ensure backward compatibility; and has made various inconsistent decisions on the inclusion of other characters in different ways. However. the underlying concept is sound, and if it takes another twenty years to refine it, the end result should still be better than the cacaphony there is now.

Enough with the background. I want to discuss most of this in the context of browser rendition, since this is a good deal of what I work on anyhow.

Let’s take a quick look at this:

I have it up here as an image to guarantee that everyone here can see this word. (I should note, by the way, that I picked this word out at random, but I do not know ancient Greek. When I looked it up, it turns out it’s an adjective meaning “eager to be of service”, which I find vastly amusing.)

In Unicode, I could encode this as follows:
πρόθυμος
I am using Numeric Character References here, instead of raw UTF-8, mostly because IE6 expects such representation although in theory either should be acceptable and certainly Firefox, Safari, and Opera are all happy with either. The codes can be found here and here.

In any case the above should render similar to the image above:
πρόθυμος (NCR)
I could also put it down like this:
πρόθυμος (direct UTF-8)
but Internet Explorer may not render this correctly.

Now if it did not, there are several considerations to check.

The first will be whether or not the page itself is correctly set up for viewing Unicode. Since I’m the one running this show, of course it is. There needs to be a declaration at the top something like this:

<meta 
    http-equiv="Content-Type" 
    content="text/html; charset=UTF-8" 
/>

Since I can eliminate that as a problem off the bat, the next consideration is the browser being used to view this. All the modern browsers (meaning: Firefox (all OS), Opera (all OS), Safari, Internet Explorer 6 (latest patches), Netscape 7.2 plus and derivatives) should understand this. Some of the older ones may not. In particular IE on the Mac never contained Unicode support. In many cases, setting several menu options may be necessary to enable the support — check the documentation for the particular browser for “character encoding”. For IE, check the “user-defined” options. View->Encoding needs to be set to user-defined, and then in the Internet Options, a suitable font needs to be selected for the “user-defined” font (eg, not the Latin, etc fonts).

Different browsers will support unicode at different levels. For example, on IE6, it’s not only necessary to enable the character encoding support, but also to do certain registry edits for both the browser and the operating system (IE7 appears to contain more support for Unicode, fortunately). Firefox and Opera only need to be informed of a compatible font. Safari actually breaks down the “unicode” fonts into the different regions on the (very reasonable) assumption that one might use different unicode fonts for different languages and not some “universal” unicode font. So in Safari, setting the unicode “Greek” to the correct font will allow the above to display.

A good font for the above display that I would recommend the Cardo font. There are several out there, including Arial Unicode MS, but I do not recommend this or any of the older ones, as support is only to version 2.0 of the Unicode standard, and we’re well past that now. I’ll return to this point later on. For now, I’m going to detour briefly into legacy fonts, just to illustrate why they were such a bad idea.

Legacy Fonts

I’m not even going to render them on this page . Actually, I cannot render them in this page, because they require different meta declarations, i.e.:

<META http-equiv="Content-Type" 
          content="text/css; charset=ISO-8859-1"
/>

In any case, the representations for the above word in these fonts, respectively, are

<font face="Greek Old Face 98">prÒqumoj</font>
<font face="Athenian">prñyumow</font>
<font face="Ismini">pr¿uymoq</font>

Note the need to explicitly switch font face in order to obtain the results I want. Unless the entire page will be rendered in one of these fonts, I have to switch around as needed. Unicode simplifies all of this, and theoretically given sufficient support (a unicode keyboard, unicode display in the editing software, etc) I would not even need to use the numerical character representation of specific characters. However, as I cannot guarantee all visitors to this site would be similarly equipped, this is a fallback for now (and indeed, since I — nor anyone — will never have a keyboard that includes all the possible alphabets and symbols for non-alphabet languages, this kind of workaround will always be needed anyway).

Interestingly, some of the newer browsers themselves have bugs in attempting to handle legacy fonts. For example Firefox had trouble with the style font-family method of switching between fonts, but was able to display correctly once it was changed to inline font face notation.
So

<font face="Greek Old Face 98">prÒqumoj</font>

Minor note on WordPress

This is getting lengthy and I still have more stuff I want to discuss, so I’m going to wrap up here and finish the rest in the next post. But I thought I’d point out that somewhere along the line in the course of editing and re-editing this post, the NCR’s I was using to illustrate the various unicode words and such above kept getting rendered into their UTF-8 representations. I wanted NCR’s for several reasons, partly because it allows me to reference the Unicode Manual on which ones they are, but also because some browsers require NCR. But somehow, and I’m not sure if it was internally in WordPress or some combination of cut and paste in either Windows XP or Ubuntu that did it, but it’s a classic example of the annoyances that are still present when dealing with “exotic” character sets.

When I’m checking to see if my web pages work across various platforms and various browsers, I don’t have to start out by going through and checking how they appear in an all encompassing, exhausting review using each and ever on any and all. If I hit the four main engines in the order of their percentage of use: Trident, Gecko, Presto (Opera), and KHTML, I’m in a very good position. Granted, for more troublesome nit picky detail, it is possible for two different gecko-based browsers to have different problems with some bit of HTML or CSS or JS or other, but in the main, I’ve likely shaken out all the major glaring problems in the most efficient manner.

Knowing that Safari has the lion’s share of the Mac OS lets me ensure that I’ve taken care of the majority of Mac users by checking with that one. If there’s some issue with MacIE, I can pretty much leave it alone or let it degrade. Or if I’m pressed for time, I can choose Safari over MacIE or Camino or Mac Firefox and get pretty good Mac coverage.

Speaking of which, I’m aware that this blog doesn’t display well in Safari. I’m hoping to have some time on a borrowed Mac soon to figure out why.

Rendering Engines

Before I get going, however, I want to cover the rendering engines, because they are the underlying reason why some browsers can be considered “related.” Browsers are generally constructed as two separate parts: a front end that the user sees — the graphical interface, tools, etc; and a back end that does the messy work of taking an HTML document sent by the connecting site and laying it all out (“rendering it”) on the screen for the said user.

Trident

Trident is the rendering engine for Internet Explorer, from IE4 onward. It was first introduced in October 1997 and remains in use today. For IE7’s release, Microsoft is making significant changes to Trident to improve web standards support. However, despite these changes, Trident remains significantly less compliant than competing rendering engines, even though it is argubly the most used engine due to Microsoft’s share of the OS market.

Gecko

Originally created by Netscape Communications Corporation, its development is now overseen by the Mozilla Foundation (details below), Gecko is the open source, free software web browser rendering engine used in Netscape, Mozilla, Firebird, and other browsers. It is written in C++ and supports open Internet standards.

Gecko is cross-platform and works on Windows, Linux and Mac OS X. Gecko is generally considered to be the second most-popular layout engine on the Web, after Trident.

KHTML

The KDE project developed KHTML as its the rendering engine and introduced it with KDE2 in 2000. It’s written in C++ and licensed under LGPL and supports most web browsing standards plus various quirks and oddities peculiar to IE6 in order to render as many pages as practicable. It’s a fast rendering engine that is primarily used by KDE Konqueror and Apple Safari. More recent versions of OmniWeb and other browsers have also made use of it.

Browsers

Lynx

Of all the non-graphical browsers, Lynx is probably the oldest and best known. The University of Kansas had written a hypertext browser independently of the web, called Lynx, used to distribute campus information. A student named Lou Montulli added an Internet interface to the program, and released the web browser Lynx 2.0 in March, 1993. Lynx quickly became the preferred web browser for character mode terminals without graphics, and remains in use today.

Mosaic

The first real browser was NCSA Mosaic, which appeared in November of 1993. It was available on both Windows and Unix X Windows and then within a few months, Macs as well. Since there were no background images available, all web pages had a gray background. However, it introduced inline images, forms support, and bookmarks and quickly became the most popular non-commercial web browser. In August 1994, NCSA assigned commercial rights to Spyglass, which subsequently licensed several other companies, including Microsoft for Internet Explorer. Mosaic at this point is completely deprecated and no longer supported (as of 1997), although the source files are available to anyone who is curious enough to play around with it.

Netscape and derivatives

A year after Mosaic’s debut, Netscape Navigator 1.0 through 4.8 (commercial) introduced more, such as tables, frames, javascript, mouseovers and so on. In these early days browser development occurred at a much faster pace than the agreements on HTML standardization, which accounts for many of the nonstandard features that are still available to this day. Netscape in particular captured a large share of the market at this time because of its (nonstandard) extensions which allowed people to put together flashier websites (and to view them). This prediliction for extensions included javascript; at one point Netscape and Internet Explorer in effect each had their own versions, before DOM came into the picture. This period is often referred to as the Browser Wars.

Because of the AOL buyout, the rewriting, and the last minute decision to integrate a completely new rendering engine, NN 5.0 never actually appeared. Instead, 6.0 was released in 2000, forced to do so by AOL before the rendering engine was mature enough. With these factors, it slipped badly in the race it had been in with IE up to then. Netscape 7.0 (finally dropping the “Navigator” from its name) was released in August 2002, Netscape 7.1 in June 2003, and version 7.2 a year after that. Up till this time the emphasis had been on building a big bulky “kitchen sink” browser, with mail support, IM, and so on all crammed together. AOL has continued the Netscape line in 2005, renaming it Netscape Browser in version 8.x, but dropping the suite and supplying just a browser.

Netscape’s greatest impact on the overall development of browsers and rendering engines (and argubly its own demise) occurred when it released its source code in 1998 and entrusted its development to an internal department, Mozilla (named in tribute to NN 1.0’s codename). Thus was born the open source Gecko rendering engine, which supported HTML 4.0, CSS1, XML and the DOM as specified in W3C standards. Netscape had used its own proprietary rendering engine in versions 1-4. For the 6.x and 7.x series, the browser was based on Gecko. For the 8.x series it is based both on Internet Explorer’s Trident engine, Mozilla’s Gecko, and Firefox’s XUL, a markup language developed by Mozilla and itself a continuation of the Gecko development. Yes, it’s confusing.

All of these versions up to 7.2 supported the Windows, Unix, and Macintosh platforms. At present only a Windows version of Netscape Browser 8.x is available.

Internet Explorer

MS’s Internet Explorer made its initial appearance August of 1995. One of the things that fascinates me about this is that not only was it free, but it was also independent of the operating system. Quite a bit different from the MS we know and love today. Not only that, but Netscape’s decision to go open source was probably partly in response to this. IE3 introduced the first support for CSS and also extended javascript in its own way. It competed neck to neck with Netscape before pulling ahead around 2000 with what many would (and did) describe as monopolistic techniques, although Netscape’s failure to put out any new release for four years after its 1998 announcment was no doubt a major factor as well. (Note that IE stopped its own breakneck pace of updates at this time: incredibly, IE6 has not been updated aside from bugfixes and patches since October of 2001.)

MS also halfheartedly put out a version of IE for the Macintosh in 1996, but has abandoned it since 2001 — MacIE 5.0 is for OS 9 and previous; MacIE 5.1 for OS X.

IE4 (with the new Trident renderer) marked the beginning of Microsoft’s attempts to integrate it fully with the operating system: a trend that continued through versions 5 and 6 until IE7. IE7 will be a standalone browser once more in part for security reasons.

Internet Explorer runs on Windows. Although since earlier versions of Windows may or may not be able to run IE6, this forces users to make do with MSIE5.5 in many cases. The latest version, IE7, will only run on Windows XP SP2 and later (Vista) versions, therefore IE6 will not be disappearing any time soon, either. The Macintosh version is no longer supported. There was even a Unix version, which ran on Solaris’ and HP-UX’s X Windows, also no longer supported.

Opera

Norwegian based Opera 2.0 (shareware) was released December of 1996, and its latest release, 9.0 (freeware) was within the last month. It has always had excellent CSS support (although considering that Opera’s CTO is one of the writers of the CSS specifications, this is no surprise). Opera 3 came out in December of 1997, version 4 in June 2000, and 5 in December of the same year. Then version 6 in November of 2001. However, versions 7-9 have seen significant improvements and it remains small and light — quick and easy to download and run. The ads in the free version and the paid version were scrapped with the release of 8.5 which remains today freeware, although not open source, and ad-free.

Unlike the other browsers covered so far, Opera was written from scratch and is not based on anything else: not NCSA Mosaic nor Gecko or Trident. It is strongly (and impressively) committed to standards support but at the same time its proprietary code allows it to provide browsing features such as page zoom, a multi-document interface browsing environment and mouse gestures.

Opera can be run on Windows, Linux (*nix), and Macintosh operating systems. Interestingly, they have optimized versions for cellphones and PDA/Palms which are worth checking out.

Mozilla and Mozilla Firefox

(See also what I call the many names of Mozilla.)

The Mozilla department started work on the new rendering engine after its formation in 1998. At this point, it was still part of Netscape and it began work on what was initially called Mozilla, releasing 1.0 in 2002, along with Netscape 7.0, which was essentially a rebranding of Mozilla 1.0. Then Mozilla Phoenix 0.1 was released, also in 2002, and this is the first cut at using XUL. The idea here was to create a leaner and faster browser. In 2003, Mozilla separated from Netscape (and AOL) and became the Mozilla Foundation.

In 2005, Mozilla Foundation released the last “Mozilla” (1.7) which was renamed Mozilla Application Suite to avoid confusion. Having shed itself of this, Mozilla Foundation now focused on one browser (Phoenix renamed Firebird renamed Firefox) and one email client which are separate, self contained applications. Mozilla Firefox 1.0 was released in 2005. Current version 1.5.0.4 was released June 2006.

Firefox is available for Windows, *nix, and Macintosh.

SeaMonkey

Of course, nothing really ever dies in opensource. The Mozilla Application Suite, though no longer supported by Mozilla Foundation, has been unofficially picked up by an open source community project which has renamed it SeaMonkey, and which has released steady updates to it. It’s currently at 1.0.2, released June of 2006. As a suite, it bundles together a web browser, an email reader, a newsgroup client (!), IRC chat, and HTML editing.

SeaMonkey is available for Windows, Linux (and some *nix), Mac, and even OS/2.

Camino

In another bid for the “just a browser” application, there’s also Camino, which is a free, open source, graphical Web browser based on Mozilla’s gecko engine and designed for the Mac OS X family of operating systems. However, since it predates Firefox, and was intended solely for the Mac, Mac-native Cocoa APIs have been used where FF used XUL. It concentrates on providing “just the browser” in a lightweight application.

Konqueror

Konqueror was a sudden entry into the fray in November of 2000. It is a wholly independent browser, developed for Linux. It normally uses KHTML as its rendering engine (although its modular nature allows it to use Gecko instead — this is kmozilla in the kdebindings package) and is compliant with HTML, supports Javascript, Java applets, CSS, SSL and other open standards. Konquerer 3.5.2 was released with KDE 3.5.2 in March of 2006.

Safari

Apple based Safari on KHTML, when Konqueror itself was at 3.02, and released it in January of 2003. Apple made the changes it had made to KHTML available back to the open source community, some of which has been incorporated and is used in later versions of Konqueror as well. Available as a separate download initially, it was included with Mac OS X v10.3 on release on October 24, 2003, as the default browser, with Internet Explorer for Mac included only as an alternative browser. Since the release of Mac OS X v10.4 in April 29, 2005, Safari is the only web browser included with the operating system.

Safari uses Apple’s WebKit for rendering web pages and running JavaScript. WebKit consists of WebCore (based on Konqueror’s KHTML engine) and JavaScriptCore (based on KDE’s KJS JavaScript engine) both of which are LGPL. WebKit itself was also released as open source. The source code for non-renderer aspects of the browser, such as its GUI elements, is proprietary.

Additional Sources

http://www.boutell.com/newfaq/history/fbrowser.html
http://www.livinginternet.com/w/wi_browse.htm
http://www.holgermetzger.de/Netscape_History.html
http://www.blooberry.com/indexdot/history/browsers.htm
http://browsers.evolt.org/