When a Web surfer clicks on an icon to launch his or her favorite Web browser, only the geekiest of the geeky pay any thought to which engine layout is at work. The typical Web user has no clue that a different browser choice may also include a different browser layout engine.
If anything, most Internet users concern themselves about which Web browser is more secure. Should they worry instead if older versions of Apple’s browser were better because they used KHTML? Or that maybe the security and usability of Mozilla’s Firefox browser is better because it uses Gecko? Could Microsoft’s Internet Explorer 7 (IE7) be a better browser choice today because it uses the Trident engine? Why are there so many different options to begin with?
“Why do we want more than one layout engine? It helps to spur innovation and means that if a flaw occurs it won’t necessarily be in every browser at once. Having some different implementations of anything is a good thing,” Gene Spafford, computer science professor at Purdue University, told LinuxInsider.
What Are They?
The three main Web engines in mainstream use today are Trident, Gecko and Presto. IE7 is based on the Trident layout engine.
Mozilla uses Gecko in Firefox and the Thunderbird e-mail client, as do several other open source Webbrowsers. Opera Software uses Presto as the layout engine in its browser. So does Nokia in its Internet Tablet products. Also, Nintendo products are based on the Presto engine.
Apple eventually broke from the KHTML mold. It used some of the KHTML code and grew it into itsown Web engine called WebKit.
“KHTML doesn’t really exist in a relevant fashion anymore,” Guy Lunardi, product manager for Novell, told LinuxInsider.
Do Differences Matter?
Both the Apple Safari browser and the Apple iPhone use WebKit. However, WebKit’s popularity extends beyond Apple, according to Lunardi.
Adobe AIR (Adobe Integrated Runtime) and Nokia’s smartphone line are using WebKit today.
Don’t, however, suggest to Lars Knoll, the creator of KHTML who is now a software developer for Trolltech, that his legendary browser layout engine is a has-been. KHTML’s source code is a lot smaller and easier to work with than Gecko, he explained.
“In terms of what’s new with KHTML, I think the main news currently is the ongoing effort of trying tomend the fork between KHTML and the WebKit project,” he told LinuxInsider in an interview from his office in Oslo, Norway.
In the Beginning
KHTML began as part of KDE 2.0, a desktop environment in some Linux operating system distributions. KHTML was an endemic part of the Linux Web browser Konqueror and KDE’s integrated KHTML-powered Web browser and file manager.
It was a mainstream rendering engine solution as the popularity of the Netscape browser was waning. Back then the folks at the Mozilla Foundation were still experiencing the birth trauma of separating its open source browser from the Netscape source code around Gecko.
“While the focus of Gecko in the early years has been to build up a complete development platform, KHTML has always just focused on being an HTML rendering engine,” Knoll said. “The idea behind KHTML was to create a standards-compliant HTML rendering engine that could handle all — at that time — modern Web pages using CSS (cascading style sheets) and JS (JavaScript).”
Mozilla/Gecko was a project paid for by Netscape and then AOL. Later, the Mozilla Foundation fostered a large amount of paid people working on the Gecko engine, he added.
“KHTML was a project purely driven by volunteers until Apple got involved. None of the people that worked on KHTML until 2003 ever got paid for the work we did,” explained Knoll.
The Path Divided
The goals of both rendering projects are similar. While many differences exist on the inside, they bothprovide a standards compliant HTML engine that can deal with all Web pages built on the net. Today, both engines support more or less the same feature set: HTML 4.1, XHTML, CSS 2.1, JavaScript and Ajax-type Web applications, said Knoll.
One of Knoll’s main focus areas from the very beginning, he said, was to try to make the architecture assound and as easy as possible for an HTML rendering engine. This made it a lot easier for people to startworking and contributing to the project.
“It was also probably the main reason for Apple to go with KHTML instead of Gecko for its Safari Webbrowser,” Knoll proffered.
Novell’s Lunardi agrees that the performance among these Web browser layout engines is seamless. They all have to implement a lot of standards and specs, including HTML, CSS, XML Document Object Model, RDF (resource description framework), JavaScript and much more.
Same Differences
These different engines exist because they were developed by different groups for different needs. Inreality, they all provide generally the same end goals.
“As such, they will handle the combinations of these in different ways. They will be trueto the specifications in different ways. They will handle errors and poorly formatted content indifferent ways,” Lunardi said.
Knoll maintained the KHTML project until 2003, when others took over so he could move on to related work. In a sense, his work as a software developer has come full circle. Last autumn he went to work on WebKit, trying to get that rendering engine integrated into the Linux desktop environment KDE 4.
No Best Choice
Users would be hard-pressed to select a specific Web browser solely on the basis of which layout engine it uses. None of the engines residing on the same system cause conflicts for users or headaches for software developers, according to Knoll.
The choice of layout engines is largely a flavor additive for browser developers. For instance, KHTML is a lot better suited for embedded devices due to its smaller memory footprint. Gecko has more market share, explained Knoll.
Some minor issues exist for Web developers, but most of these are fairly trivial, Knoll said. Thebiggest headache for Web developers is probably the difference between the browsers that aim at standards compliance (Gecko, KHTML and WebKit) and IE.
“In the end, it’s often a matter of taste which browser someone uses. On Linux one has three possibilities:Firefox — or another Gecko-based browser — Konqueror or Opera. As a user, you can simply pick whatever you like best,” Knoll concluded.
Why Not One?
Why shouldn’t there be a single standard engine for all browsers? Knoll sees two reasons why having just one rendering engine would not be good for consumers.
Having only one implementation will never give you any guarantees that what the engine implements matches the documentation. It will also never guarantee that standard is implementable by anyone else, he said.
Having several engines is good, as it triggers competition — there is no need to improve if you have amonopoly, he reasoned, echoing Spafford’s view.
“We’ve seen this in the browser area in the last years, where every engine tries to be as fast aspossible and/or as standards-compliant as possible,” he said.
Loading ...
As a web developer, I believe that the issues with Trident have been significantly downplayed in this article. When using arcane development techniques like table layouts which create accessibility problems, worse search engine ranking, and slower performance, it’s true that compatibility issues are usually relatively insignificant. But when using the more efficient and effective techniques, Trident seems to stand alone in its grumpiness due to its uniquely poor support for modern web standards.
The problem stems from how Internet Explorer development was managed by Microsoft. Roughly five years into development, Microsoft decided to stop doing any work on it other than the occasional security patch when an extremely critical vulnerability was found. This went on for about five years. Meanwhile, the developers of the other browsers were hard at work improving their engines. So the development effort put into Trident was roughly half that of the other major layout engines, and most of the focus was on older technologies. IE7 introduced some improvement, but it wasn’t dramatic; just a typical year’s worth of improvement for the year they spent on it. Trident remains by far the most difficult engine to support when following the best practice techniques of modern web design.