Mozilla Project Hurt by Apple's Decision to use KH

Anonymous Coward writes "I Read this article from ZDNet claiming how some of the Mozilla developers were hurt by Apple's decision to use KHTML over Gecko. I can see both their points. Mozilla was made for cross-platform compatibility, and this probably adds to the bloat, however that's not what they were looking for. They wanted small and fast."

Mozilla Lite?

[Gunfighter]

Why not use phoenix or some similar project w/out the bloat of the full-blown Mozilla?

-- Gun

P.S. First post

Why the bloat?

[Pig Hogger]

Obviously, apart from the multiplatform thingy, the bloat surely comes from evolving code; that is, you start with a neat, swift & cool architectyre (Netscrape 1), then add some bells and whistles (Netscrape 2), then you get featuritis (Netscrape 4) until the bloat becomes unmanageable (Netscape 7).

At one point, it's necessary to stop and redo everything from scratch.

ZDNet took statements out of context

[feelafel]

It should be noted that Mike Shaver's (formerly of Netscape, still of Mozilla) comments [off.net] were, as he points out [0xdeadbeef.com], taken horribly out of context in the ZDNet article.

Re:Nothing new here

[Apiakun]

Uhm, the iPod is available for PC, and not because of great urging, but because it was a good business decision.

The article doesn't say that!

[smagoun]

The article doesn't say the Mozilla developers were hurt! It says they either a) agree with Apple or b) don't care. For example:

One Mozilla staff member called KHTML selection an understandable if not foregone conclusion, given Mozilla's technical problems.

and

"I guess I'm supposed to be mortally offended--or at least embarrassed--that they went with KHTML instead of our Gecko engine, but I'm having trouble working up the indignation," wrote Mike Shaver in a Web log posting. "We've all known forever that Gecko missed its 'small-and-lean' target by an area code, and we've been slogging back towards the goal, dragging our profilers and benchmarks behind us, for years."

Apple hurt Mozilla? The only thing that hurt Mozilla was Mozilla. And for the most part, the Mozilla developers know that already.

"Editors," indeed.

another good (and related) read.

[mkoz]

http://linuxjournal.com/article.php?sid=6565

Slashdotted Already?

[perlstar]

Applications

Mozilla hurt by Apple blast

By Paul Festa
Special to ZDNet News
January 14, 2003, 4:00 AM PT

AOL Time Warner's Mozilla project is facing new questions about quality after Apple Computer's release of a browser based on rival open-source code.
Apple last week unveiled its own browser, called Safari. The company said it was based on the KHTML rendering engine that is the core of Konqueror, an open-source file manager and Web browser for the K Desktop Environment (KDE).

In an e-mail congratulating KHTML engineers on their work and its selection by Apple, Safari's engineering manager touted the technology over Mozilla and its rendering engine, Gecko.

"When we were evaluating technologies over a year ago, KHTML and KJS stood out," Safari Engineering Manager Don Melton wrote. (KJS is KDE's JavaScript interpreter.) "Not only were they the basis of an excellent, modern and standards-compliant Web browser, they were also less than 140,000 lines of code. The size of your code and ease of development within that code made it a better choice for us than other open-source projects."

Despite its diplomatic tone and anonymous reference, Mozilla veterans read between the lines of Melton's message.

In a Web log, Mozilla founder and former evangelist Jamie Zawinski said Apple is bad-mouthing Mozilla.

"Translated through a de-weaselizer, (Melton's e-mail) says: 'Even though some of us used to work on Mozilla, we have to admit that the Mozilla code is a gigantic, bloated mess, not to mention slow, and with an internal API so flamboyantly baroque that frankly we can't even comprehend where to begin,'" Zawinski wrote.

One Mozilla staff member called KHTML selection an understandable if not foregone conclusion, given Mozilla's technical problems.

"I guess I'm supposed to be mortally offended--or at least embarrassed--that they went with KHTML instead of our Gecko engine, but I'm having trouble working up the indignation," wrote Mike Shaver in a Web log posting. "We've all known forever that Gecko missed its 'small-and-lean' target by an area code, and we've been slogging back towards the goal, dragging our profilers and benchmarks behind us, for years."

Shaver, who left Netscape three years ago but retained his position on the small Mozilla staff, said that in Apple's shoes he might have made a similar decision.

"If I had to write a new browser, and I was going to have to touch the layout code in a serious way, I would think about Mozilla alternatives," Shaver wrote. "I really, really hope that Mozilla will learn from Safari/KHTML, because they've done a lot of great work in about a tenth of the code."

Mitchell Baker, who goes by the title of chief lizard wrangler at Mozilla, defended the Mozilla project against technical gripes in a prepared statement. "Gecko offers crossplatform capabilities, leading standards support as well as a full feature set and tested compatibility on the Web," she said.

"Gecko's speedy crossplatform nature is important to maintaining a Web to which all users have access regardless of their platform," she added. "Gecko is already embedded and distributed in real-world applications from Red Hat, IBM, OEone, Netscape and CompuServe, and we look forward to the upcoming releases of Gecko-based products that are currently in development."

Slow progress
Mozilla has faced criticism before over the pace of its development efforts, which were originally conceived as the Web community's best chance to challenge the dominance of Microsoft's Internet Explorer. Mozilla 1.0 was released last year, after long delays that effectively allowed Microsoft to cement its lead.

AOL Time Warner's Netscape division issued Netscape 6--its first browser based on the Mozilla code--to poor reviews, but a subsequent update answered many of the critics. Netscape Communications is Mozilla's corporate sponsor.

Mozilla and Netscape have both seen small gains in market share, appearing in the market alongside an independent entry from Norway's Opera Software. None has significantly challenged Microsoft's lead, however, which remains well above 90 percent, according to a recent survey.

Apple's browser is unlikely to alter the market-share picture, but is still a significant entry into the field. Although it caters to a small group of users, it could help Apple wean itself from its reliance on Microsoft's IE and create new software services. Apple's vote also carries significant weight in software circles as a result of its development of several highly-regarded applications for its Macintosh personal computers, particularly its iTunes and iPhoto multimedia tools.

Melton's e-mail detailed the Safari team's deep roots in the Mozilla project. Melton helped launch Mozilla in 1998. Safari engineer David Hyatt launched Chimera, a version of Mozilla for Mac OS X.

Asked to elaborate on its rejection of Mozilla, Apple went out of its way to minimize its dissatisfaction with the technology it bypassed.

"The Gecko engine is fairly well-regarded engine," said Chris Bourdon, product marketing manager for Mac OS X. "It isn't to say that there is anything poor about Gecko or Mozilla. The Safari team just felt KHTML was a better code base from which they could build a browser."

Bourdon said Safari engineers looked at size, speed and compatibility in choosing KHTML. In addition to Mozilla, Apple also considered building its own browser from scratch.

Bourdon said the fact KHTML's small size--140,000 lines of code--let Apple build a browser that is a svelte 3 MB in size. He compared that with Netscape's more than 17 MB, though that includes an e-mail reader and other peripheral applications.

Untying browser knots
Apple, which embarked on its browser project in order to free itself further from dependence on Microsoft and its Internet Explorer browser, may have balked at using Mozilla because of its ties to AOL Time Warner. The media giant's Netscape unit funds and staffs Mozilla's nonvolunteer positions.

Though shared enmity with Microsoft has made Apple's relations with AOL Time Warner comparatively warm, the question remains whether Apple would want to trade in its browser reliance on the world's largest technology company for that of the world's largest media and technology company.

Apple and analysts alike insisted that technical, rather than political, considerations were the real reason behind Apple's choice.

"Every discussion I had with them had more to do with the quality and size of the kernel and what they could do with it," said Tim Bajarin, an analyst at Creative Strategies in San Jose, Calif. "My suspicion is the real goal was to just try to work with what they considered the best technology that they could build on. And they did a heck of a lot of research."

Since Safari's release last week, Web developers have been trying the browser out and discovering bugs in its rendering capabilities and standards compliance. That's only to be expected from the first public beta of a browser, and Safari's Hyatt has been maintaining a Web log detailing some of the more prominent problems and their resolutions.

While Mozilla has long carried the torch of standards compliance, standards advocates called the new prominence of its open-source competitor a boon for Web standards.

"The two projects have had very different histories and goals--some very much in line with our stance, and some that may have served to detract attention away from their implementing standards as well as we'd like," said Steven Champeon, a member of the Web Standards Project and chief technology officer of Hesketh.com. "But in the long run, as long as the number of highly standards-compliant browsers continues to grow, and we can see some great competition out there, everyone wins."

One Web developer cheered Apple's decision, and agreed with the company's comparative evaluation of the two open-source browsers.

KHTML is "very fast, doesn't have nearly the bloat of Mozilla, and does most of what I need," said Alex Russell, a Web application developer for SecurePipe and a lead developer for netWindows. "The Mozilla rendering engine isn't slow, but at the same time it has emphasized crossplatform correctness over speed, while KTHML has taken a slightly more expedient approach of shooting for a smaller feature set, getting it right, and then making things fast."

Re:Nothing new here

[scrod]

Have you been living in a cave for the past few years? They eschew standards? Mac OS X has a windowing system based on PDF, OpenGL integrated at a very low level in the operating system, XML-formatted preferences for every single app and system setting, an ultra-compliant Java2 VM, and an open source foundation with a BSD UNIX personality. It's getting very, very difficult to find new technologies in OS X that are proprietary, and you're complaining that they used one open source rendering engine instead of another? What kind of warped view of the world do you have?

David Hyatt on KHTML vs Gecko (long)

[Anonymous Coward]

This very informative rant was on David Hyatt (Safari developer)'s weblog [mozillazine.org] on Saturday for a few minutes, but he removed it for unknown reasons. I saved a copy:
Quoted from the original mail to the KDE folks:

The number one goal for developing Safari was to create the fastest web browser on Mac OS X. When we were evaluating technologies over a year ago, KHTML and KJS stood out. Not only were they the basis of an excellent modern and standards compliant web browser, they were also less than 140,000 lines of code. The size of your code and ease of development within that code made it a better choice for us than other open source projects. Your clean design was also a plus. And the small size of your code is a significant reason for our winning startup performance as you can see reflected in the data at http://www.apple.com/safari/.

Mike Shaver writes in his blog:

This whole Safari thing is a source of deep entertainment to me. I guess I'm supposed to be mortally offended ? or at least embarrassed ? that they went with KHTML instead of our Gecko engine, but I'm having trouble working up the indignation. We've all known forever that Gecko missed its "small and lean" target by an area code, and we've been slogging back towards the goal, dragging our profilers and benchmarks behind us, for years. If I had to write a new browser, and I was going to have to touch the layout code in a serious way, I would think about Mozilla alternatives. I think it's awesome that they pretty much have to compare Safari to Chimera and Netscape/Mozilla, because it shows how far we've come from the universal acceptance of IE's hegemony. I think it's fantastic that they chose to include "Gecko" in their user-agent, so that they could get standards-compliant content, because it means that our evangelism efforts in support of such content have been working. I'm thrilled that they're going to be another IE-alternative browser, which will try some techniques Mozilla decided against, because we can see if it really works or not. And I really really hope that Mozilla will learn from Safari/KHTML, because they've done a lot of great work in about a tenth of the code. Kudos, guys, and welcome to the web.

David Baron writes:

Why is Mozilla's layout engine so big and complex? Perhaps the simple answer is that there were too many people available to write it, and they wrote as much code as they could. After all, they didn't have any incentives to keep the code small.

But what, in detail, is wrong? (Now I'm just speaking of the code in mozilla/layout, which is one of the pieces code I work on, and by far the most discouraging one for a company coming along and thinking of building a web browser based on Mozilla's layout engine.)
I think some of the people who wrote the code didn't understand the specifications that they were implementing. Part of the problem may lie in the specifications themselves. For example, there's almost no information in CSS2 describing shrink wrapping. Might being an afterthought explain why Mozilla's layout engine has shrink wrapping code scattered throughout it in a disorganized fashion? Even lately I've watched some developers want to make incorrect changes in behavior or fail to understand the reason that another browser lays a page out differently.

I think part of the problem may have been a desire to make everything modular so that it could be split up between different programmers. In the end, there were just too many pieces. (Could this be a problem of too many design documents?)

There's overoptimization in certain areas. For example, our rendering object structures are extremely optimized for size at the cost of code complexity, and, to some degree, performance. However, our content tree structures are larger and the code is simpler. From what I understand about khtml, it has much smaller content tree structures (with the DOM using tearoffs), while its rendering objects (what Mozilla calls frames for some confusing reason) are much larger, allowing for simpler code.

There's been an inability to focus on more than one or two things at the same time. In 1998-1999, there was a focus on standards compliance. In 2000-2002, there was a focus on making real web sites work. In 2001 there was a focus on performance. Now (late 2002/early 2003) there's a focus on memory use. In many of these cases, working on one objective can hurt another one, and I think we've often failed to balance them appropriately.

(The real solution to cleaning up layout probably involves making layout objects use twice the amount of memory that they currently do. Is that a problem? I don't think so, since they take up so little of the total. We're better off increasing the amount of memory that frames use and attacking memory use in other areas. If I do this, will I be told that I have to fix the memory use regression in 72 hours or back out the changes? I hope not.)

In the end, khtml's code is a lot simpler. Perhaps more importantly, the code looks a lot more like a description of the way the layout process works. After hearing a short explanation of what's what, I can understand some of khtml's code almost as well as the equivalent code in Mozilla.

Here are the two function protoypes that David Baron linked to. I think they pretty much illustrate the point perfectly.

KHTML: virtual void layout(); Gecko: NS_IMETHOD Reflow(nsIPresContext* aPresContext, nsHTMLReflowMetrics& aMetrics, const nsHTMLReflowState& aReflowState, nsReflowStatus& aStatus);

This is a wonderful example. Let's go over it in detail. First notice the NS_IMETHOD on the prototype. Basically this means the base class of all render objects in Gecko is an XPCOM interface. Rather than develop a clean tearoff model so that you could create heavyweight objects for external use while keeping the internal objects lightweight, most of the layout structures in Gecko *are* heavyweight and rely on communication through COM interfaces and virtual function calls. Many of those objects are refcounted, but adding insult to injury, some are simply pseudo-COM and their refcounting functions (addref/release) do nothing. Complete confusion can ensue if you aren't aware of which objects are special and which aren't.

Next, let's take the first argument to Reflow. The nsIPresContext is passed as an argument to virtually every layout function for one deeply flawed reason, namely the ridiculous idea that one document should support multiple presentations simultaneously. This is simply not needed in a desktop browser. This separation results in multiple nsIPresContexts and nsIPresShells being supported for a given document, and even getting to the right shell is a pain. (document->GetNumberOfShells; document->GetShellAt(0); etc)

Next we have nsHTMLReflowMetrics and nsHTMLReflowState. Rather than compute size information (like min and max width) up front in a separate pass and just caching it on the objects, we have this object passed down along the reflow chain. There is still other information that could be cached on the objects themselves, like maximal positive and negative margins for correct margin collapsing of vertically adjacent blocks. KHTML does this. The Gecko way, although it makes for smaller rendering objects, has the drawback of making incremental reflow problematic. For example, if you tweak one margin on some block deep in your document, you'd like to only recompute margin information for that single block. If you don't cache margin information anywhere, however, you'll have to crawl around again in order to figure out the correct placement for the block. I'm not sure if Gecko does this or not, but my guess is it just gets margins wrong in many incremental reflow cases.

I don't even know what nsReflowStatus's point really is. Seems like it could just be the return value from Reflow if you really needed to keep it around.

Finally, the name of the function. Gecko chooses strange English words for various processes and objects within layout. Instead of just using layout we get reflow. Instead of RenderObject we get nsIFrame. In some cases KHTML is no better, but where it counts, I think most of the names are more readable.

Now compare directory structure. KHTML has a simple obvious directory structure. Before I knew anything about the code, I was able to guess the right directories for various implementations. Gecko has the opposite problem. There are way too many interfaces first of all, entire objects that have no reason for existence. These mingle with the useful files making it harder to find what you're looking for. Combined with a byzantine directory structure, (e.g., portions of the CSS back and front ends are scattered between two separate libraries and multiple directories within those libraries.), Gecko becomes extremely difficult to wrap your head around.

The upshot, and this cannot be stated clearly enough, is that there are only a handful of people who are even capable of modifying Gecko, because the code is so unreadable and so complex.

Now imagine that your number one priority for a browser is speed. You want a browser that launches almost instantly. You want a browser whose page load peformance can be improved dramatically. This is your number one goal, because you want to address what has been a fundamental problem on your platform (OS X) ever since it was launched: that no browser has accomplished the goal of fast startup and fast page load. Your job is to find an existing open source engine and improve it to the point where it does have fast startup and phenomenal page load times.

The problem is, how do you make Gecko have a fast startup time on the Mac? Comparing Chimera's slow cold launch with its zippy warm launch, it's readily apparent that much of Gecko's startup time problem on the Mac is due to the enormous code footprint. So, in order to use Gecko, your first task would be to shrink this code footprint. So how do you do it? Well, you'd have to deCOMtaminate a lot of the core code, eliminate redundant interfaces, and in some cases re-architect dramatically a lot of components so that they didn't need to exist. For example, Gecko has its own image loading library, which you would want to eliminate in favor of simply using the operating system's image capabilities. Ditto for networking.

Now look at KHTML, which dropped in as is (with QT implemented) gives you a fast startup time right off the bat, because the code is so small and well-designed that you don't even have to worry about startup. A whole huge set of tasks eliminated simply by picking KHTML over Gecko.

Next consider the problem of native widgets. KHTML has a clean separation of the form controls as native components (using QWidget and QInterfaces to communicate), so all you have to do is back those QInterfaces with Cocoa implementations and bang, you have native form controls.

The same problem in Gecko is months of work. You have to develop these interfaces for each widget (they don't exist), and then slowly but surely get native widgets working again. You'd have to completely rearchitect all the form control render objects in Gecko to talk to native widget interfaces. Then you get to have fun fighting all of the bugs from a brand new forms implementation and again would probably have to modify other parts of Gecko to support these new form controls.

So to summarize: with KHTML what you have is a tiny engine with reasonable standards compliance and native widgets that would need to become a tiny engine with native widgets and outstanding standards compliance. WIth Gecko, you have an enormous engine with outstanding standards compliance and non-native widgets, that would need to become a small engine with native widgets while still retaining outstanding standards compliance.

Which task is going to be easier? There's no question that both involve heavy modification of the layout engine, and both involve a lot of work, so then the question becomes, Which one is easier to modify? In my opinion (speaking only for myself), the answer is KHTML. I won't pretend that the choice of KHTML over Gecko is a no-brainer (it's not), but for those of you who think standards compliance is the only consideration when developing an outstanding browser engine, well, hopefully this will give you some food for thought.

Re:Nothing new here

[fishboy]

let's take apart your argument, slashdot take-down style:

Apple has never valued cross-platform compatibility except at great urging.

never is a strong word in my books-- what do you call bluetooth, 802.11, firwire, opengl, xml, and usb? refusal to embrace and push for open standards? if anything, apple is the measure of computer industry these days.

From the days of proprietary Apple-only hardware and the squelching of would-be competitors, to the modern day with the refusal to port Aqua and launching the iPod for Macs only.

computers are what apple sells and they stay in business by selling their machines, not other peoples'. the licencing of apple hardware was flawed from the beginning and handcuffed apple into killing the program because of abuse. porting aqua to other platforms would be the end of apple-- remember, they are a hardware complany, not a software company. aqua sells macs, not the other way around. so do ipods. apple builds incentive to buy their hardware, why give those incentives to other platform users?

the integration of an X server in the latest release is definitely the exception to the rule.

pal, you have so missed the boat in your post that i think you should take a step back from this fud. x server is merely the tip of the iceberg of what has been the "exception to the rule". os x is on the cutting edge of the open source / corporate relationship, existing on open standard freebsd and countless other non-proprietary formats. if the other favourite popular target of slashdot could be mentioned this favourably, we wouldn't be here.

just my two cents.

Discussion on MozillaZine

[alanjstr]

There has been a lengthy discussion on MozillaZine here [mozillazine.org]

Re:Emulated GUI's rejected by market

[ShdwStkr]

It's called SWT, Standard Widget Toolkit.

Find it here [eclipse.org], towards the bottom.

-SS

Official KDE newsflash

[infolib]

here [kde.org]

Snippets:
Jobs said the browser was "based on standards", "works with any Web site", has much-improved performance over IE (page-loading speed is "three times faster", JavaScript performs twice as fast and it launches "40% faster" - comparisons to Netscape 7.0 shows similar performance gains on the Macintosh platform)

Apple [...] has today sent all changes, along with a detailed changelog, to the KHTML developers.

Also:
Mail from Safari team to KHTML devs [kde.org]
and Dirk Muellers response [kde.org]

-- With more than 200 comments this is apparently a big thing to the KDE community

Re:KHTML can't be _that_ bad w/r/t cross-platform

[Teancom]

Apple didn't use QT in Safari. They used KWQ (Quack). That's a wrapper layer, that passes QT stuff onto the ObjC/Cocoa layer. So while Apple may indeed use other KDE stuff (though I don't know what else they would want), it won't be a boon to Trolltech, as they don't have to pay the trolls a dime.

Re:even if it's "half finished"....

[skahshah]

The zip file is about 6.1MB. Phoenix is certainly a lot more, once the file unzipped.

Comment removed

[account_deleted]

Comment removed based on user account deletion

Actually

[commodoresloat]

We should be comparing to Chimera [mozilla.org], which is the OS X version of the trimmed-down Mozilla-based browser. My copy is about 21M.

Mod parent up!!! khtml is crossplatform.

[Moritz Moeller - Her]

Jesus H. Christ! How can anyone claim that khtml ist not crossplatform?

It can be used without X (kde no X = kdenox, in CVS), without unix even, as Atheos shows.

Nobody remember Konqembedded?
http://www.konqueror.org/embedded.h tml

Also the only slight dependency is qt, which is crossplatform (Windows, Unix, OS X, embedded). As Apple [and Atheos] shows, it is easy to write wrapper to get rid of even that dependency.

Read Dave Hyatt's Blog

[alanjstr]

Hyatt works on Mozilla, Phoenix and Safari (he's an Apple employee).

Here is his blog [mozillazine.org] which talks about it.

Re:architecture questions

[IamTheRealMike]

# Why are we using xpcom considering the huge bloat/threading issues on non-win32?

Because XPCOM allows plugins to have some semblance of binary compatability, and because it enables XPConnect which makes it trivial to create cross platform UIs. Note that the large amount of code written in XUL/JavaScript is very easy to hack, a lot of contributors to Mozilla started this way. The development time costs were probably worth it alone.

Why do the signatures on our api make almost no sense to outsiders?

Signatures? If you mean function prototypes, they are fairly self explanatory usually. Anybody with a good grasp of C++ who wants to understand them can find out what the portable typing system is.

# Why do we compare our performance almost exclusively to IE?

Because Gecko is feature-comparable to IE (Trident) and KHTML isn't? Also remember that nobody uses Konq and everybody uses IE from a statistical viewpoint.

# If Apple wont use our code because it's too big, do we have any real chance of being used on small devices?

I dunno if they really target very small devices any more. For starters, very small devices probably aren't going to need fully featured web browsers anyway.

Why are we still using xul now that we ifdef [hixie.ch] out platform-specific ui code?

Well, that link goes to a simple preprocessing tool, it doesn't make any mention of XUL I can see. And more to the point, XUL is an abstraction system so if anything removing platform-specific code would make sense. Of course Moz does use some platform specific code, like common dialog boxes.

Using XUL makes a lot of sense btw. Other than Qt which is only free software on X11 platforms, there weren't really any good C++ cross platform toolkits back then. The nearest is wxWindows which wasn't anywhere near as well developed as it is now, and still isn't really up to the quality needed of Mozilla from what I've heard (not used it myself, might be wrong).

The choice was simple - either XUL or Windows only.

Mozilla is complex at points, the use of XPCOM in all parts of the app was a mistake (which is now being rectified in de-comtamination, ho ho), but that's because the web is a complex thing. I think people malign Gecko too much really...

Re:KHTML can't be _that_ bad w/r/t cross-platform

[iJed]

Oh boy, that's funny. So that's why it has a textured window (that cannot be themed to something less distracting), along with all the rest of the usual Apple eyecandy - but no tabs?

You can easily change the Safari theme from brushed metal Aqua to standard Aqua with a couple of clicks in Interface Builder. You could also use one of the Unsanity [unsanity.com] haxies.

Re:I'm not an Apple user but...

[90XDoubleSide]

from http://www.mozillazine.org/weblogs/hyatt/ [mozillazine.org]:

A number of people have commented on Safari's UA string, which is as follows: Netscape 5.0 Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/48 (like Gecko) Safari/48 The portion of the UA string that seems to be stirring up controversy is the portion that says (like Gecko). The reason it is there is that in order to work with real-world DHTML sites you have essentially two options: you can claim to be MSIE or you can claim to be Gecko. We found that any other choice that we tried led to a significant portion of DHTML malfunctioning. You would not believe (well, maybe you would) how much DHTML exists out there that works only with MSIE or Gecko, and that uses proprietary extensions of each to accomplish the DHTML effects. Had we released a browser with a UA string that did not superficially match either MSIE or Gecko, users would have downloaded Safari and experienced many malfunctioning Web sites. If anyone thinks that would have been a good idea, please step forward in your blog and explain why. I'm willing to listen. Our solution was a compromise. We produced a user agent string that is different from Gecko's and easily distinguishable if you choose to sniff for it, but that at this time will pass most UA checks that sniff for Gecko. It may be that enough sites will start sniffing directly for our string that we can drop the "(like Gecko)" from our user agent string, but I'm not optimistic. We chose to be more like Gecko than like MSIE because we wanted to be lumped into the standards compliant category, because fundamentally we are committed to supporting DOM 1&2, CSS1&2, and enough proprietary MSIE extensions and Gecko extensions (innerHTML, createContextualFragment, offsetWidth/Height, etc.) that we could be placed in a similar category. That's all from my end. I welcome constructive feedback on this issue.

Re:Bloat

[jonadab]

Yeah, Gecko is big. It has to be, to get all the layouts correct.
Understand, it's designed to lay out and render, correctly, anything
from non-wellformed pre-W3C HTML on the one end of the scale up
through XSLT at the other end, plus XUL. That's a tall order.
Konqueror doesn't handle quite as wide a spectrum.

That said, KHTML handles more of MSIE's proprietary non-W3C extensions
to the DOM than Gecko does, which _may_ be part of why Apple chose it.

Re:Why hate KHTML?

[bricriu]

A page using CSS Level 2 in IE (pc) [comcast.net], Chimera (Gecko on the Mac) [comcast.net].

Now, that same page using Safari [comcast.net]

You may notice some differences.

Re:DEATH TO BRUSHED METAL!!!

[coolmacdude]

Okay well this is not meant to flame you but, any idiot knows you can turn it off if you don't like it. And even if you don't know how, there are apps willing to do it for you (check VT).

Re:Safari is only half finished... it will bloat

[Daleks]

Please, please, please, PLEASE try to remember - Chimera is NOT Mozilla.

Yes, but the argument is over rendering engines, not browsers. Mozilla and Chimera both used Gecko. More specifically, Chimera uses CHBrowserView [mozilla.org], which wraps Gecko as a Cocoa NSView sublcass. Safari uses WebCore [apple.com].

It's a side project, associated with mozilla.org in a similar fashion as Phoenix.

Yes, and Phoenix uses Gecko. Your point?

When comparing Safari to Mozilla, please do it properly, and compare it with the actual Mozilla OS X builds.


A comparison of the Mac OS X build of Mozilla vs. Safari makes Mozilla look even worse. The problem is that it's an apples to oranges comparison because Mozilla includes a chat program, mail & news modules, and all the other X* components. Chimera on the other hand (which may support parts of XPCOM, XUL, etc.--i'm not entirely sure) trims away these parts of the application and provides itself for better comparison. Chimera vs. Safari is as close to Gecko vs. WebCore as you're going to get.

Thanks.

Your welcome.

Re:even if it's "half finished"....

[Politburo]

As others pointed out he's compared the wrong file sizes. None of you bothered to post the correct figure though. On Windows (2000), my phoenix directory is 12 MB. That is with ~5-10 components added, which is very little added size.

KHTML a natural choice

[Anonymous Coward]

Lets see:

Chimera: A fantastic, impracticable plan or desire: bubble, castle in the air, dream, fantasy, illusion, pipe dream, rainbow.

Dave Hyatt (for I think it was he, forgive me if I am wrong) said that Chimera was named thus because of the the UNHOLY alliance between the gecko codebase, and Mac OS Xs' Cocoa, object frameworks.

The fact is, and the Mozilla team will agree, that Gecko is a hopelessly over-engineered piece of technology (a little like Quartz). It wasn't built to be 'cross-platform', it was built to be THE platform and with this in mind the engineers of it have turned it into an overcomplicated device.

This does not deny that geko is a fine machine, it is complete, fast and effective.. BUT it is fat, and messy.

When OmniGroup decided to adopt the JS engine from the Mozilla project, they found they had bit off an awful lot to chew.. saying that great areas of it were un-threadsafe and integrating it with OSXs' object frameworks was a nightmare.

Contrast with KHTML.. it is extremely lightweight (if far less complete than Gecko) is more modular and it's hooks outward to the host are more prevelant (Gecko wants to BE the platform remember)

I had no Idea Apple would do this, and was suprised when they used KHTML, but that is probably because I knew little of it.. in fact talk of Apple working on a browser worried me.. because I assumed they would try to use Gecko.. it would have been like banging a square peg into a round hole had they tried to do it.

I'm not taking away from Chimera, they gave the Mac community something great, but look at it.. it's integration with Aqua is roughshod and bizarre, it never 'feels' right.. now look at what Apple have done with KHTML.. it is natural, looks right (like OmniWeb) and works like a dream.

Safari has a -long- way to go, and the bloat will occur (that last 20% of standards to support will add another 50% of code, I'll bet) but now It is, far and away the benchmark in OSX browsing, and I feel it will be for some time.

Re:Actually

[alannon]

Actually, yes. PPC object code tends to be about 2/3 larger than X86 object code. Sometimes larger, actually, depending on the compiler.

Re:Mozilla hurt by Mozilla, not by Apple.

[Xenex]

" From what I've seen, if I ever get a Mac I may be very tempted to use Safari over Opera."

I'll be rude and link to my own mini-rant about Opera on the Mac [slashdot.org].

Trust me, the only browser on the Mac you'd prefer Opera to is iCab.