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."

Comments

ZDNet took statements out of context

[feelafel]

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

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

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?

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

Official KDE newsflash

[infolib]

here

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
and Dirk Muellers response

-- 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.

Actually

[commodoresloat]

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

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.

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 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:I'm not an Apple user but...

[90XDoubleSide]

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

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), Chimera (Gecko on the Mac).

Now, that same page using Safari

You may notice some differences.

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, which wraps Gecko as a Cocoa NSView sublcass. Safari uses WebCore.

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.

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.