[radii_22]

Just the above question. I would like to know the technical and commercial reasons. Mozilla is doing great right now, XUL is promising (and the only competition to MS' XAML), it has better web standards compatibility, and it's synergetic : Linux, Mozilla, Sun, etc, the competition against Microsoft web technologies.

i know that Apple needed not only a browser but a web core, but it could have been done with Mozilla... so, what's the real reason of Konqueror?

--->>>

[bmedina]

They chose KHTML due to its smaller code footprint. That helps with a host of things, the most important being ease of development and memory usage.

[TimmyDee51]

While the following may or may not be a good reason, I think it's interesting to ponder.

Maybe Apple took KHTML (in addition to its smaller code base) because it could make more advances to it than to the Gecko engine, which already has tons of people working on it. By taking a smaller project and rocketing it forward, they won the admiration of almost everyone in the KDE community. While the audience for KDE is certainly smaller than that of Mozilla and its ilk, the impact it made on the KDE community is arguably greater than what could be made in the Mozilla community. The bigger the splash, the better the marketing statement. Plus, it reminds everyone that Apple is an underdog and still looks to help out the other underdogs (KDE isn't an underdog in the Linux world, but KHTML is in the browser world).

Again, this is all speculation, and a bit out there at that, but I think it's interesting to think about.

[bmedina]

But Gecko/Mozilla is much more widely used and known. If Apple had chosen Gecko, they would have turned many more heads than they did in chosing KHTML.

Speculation is fine, but Apple themselves have said that their decision was based on engineering factors, not marketing.

[DekuDekuplex]

Originally posted by bmedina:
But Gecko/Mozilla is much more widely used and known. If Apple had chosen Gecko, they would have turned many more heads than they did in chosing KHTML.

Speculation is fine, but Apple themselves have said that their decision was based on engineering factors, not marketing.

This is just my speculation, but perhaps one reason had to do with text rendering.

I know for a fact, for example, that when I view posts on this newsgroup in a Gecko-based browser, such as Mozilla, Firefox, or Camino, the text for the "Author" and "Topic:" titles at the top of the thread pages looks different (and, IMHO, harder to read) than when viewed in, say, Safari. In particular, the typeface families have a distinctly harder look around the edges, and lack enough space between some characters (for example, a string of two 'l''s in a thread topic title at the top of a thread page is much easier to identify in Safari than in Camino). This is also true of most of the text that appears when editing existing posts.

(Unfortunately, for some reason, my installation of Safari 1.0, build v85, running on Mac OS X 10.2.6 Jaguar always crashes when I try to post on MacNN Reader Forums only, so I usually use Camino 0.8.1 to post here. This behavior has not happened when posting on any other forum.)

-- DekuDekuplex

[CaptainHaddock]

I'd be curious to know what Dave Hyatt, the main Safari developer, has to say on the subject. His blog is here: http://weblogs.mozillazine.org/hyatt/index.html (hosted at Mozillazine.org oddly enough), but I can't find any email address.

I suspect, along the lines of what TimmyDee51 suggested, that Apple felt they could have a larger role in the development of KHTML than of Mozilla, which is busting at the seams with developers. KHTML might also have cleaner code (fewer cooks making the broth).

At any rate, I think there are significant advantages to Apple supporting KHTML. More major browsers means that standards become more important than ever, and no one can monopolize the Web. Thanks to Apple, we're assured of two high-quality open-source browser engines (KHTML and Gecko) in addition to the two major non-free engines (Opera and IE).

By the way, I have noticed major improvements in Konqueror in recent versions. I find if I design a standards-compliant web page, it's usually pixel-perfect in, Safari, Opera and Konqueror, and nearly perfect in Camino/Firefox. IE is buggy as heck, but who cares.

I'm curious to see if Apple will design their own implementation of XUL. Maybe they'll do something that works with both XUL and XAML.

[waffffffle]

At the time there was no such thing as Firefox (or Firebird or Phoenix). Camino (Chimera) existed and it was essentially proof that Gecko is a very large and bloated rendering engine, very difficult to embed in other applications. Camino takes a long time to load because Gecko is so large. Gecko contains many features and subsystems in order to maintain cross-platform compatibility, and therefore contains many OS-like components. Therefore loading Gecko can be compared to booting an operating system. This has a lot of overhead.

KHTML on the other hand was small and light. While it was immature in comparison to Gecko, this was nothing that couldn't be fixed, and Dave Hyatt has shown that. Remember that Hyatt was the lead on Chimera before going to Apple to create Safari. He had publicly stated that Gecko was less than ideal for an OS X browser. When Safari was first released it was a fraction of the size of most web browsers. While it has certainly ballooned in size, I believe it is still smaller than most.

I too originally thought Apple was making a mistake by going with KHTML but they have certainly proved me wrong. KHTML is now a robust rendering engine and it is tightly integrated into the OS X GUI to provide a great user experience, while Camino on the other hand has a number of UI quirks that are due to Gecko's UI system.

[AKcrab]

This was discussed rather heavily when the announcement was made.
This seems to be a pretty good recap.

[EMC]

On my linux machine, Konqueror takes 8 seconds to load. Firefox takes 1.5 seconds to load.

The entire Firefox directory is 32 MB.

There is not a single web page that Konqeror can load faster than firefox. (I have the newest versions of each browser)

Konqueror's rendering engine often cannot display pages properly. This is very rare with firefox.


Now, explain to me again how Konqueror was a "less bloated" and "better" choice for Safari?

Safari with Konqeror only hurts Apple. 95% of computer users stick to the web browser that's installed by default. With the poor rendering ability of Konqueror, the typical user will simply feel that Macs can't properly display web pages. If Apple had chosen Gecko, this problem wouldn't exist.

[bmedina]

Because it's easier to take a project with a small code footprint and add the features you need than to take a huge project and try to optimize it.

[EMC]

What sort of optimization do you mean? Compiler optimization depends on the gcc/g++ PowerPC optimization routines. Apple has nothing to do with this.

If you mean optimization of the rendering engine, you are suggesting that it would be easier to rewrite sections of the Konqueror source because it is more efficiently written. Unfortunately, it would require a significant amount of work (namely thousands of man hours) just to get Konqueror to render at the same speed as Gecko, which would probably fatten up the existing codebase. Then you're talking about thousands more hours trying to fix the Konqeror engines numerous rendering issues to get to the Gecko engine level. If at this point (note at least 1-2 years from now) the safari code base is still smaller that the Gecko engine, Apple engineers will sucessfully be two years behind mozilla.org. Now, take into account that a lot more software engineers work on Gecko than Konqueror. Wouldn't you rather have the functional, fast Gecko engine now, and let the Apple programmers work on something more important like say, OS development.

[Catfish_Man]

Originally posted by EMC:
What sort of optimization do you mean? Compiler optimization depends on the gcc/g++ PowerPC optimization routines. Apple has nothing to do with this.

If you mean optimization of the rendering engine, you are suggesting that it would be easier to rewrite sections of the Konqueror source because it is more efficiently written. Unfortunately, it would require a significant amount of work (namely thousands of man hours) just to get Konqueror to render at the same speed as Gecko, which would probably fatten up the existing codebase. Then you're talking about thousands more hours trying to fix the Konqeror engines numerous rendering issues to get to the Gecko engine level. If at this point (note at least 1-2 years from now) the safari code base is still smaller that the Gecko engine, Apple engineers will sucessfully be two years behind mozilla.org. Now, take into account that a lot more software engineers work on Gecko than Konqueror. Wouldn't you rather have the functional, fast Gecko engine now, and let the Apple programmers work on something more important like say, OS development.

...and yet Safari 2 is still the fastest web browser I've ever used. Personally I think Apple made a pretty good decision.

[wataru]

Originally posted by DekuDekuplex:
This is just my speculation, but perhaps one reason had to do with text rendering.

What you're describing is really just Safari misbehaving. The text you described happens to be in a screen font, i.e. a font designed solely to be displayed on a screen. You don't need to, and shouldn't, antialias a screen font. Firefox respects this, but Safari antialiases anything and everything. This is a conscious design decision on the part of both teams.

[CharlesS]

Originally posted by wataru:
What you're describing is really just Safari misbehaving. The text you described happens to be in a screen font, i.e. a font designed solely to be displayed on a screen. You don't need to, and shouldn't, antialias a screen font. Firefox respects this, but Safari antialiases anything and everything. This is a conscious design decision on the part of both teams.

And the reason is that non-antialiased text is ugly and hard on the eyes.

[thefamousmred]

As someone who has the pleasure of working with Gecko in my day job, I can back the assertion that the Mozilla codebase is (still) a massive pain in the ass to work with. Apple made the right choice.

[wataru]

Originally posted by CharlesS:
And the reason is that non-antialiased text is ugly and hard on the eyes.

Non-antialiased text is often ugly and hard on the eyes because the font is meant to be printed, not displayed on the screen. Like I said before, a screen font is designed to be displayed on the screen, therefore it does not need antialiasing and it is not hard on the eyes.

Maybe people aren't quite understanding this. Screen fonts are the same as bitmap fonts. In making one, someone creates each character pixel-by-pixel to look nice at a certain size without antialiasing and whatnot. A printer font is one where the characters are defined by vectors, not bitmaps. Since a screen does not have arbitrary resolution, they need antialiasing to look good. Firefox only antialiases printer fonts. This is the correct behavior. Antialiasing a screen font just makes it blurry and harder to read.

[CaptainHaddock]

"A printer font is one where the characters are defined by vectors, not bitmaps. Since a screen does not have arbitrary resolution, they need antialiasing to look good. Firefox only antialiases printer fonts. This is the correct behavior. Antialiasing a screen font just makes it blurry and harder to read."

As a graphic designer (both web and print), I'm afraid I have to contradict you. Very, very few fonts contain any bitmapped characters at all, and certainly not at every point size. There is virtually no difference between screen and print fonts, especially now that Truetype and Opentype fonts are becoming ubiquitous. The pixel resolution of even the best monitor is too low to accurately capture letterforms, so anti-aliasing (which doesn't exist in print) is *necessary* to look good. What's more, professional fonts contain hinting guides to help the computer do smarter smoothing.

Now, there are several ways to anti-alias type, and some methods are so sharp you can barely tell. Apple's anti-aliasing technology also incorporates something called "sub-pixel hinting" when an LCD screen is being used. By taking advantage of the fact that each LCD pixel is actuall three sub-pixels (red, green, and blue), you can use coloured anti-aliasing to achieve extra crispness.

In short, non-anti-aliased fonts on a screen are ugly and silly in this day and age. That's one reason OS X looks so beautiful and Windows looks so crappy.

[qnxde]

I'm glad they chose KHTML. I find the output from all Gecko browsers very ugly and hard on the eyes. Also the line spacing is far too close together.

[CharlesS]

Originally posted by qnxde:
I'm glad they chose KHTML. I find the output from all Gecko browsers very ugly and hard on the eyes. Also the line spacing is far too close together.

And also, it's just nice to have more choices on the Mac.

[wataru]

Originally posted by CaptainHaddock:
Very, very few fonts contain any bitmapped characters at all, and certainly not at every point size.

That's why Gecko only leaves fonts un-antialiased when they are such fonts, and even then only at certain sizes.

[Chuckit]

I admit I'm fairly ignorant of the inner workings of Gecko, but surely it isn't responsible for actually rendering text. Otherwise, text on Firefox for Mac should look the same as text on Firefox for Windows, and that ain't the case.

[solbo]

Originally posted by Chuckit:
I admit I'm fairly ignorant of the inner workings of Gecko, but surely it isn't responsible for actually rendering text. Otherwise, text on Firefox for Mac should look the same as text on Firefox for Windows, and that ain't the case.

It uses Quickdraw to render the text and not Quartz.

Gecko just parses and displays XUL/CSS/HTML etc. It uses other libraries and system level things to render things like text.

You see the same thing with a lot of other legacy applications on OS X.

[Catfish_Man]

Originally posted by solbo:
It uses Quickdraw to render the text and not Quartz.

Gecko just parses and displays XUL/CSS/HTML etc. It uses other libraries and system level things to render things like text.

You see the same thing with a lot of other legacy applications on OS X.

They're working on switching to Quartz, partly because of Quickdraw being deprecated, and partly to get better non-English text support.

[EMC]

As a graphic designer (both web and print), I'm afraid I have to contradict you. Very, very few fonts contain any bitmapped characters at all, and certainly not at every point size. There is virtually no difference between screen and print fonts, especially now that Truetype and Opentype fonts are becoming ubiquitous. The pixel resolution of even the best monitor is too low to accurately capture letterforms, so anti-aliasing (which doesn't exist in print) is *necessary* to look good. What's more, professional fonts contain hinting guides to help the computer do smarter smoothing.

Let me contradict you on a few points. Since you are a web graphic designer, this may help you a bit with your career. There is a BIG difference between screen and print fonts. Screen fonts are created as bitmaps and are intended to be viewed as is. Say you're creating a web page about the original Atari. You want to use a font that is very blocky to describe the Atari. You do not want the browser to anti-alias this font. If you use a screen font, firefox won't anti-alias it as it recognizes that it was intended for screen view. Safari doesn't care and anti-aliases screen fonts as well as printer fonts. This is not the proper behavior.

The pixel resolution of even the best monitor is too low to accurately capture letterforms, so anti-aliasing (which doesn't exist in print) is *necessary* to look good.

Newer computers have much higher resolutions then the Macs you use. HP, Dell, and Fujitsu offer laptops at very high resolutions -- enough to merit non-anti-aliased text. You can buy a BTO laptop with 1900x1400 pixel resolution on a 14-inch LCD screen.

Now, there are several ways to anti-alias type, and some methods are so sharp you can barely tell. Apple's anti-aliasing technology also incorporates something called "sub-pixel hinting" when an LCD screen is being used. By taking advantage of the fact that each LCD pixel is actuall three sub-pixels (red, green, and blue), you can use coloured anti-aliasing to achieve extra crispness.

Yes, Microsoft was the first one to introduce this under the trademark "ClearType". While some people appreciate the feature, many, including myself, can't stand it as it makes the text not only blurry, but black text appears red and green at the edges. It gives me a headache...

[CharlesS]

Originally posted by EMC:
Let me contradict you on a few points. Since you are a web graphic designer, this may help you a bit with your career. There is a BIG difference between screen and print fonts. Screen fonts are created as bitmaps and are intended to be viewed as is. Say you're creating a web page about the original Atari. You want to use a font that is very blocky to describe the Atari. You do not want the browser to anti-alias this font. If you use a screen font, firefox won't anti-alias it as it recognizes that it was intended for screen view. Safari doesn't care and anti-aliases screen fonts as well as printer fonts. This is not the proper behavior.

It's a trade-off. Sure, someone might want to make a website about the original Atari, but such cases are definitely a minority. Even in that case, I still think it'd be irritating to have to read through pages of blocky text, and I'd probably just look for some other site about the Atari instead.

The problem is that too many web sites use screen fonts all over the place (like MacNN used to do with Geneva - ugh), which drives my eyes nuts when I view them with the Gecko browsers. It's just really out of place when every other text in the entire OS is anti-aliased. I remember editing the prefs files to replace all instances of Geneva with Lucida Grande back when I used Camino, in the days before the WebCore browsers came out, just to make MacNN not look ugly as hell.

Yes, Microsoft was the first one to introduce this under the trademark "ClearType".

Actually, Apple used this with the Apple IIe, back in the 1980s.

[macmike42]

Originally posted by EMC:
What sort of optimization do you mean? Compiler optimization depends on the gcc/g++ PowerPC optimization routines. Apple has nothing to do with this.

Yes, they do. Check your gcc release notes.

[wataru]

Originally posted by CharlesS:

The problem is that too many web sites use screen fonts all over the place (like MacNN used to do with Geneva - ugh), which drives my eyes nuts when I view them with the Gecko browsers.

Then that's the web site's fault, not Gecko's. You're just using antialiasing to cover up the real problem. I suggest you complain to the sites, or fix the problem with a custom stylesheet or something, rather than endorse a non-solution.

[bmedina]

Originally posted by EMC:
What sort of optimization do you mean?

Mostly stripping out all the stuff that makes Gecko cross-platform. The Mozilla engineers had to re-implement a lot of the things that you'd regularly get from OS frameworks so that the codebase stayed portable. Of course, doing so means that you're working on a branch of Mozilla that isn't easily integrated with the trunk. It's just one big headache in general.

[yskar]

Since one of the basic concepts of Mac OS X is seamless cooperation between various applications, it is natural that Apple chose the rendering engine with more affinity to the core system of Mac OS X. In this respect, KHTML is clearly superior to Gecko.

Take the built-in spell checker in Mac OS X for example. Any pure-Cocoa application can make use of it, and so can Mail.app. However, Gecko-based Cocoa app Camino can't, because it's not pure-Cocoa. If the default web browser couldn't make use of it while the default mailer can, it would confuse the average level users. The same is true with Keychain, which acts differently with Safari and with Camino. I assume Apple hated such kind of inconsistency.
(But Apple has done an inconsistent job, too - you can't customize the Safari Toolbars like Finder, for example.)

Remember, Apple's target is "non-techie", the vast majority of Mac users. Power users will choose what they prefer. We are probably NOT the Apple's target users.

[solbo]

Originally posted by yskar:
Since one of the basic concepts of Mac OS X is seamless cooperation between various applications, it is natural that Apple chose the rendering engine with more affinity to the core system of Mac OS X. In this respect, KHTML is clearly superior to Gecko.

Take the built-in spell checker in Mac OS X for example. Any pure-Cocoa application can make use of it, and so can Mail.app. However, Gecko-based Cocoa app Camino can't, because it's not pure-Cocoa. If the default web browser couldn't make use of it while the default mailer can, it would confuse the average level users. The same is true with Keychain, which acts differently with Safari and with Camino. I assume Apple hated such kind of inconsistency.
(But Apple has done an inconsistent job, too - you can't customize the Safari Toolbars like Finder, for example.)

Remember, Apple's target is "non-techie", the vast majority of Mac users. Power users will choose what they prefer. We are probably NOT the Apple's target users.

That has nothing to do with it. KHTML couldn't make use of any of these things until Apple put a ton of work into breaking it out of QT and KDE and making it a framework. If they had put the same amount of effort into converting Gecko into a system level framework then you could put GUI Cocoa wrappers around Gecko and have the same level of integration.

KHTML is orders of magnitude smaller and more a efficient than Gecko, that is why they chose it. They had limited resources so they had to pick the most maintainable code-base they could. They would probably still be streamlining Gecko if they had went that route.