Surprise: Apple's New Browser Is a Sister to Konqueror
January 11th, 2003 by Doc Searls in
Steve Jobs' Macworld keynotes are always Major Events in which lots of new stuff gets announced, but they rarely carry much news of unusual interest to folks on the Linux side of the OS tracks. True, Apple has been talking up UNIX and open source for several years now, and its OS X-based laptops are popular Type O devices in UNIX-y environments, including plenty of Linux shops and households. But hardly anybody expected Jobs to deliver any open-source surprises--least of all a new application based on a code developed by and for the Linux community.

But that's exactly what they did with Safari, Apple's new browser.
There had been rumors that Apple would replace Microsoft's Internet Explorer as the default browser in the OS X "dock". While standing in line with other "media" waiting to be herded into our special section in the keynote theater, I talked with some old-timers who rolled their eyes remembering Apple's last browser effort, the late Cyberdog. The default assumption was that Apple would add to the growing list of browsers based on Mozilla's Gecko engine, perhaps coming out with its own branded version of Chimera.
But that didn't happen. Instead Apple did something far more radical: They based their new browser on KHTML, from KDE.
Here's how Jobs put it in his keynote:
"How did we do this? We based Safari on an HTML rendering engine that is open source. About half the code in Safari is this open-source rendering engine. Now, we started working with this over a year ago. And it needed a lot of improvement. We've dramatically improved the performance. Some things are up to an order of magnitude faster. And, some people have a problem with open source. We think it's great [applause] and, we are going to be putting all of our improvements to this code base -- we're going to be hosting them on the Web today. [Applause.]
The code base that we decided to start with was KHTML. It's very popular in the Linux world. And it was a very well architected HTML rendering engine that is now dramatically improved.... We have built an incredible browser around it. We could not be happier with it.
Avie Tevanian, Apple's development chief, told me this:
"We looked at all the different potential code bases to build a browser on, including building one completely from scratch. And what we discovered was that KHTML gave us the best set of trade-offs between speed, size, quality, ability to render the most sites, things like that. It wasn't always the best at all of these, but for some things it excelled, and we thought we could take our resources and add to it, to make it the best in all these aspects. We'll keep contributing changes, and we expect others will contribute changes back."
KDE's news page added this:
The KDE connection: "[f]or its Web page rendering engine, Safari draws on software from the Konqueror open-source project. Weighing in at less than one tenth the size of another open-source renderer, Konqueror helps Safari stay lean and responsive." The good news for Konqueror: Apple, which said that it will be "a good open-source citizen [and] share[] its enhancements with the Konqueror Open Source community ", has today sent all changes, along with a detailed changelog, to the KHTML developers. Congratulations to the KHTML developers for this recognition of their outstanding efforts.... Hats off to collaboration!
Those developers got the news by this e-mail to Dirk Mueller from Don Melton of the Safari development team.:
From: Don Melton <gramps@apple.com> Subject: Greetings from the Safari team at Apple ComputerDate: Tue, 7 Jan 2003 11:31:10 -0800Hi, I'm the engineering manager of Safari, Apple Computer's new web browser built upon KHTML and KJS. I'm sending you this email to thank you for making such a great open source project and introduce myself and my development team. I also wish to explain why and how we've used your excellent technology. It's important that you know we're committed to open source and contributing our changes, now and in the future, back to you, the original developers. Hopefully this will begin a dialogue among ourselves for the benefit of both of our projects. I've "cc"-ed my team on this email so you know their names and contact information. Perhaps you already recognize some of those names. Back in '98 I was one of the people who took Mozilla open source. David Hyatt is not only the originator of the Chimera web browser project but also the inventor of XBL. Darin Adler is the former lead of the Nautilus file manager. Darin, Maciej Stachowiak, John Sullivan, Ken Kocienda, and I are all Eazel veterans. 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/. How did we do it? As you know, KJS is very portable and independent. The Sherlock team is already using it on Mac OS X in the framework my team prepared called JavaScriptCore. But because KHTML requires other components from KDE and Qt, we wrote our own adapter library called KWQ (and pronounced "quack") that replaces these other components. KHTML and KWQ have been encapsulated in a framework called WebCore. We've also made significant enhancements, bug fixes, and performance improvements to KHTML and KJS. Both WebCore and JavaScriptCore, which account for a little over half the code in Safari, are being released as open source today. They should be available at http://developer.apple.com/darwin/projects/webcore/ very soon. Also, we'll be sending you another email soon which details our changes and additions to KHTML and KJS. I hope the detailed list in that email will help you understand what we've done a little better. We'd also like to send this information to the appropriate KDE mailing list. Please advise us on which one to use. We look forward to your comments. We'd also like to speak to you and we'd be happy to set up a conference call at our expense for this purpose. Please forward this email to any contributor whom I may have missed. -- Don MeltonSafari Engineering ManagerApple ComputerP.S. -- I'm sending you this email while attending Macworld exposition so it may take myself and my staff several hours before we can respond to email. My apologies in advance.
From: Dirk Mueller <mueller@kde.org>Subject: Re: Greetings from the Safari team at Apple ComputerTo: Don Melton @apple.com[......]Date: Tue, 7 Jan 2003 21:18:19 +0100On Die, 07 Jan 2003, Don Melton wrote: > I'm the engineering manager of Safari, Apple Computer's new web browser> built upon KHTML and KJS. I'm sending you this email to thank you for> making such a great open source project and introduce myself and my> development team. I also wish to explain why and how we've used your> excellent technology. It's important that you know we're committed to> open source and contributing our changes, now and in the future, back> to you, the original developers. Hopefully this will begin a dialogue> among ourselves for the benefit of both of our projects.I hope so too. I'm deeply impressed by your detailed changelog and by the changes. A few of the changes have already happened in "our" developing version and many of them were on our TODOs. For example just about this weekend I was working on improving the kjs garbage collector and now I read that you apparently already fixed the issues I had with it. Seems to me like a huge Christmas gift. Thank you. Thanks a lot Especially I'd like to hope that we could set up a mailing list where we could exchange ideas, patches and bug reports. Also a common test suite for regressions would be nice and probably help us a lot in developing KHTML and KJS further. Ideally the plan should be, and I hope you agree, to use a common code base for the backend.> Please forward this email to any contributor whom I may have missed.We've forwarded it to kfm-devel@kde.org.> P.S. -- I'm sending you this email while attending Macworld exposition> so it may take myself and my staff several hours before we can respond> to email. My apologies in advance.Have some nice time there and greetings from Germany, I just watched the Safari presentation :-)
Later that day, this e-mail came back from Don Melton:
Hi,Here is the second email I promised which details our changes and additions to KHTML and KJS which were done for Safari. As it says on our open source web page at http://developer.apple.com/darwin/projects/webcore/ the sources we will post later today are based on KDE 3.0.2. The best way to see every change line by line is to diff against the originals.- --Don MeltonSafari Engineering ManagerApple Computer
On the floor of the show, I followed one of the Safari developers (I think it was Melton) as a guest on David Lawrence's On-line Tonight radio show. Lawrence told me there had been more than 300,000 downloads of Safari on the first day. It was clearly a hot product, but not only because it came from Apple instead of Microsoft. It was a hot performer too.
Everybody I talked to at the show about the browser remarked on its speed, which seems especially swift next to the notoriously tubby Mac versions of Internet Explorer.
Glenn Fleishman, the wireless guru whose Practical Macintosh column runs in the Seattle Times, told me he had heard reports that Microsoft put countless development hours into optimizing IE for Windows, but never did the same for its Mac versions. With Safari, he said, "Apple put to use the thousands of developer hours that went into KHTML, and put in thousands more of their own, all toward solving the rendering problem." The clear implication: browser leadership has passed not to Apple, but to the Open Source development community, where it has belonged all along. He added, "I'm not sure why Mozilla and Gecko didn't do it," he added, "but it's happened with KHTML."
It's hard to avoid the sense that Apple's choice of KHTML was a slight to Mozilla, especially given the fact that so many key members of the Safari team are Mozilla veterans.
While that's an interesting gossip topic, there are bigger issues, such as the challenges Apple faces in its relationships with the Open Source community.James Davidson (author of Learning Cocoa with Objective C and the original author of Apache Ant and Apache Tomcat) said, "Using KHTML in the browser raises the bar on Apple's open-source commitments. It's a love fest right now, but how they do it from here on out will reallly raise the bar. This isn't like Darwin, which was kind of quiet and not highly exposed. This is much more out in the open. I mean, here's this thing staring millions of users in the face that Apple is calling open source. Users will associate this browser with open source and expect bug reports to go through an open-source process. The press will be asking better questions too." (Safari has a bug report button in its titlebar.)
He also wondered how community involvement would jibe with Apple's notoriously secretive development culture. "They love surprises, but that's not how open source works. I'm sure this was the last surprise we'll see on this project. From now on, everything has to be in the open." He added, "The litmus test there will be how close KHTML and Moz will come on standards support. If they come close, that will throw the ball to Microsoft. Then we'll see whether they play nasty again with IE."
But that's just Apple's issue. The larger issue for everybody is standards. Among the geeks I talked to at the show there was complete agreement that Safari's open-source code base created a new de facto condition that favors de jure standards. One Apple engineer explained, "Until Tuesday, the de facto standard was IE. That's what developers cared about, and that's what webmasters cared about. Not any more. Now everybody's going to be holding every browser's feet to the standard's fire. If you fork the standards, you fork yourself." Adds James Davidson, "It's no longer game-over for web standards interoperability. You'd better adhere to standards now."
Safari is far from a finished work. In spite of its 1.0 version number, it's still in beta. It's getting a proper pounding, too -- not only on various lists, but in geek weblogs too. Mark Pilgrim, for example, posted a buglist-filled review that brought frank and useful responses by Apple's Dave Hyatt on his weblog.
There doesn't seem to be any interference by Apple's PR apparatus. This shouldn't be a surprise. Apple engineers and PR people have been telling me for more than two years that they are very careful not to interfere with the company's Open Source community involvement, preferring to "let nature take its course."
We'll see where it goes.
Doc Searls is senior editor of Linux Journal.
Doc Searls is Senior Editor of Linux Journal
Special Magazine Offer -- 2 Free Trial Issues!
Receive 2 free trial issues of Linux Journal as well as instant online access to current and past issues. There's NO RISK and NO OBLIGATION to buy. CLICK HERE for offer
Linux Journal: delivering readers the advice and inspiration they need to get the most out of their Linux systems since 1994.
Sorry, offer available in the US only. International orders, click here.
Subscribe now!
The Latest
Featured Videos
Linux Journal Live - Oct 9, 2008
October 9th, 2008 by Shawn Powers
The October 9, 2008 edition of Linux Journal Live! Associate Editor, Shawn Powers, and Kyle Rankin, "Hack and /" columnist and author of Knoppix Hacks, Linux Multimedia Hacks, Knoppix Pocket Reference and others, discuss Linux distributions.
Linux Journal Live - Oct 2, 2008
October 3rd, 2008 by Shawn Powers
The October 2, 2008 edition of Linux Journal Live! Associate Editor, Shawn Powers, and Steven Evatt, Online Development manager for The Houston Chronicle discuss surviving disaster with Linux.
Recently Popular
From the Magazine
November 2008, #175
There aren't many numbers that put the US national debt to shame, but here's one: 1,100,000,000,000,000. What's that? That's how many floating-point operations per second the Roadrunner supercomputer at Las Alamos can perform. That's about 100 FLOPS per dollar of US debt (unfortunately, the debt is winning the second derivative race). Read the article about Roadrunner in this month's High Performance Computing issue of LJ.
Along with that, find out how to program the Cell processor and how to use CUDA with your NVIDIA GPU. Also in this issue: Mr HandS (aka Kyle Rankin) gives us a few tips on using Compiz, Chef Marcel shows you how to get blogging off your plate quicker, Mick Bauer talks about Samba security, Dan Sawyer interviews Cory Doctrow and Doc talks about how information technology can affect democracy and fix the national debt (just kidding about that last part). That and more for your reading pleasure in this month's Linux Journal.
Delicious
Digg
Reddit
Newsvine
Technorati








Why Apple didn't choose Gecko
On January 13th, 2003 Anonymous says:
The reason Apple didn't choose the more advanced Gecko engine was a political one. Apple may be a "fan" of open source, but they are no fan of Linux or of any effort to make desktop Linux more viable. They chose KHTML in order to drive the wedge between the KDE and Gnome camps deeper. Linux is a significant threat to Mac OS X on the desktop, and don't for a second think that Jobs doesn't know this. By adopting KHTML, they are trying to marginalize Mozilla, thereby adding one more hurdle against the Linux desktop effort.
Re: Why Apple didn't choose Gecko
On January 18th, 2003 Anonymous says:
You are so lost:
1. You are a Gnome zealot
2. Some Gnome zealots take the Mozilla project as own. (Sometimes they want to feel what is like having OpenOffice as a part of the Gnome project too.)
3. You hate KDE, and you don't like that the KHTML was chose by the Safari developers because of its superior code and design.
4. Your feelings were hurt because you would prefer to read: "Apple developers create new great open source browser based on Galeon-Gecko, an interesting Gnome project!"
5. From a user point of view: Gecko is in no way a more advanced engine. Konqueror is faster. Konqueror renders better. Konqueror displays great fonts. Konqueror (KDE 3.1+) behaves better with Java and JavaScript.
Sorry man, Gecko is not so great, and it is no justification for you to start seeing conspirations where they are not.
linuxgonz at netscape dot net
You idiot
On January 15th, 2003 Anonymous says:
that is quite simply the most stupid thing I have read on any message board anywhere in a LONG time.
Umm.. lemme see. can I be bothered to counter your statements? ok:
Gecko codebase is not a good match for OSX. It is over complicated, and tries to inplement much of a 'platform' itself, so it is platform agnostic bigtime.. so Gecko (in it's tech) doesn't even care about LInux particularly.
Umm.. isn't KDE a pretty Linux centric effort? how can using an LGPL project over a GPL project be a divisive move against the Linux project as whole.
You are a fool Mr.
Re: Why Apple didn't choose Gecko
On January 14th, 2003 Anonymous says:
By your logic Linux developers are the biggest threat to the Linux desktop effort. They're the ones who created competing browsers, which hurts Linux. Apple just chose a side.
In fact, you're the biggest threat to the Linux desktop because you too appear to have chosen a side.
Re: Why Apple didn't choose Gecko
On January 13th, 2003 Anonymous says:
What exactly has Gecko (or Mozilla) to do with Gnome? Is Gecko a Gnome-project? No it is not! So how exactly is this "driving a wedge between KDE and Gnome"? Gecko or Mozilla has absolutely nothing to do with Gnome. Well apart from the fact that Mozilla can be used in Gnome (well duh! It can also be used in KDE) and that there is one piece of Gnome-software that uses Gecko. But those two things do NOT make Mozilla or Gecko part of Gnome-project!
Apple chose KHTML over rival implementations for few simple reasons: The codebase is clear and well-written (makes it easy to improve and maintain) and it's alot smaller (only 140.000 lines of code) than other implementations.
It is people like you who make all kinds of absurd claims (like "Gnome has a better office-suite than KDE does! Just compare OpenOffice to Koffice!" when in fact OpenOffice is not a Gnome-project to begin with and can be used just fine in KDE). Please, get a clue before opening your mouth.
Re: Why Apple didn't choose Gecko
On January 13th, 2003 Anonymous says:
I guess he is talking about the default widget library used for building moz. I am also wondering why people refuse to believe that apple might have chosen khtml because of the technical aspects of the code. Friends of Mozilla (tm) seem to be quite upset about this. I do not understand how they promote either one of desktop camps by choosing the other (would they be promoting gnome if they had chosen gecko engine?)
hear herar...
On January 14th, 2003 Anonymous says:
And a thing the Friends of Moz fails to see are that there must be pretty heavy technical reasons based on the simple fact that several of the Safari developers are old Mozilla developers.
Re: Why Apple didn't choose Gecko
On January 13th, 2003 Anonymous says:
Linux is no threat to OS X. they're focussed on different goals. I have to manage UNIX servers in an NT/Novell company. In my case, OS X gives me a desktop that's still UNIX, can run the X Windowing System, and can work with MS Office documents and log in to the Novell network.
When I tried to be productive using my company-issued workstation and Linux, I was forced to dual-boot or use Citrix ICA, neither of which particularly appealed to me.
Besides, most desktop Linux users are of the bargain-basement sort - they're not the sort of user who's interested in paying Apple's premium for their hardware. Conversely, the people who will pay the premium aren't interested in the half-assed integration of the OS and the hardware.
Re: Why Apple didn't choose Gecko
On January 13th, 2003 Anonymous says:
I know what Gnome is, and I know what Mozilla is, but what I don't know is what you are talking about.
Galeon uses Gecko, but Mozilla is a cross-platform internet browser that has nothing to do with Linux desktops.
Ultimately, UI is crucial differentiator, not render engine
On January 13th, 2003 Anonymous says:
In summary, there are many good rendering engines but very few great user interfaces, and in the end, UI is the crucial differentiator b/w browsers.
In response to the whole rendering engine discussion I see here... IMHO Rendering engine/render speed is not everything... Of course, IE for the Mac is dog slow (its carbon, not naitive cocoa code)...and Apple was *forced* to create an alternative or fall behind. The IE for the Mac team was disintegrated long ago to make Web TV, Ultimate TV (a cancelled MS project),etc.
But for most people, more important than rendering speed is an efficient, productive UI (because rendering speed problems have largely been solved in todays best browsers).
Because the web has become so central to computing...UI is more important than ever in browsers. Safari beta (so far) offers a very nice bookmark manager but lacks tabbed browsing (or something like it).
For now, I like Chimera for OS X because it has tabbed browsing and lightning fast rendering performance. On a dial up connection, a user can open pages in new tabs and queue the downloads. This is a very very efficient method of browsing that Safari so far, have chosen to ignore. Tabbed browsing in Chimera is faster and more efficient than IE 6 for Windows. I use a technique whereby each new chimera window contains catagorys of tabs... ebay auction tabs in one window, news tabs in another window, stock data tabs in a third window. By managing topics of tabs by window I never find myself hunting for the correct tab (In IE for windows, I would find myself hunting for the right tab along the Start bar. With too many windows open the start bar becomes cluttered and useless as an interface.)
Chimera (Gecko based) is faster than Safari in my own independent testing...particularly at downloading and rendering JPEGs. When it comes to rendering raw HTML I can't tell the difference between Chimera and Safari but toss in a few jpegs and chimera wins. I imagine this is only noticeable on dial up connections.
I expect Safari will surpass Chimera and therefore all other browsers in UI and performance at some point in the near future because apple is so damn good at what they do.
Re: Ultimately, UI is crucial differentiator, not render engine
On January 16th, 2003 Anonymous says:
Carbon >*IS*< native code. If it is slow, it not because it was written in Carbon.
Not that Cocoa is not a good thing, but so is Carbon.
Re: Ultimately, UI is crucial differentiator, not render engine
On January 16th, 2003 Anonymous says:
> Of course, IE for the Mac is dog slow (its carbon, not naitive
> cocoa code)...and Apple was *forced* to create an alternative
> or fall behind.
I hope you're not suggesting that Carbon is slower than Cocoa. There is no study or statistic that proves it. As a matter of fact, Carbon and Cocoa shares some of the code.
> The IE for the Mac team was disintegrated long ago to make
> Web TV, Ultimate TV (a cancelled MS project),etc.
This statement, however, makes more sense :)
Re: Ultimately, UI is crucial differentiator, not render engine
On January 15th, 2003 Anonymous says:
Just to say, Safari has a speed problem because of it's lack of support for HTTP 1.1 and with it, keep-alives. This is why you see a speed hit on a page made up of multiple objects. Fetching them takes longer than other browsers.
I'm sure this situation cannot last... using Safari on a DSL connetction, this affect is just as noticable (if not moreso) than on a dialup.
Re: Ultimately, UI is crucial differentiator, not render engine
On January 14th, 2003 Anonymous says:
Apple is really slipping in it's attention to UI. I don't think Safari would have made the cut at Apple 5 years ago. The back and forwards buttons are too small. Haven't they ever heard of Fitt's law? In layman's terms, it states: "Make buttons big so it's a bigger target and therefore faster and easier to move the mouse and click on it".
Re: Ultimately, UI is crucial differentiator, not render engine
On January 13th, 2003 Anonymous says:
I, too, like tabbed browsing and continue to use Chimera because of that. I switched off MSIE, which I quite like on Mac OS X, because of tabbed browsing. This UI element is seductive and hard to give up.
Safari seems to have the same rendering "problems" or quirks that I've seen in Mozilla/Gecko based browsers. On my site, some text elements colored and modified with font changes via CSS come out without those changes. MSIE5.2/Mac displays these changes. AFAIK, the CSS I used is legal.
Anyway, although MSIE is Carbon-based, I think it's a mistake to assume that Microsoft won't update it to be faster. Recall that it was one of the first Carbon apps -- it appeared in the Mac OS X Public Beta, long before most companies has any Carbon apps shipping. We can assume that it's using Carbon networking, which may be a bottleneck they can fix. They have a good, highly-rated rendering engine -- let's see if they can speed it up in a future rev.
I like the competition, and that some of it is coming from open source areas. But I'm sure that there are some smart folks working for Microsoft on Mac software (and thereby benefitting this platform), and this may spur them on to be even better.
Re: Surprise: Apple's New Browser Is a Sister to Konqueror
On January 11th, 2003 Anonymous says:
"It's hard to avoid the sense that Apple's choice of KHTML was a slight to Mozilla, especially given the fact that so many key members of the Safari team are Mozilla veterans."
I don't necessarily think so. You'll notice that nowhere on their list of requirements for Safari was 'cross-platform', which is a big part of Mozilla's requirements, and contributes significantly to it's size. KHTML is only intended to run on UNIX-ish operating systems, which Mac OS-X is.
Also notice that any improvements that Apple makes to KHTML's rendering speed and standard adherence is not only unavailable to Microsoft for Windows/IE, but also unavailable to Windows *users*. This will likely allow them to eventually say: "The world's fastest browser doesn't run on windows". This would probably not have been the case if they had chosen Gecko as the basis of Safari.
-- Michael Bernstein
Re: Surprise: Apple's New Browser Is a Sister to Konqueror
On February 10th, 2003 Anonymous says:
I agree completely. This applies as well to all of us Mac users who have no need for a new operating system but would like a faster browser.
Re: Surprise: Apple's New Browser Is a Sister to Konqueror
On January 14th, 2003 Anonymous says:
> 'cross-platform', which is a big part of Mozilla's requirements, and contributes significantly to it's size.
Not true. If Mozilla was based on wxWindows or GTK+, which are also cross-platform, it would be much leaner. The thing was that Netscape's XPCOM, being modelled on MS-COM is bloatware, and being used exclusively in Navigator and Mozilla does not see all the optimization it could.
Re: Surprise: Apple's New Browser Is a Sister to Konqueror
On January 13th, 2003 Anonymous says:
Also notice that any improvements that Apple makes to KHTML's rendering speed and standard adherence is not only unavailable to Microsoft for Windows/IE, but also unavailable to Windows *users*.
That's true for the moment, but now that KHTML is getting some serious development attention, I wonder how long it will be before somebody develops a Windows based KHTML browser? If KHTML evolves into one of the premier rendering engines, it's only a matter of time. Perhaps even Apple will consider a Windows port of Safari.
Re: Surprise: Apple's New Browser Is a Sister to Konqueror
On January 14th, 2003 Anonymous says:
You can use Konq/E a version of Konqueror made to be used with Qt-embedded. Build it against Qt for windows and you have your KHTML windosbrowser. This has been possible for 1-2 yrs. The glory of Qt crossplatform:)
Re: Surprise: Apple's New Browser Is a Sister to Konqueror
On January 13th, 2003 Anonymous says:
Interesting comment...
In response to the whole rendering engine discussion I see here... IMHO Rendering speed is not everything... Of course, IE for the Mac is dog slow (its carbon, not naitive cocoa code)...and Apple was *forced* to create an alternative or fall behind. The IE for the Mac team was disintegrated long ago to make Web TV, Ultimate TV (a cancelled MS project),etc.
But for most people, more important than rendering speed is an efficient, productive UI (because rendering speed problems have largely been solved in todays best browsers).
Because the web has become so central to computing...UI is more important than ever in browsers. Safari beta (so far) offers a very nice bookmark manager but lacks tabbed browsing (or something like it).
For now, I like Chimera for OS X because it has tabbed browsing and lightning fast rendering performance. On a dial up connection, a user can open pages in new tabs and queue the downloads. This is a very very efficient method of browsing that Safari so far, have chosen to ignore. Tabbed browsing in Chimera is faster and more efficient than IE 6 for Windows. I use a technique whereby each new chimera window contains catagorys of tabs... ebay auction tabs in one window, news tabs in another window, stock data tabs in a third window. By managing topics of tabs by window I never find myself hunting for the correct tab (In IE for windows, I would find myself hunting for the right tab along the Start bar. With too many windows open the start bar becomes cluttered and useless as an interface.)
Chimera (Gecko based) is faster than Safari in my own independent testing...particularly at downloading and rendering JPEGs. When it comes to rendering raw HTML I can't tell the difference between Chimera and Safari but toss in a few jpegs and chimera wins. I imagine this is only noticeable on dial up connections.
I expect Safari will surpass Chimera and therefore all other browsers in UI and performance at some point in the near future because apple is so damn good at what they do.
Re: Surprise: Apple's New Browser Is a Sister to Konqueror
On January 12th, 2003 Anonymous says:
Somewhere in the future there may be a port of safari to win32.
http://lists.kde.org/?l=kfm-devel&m=104205219114244&w=2
Re: Surprise: Apple's New Browser Is a Sister to Konqueror
On January 11th, 2003 Anonymous says:
OK Doc, I expect to hear you discuss this more indepth on Tuesday's Linux Show.
Re: Surprise: Apple's New Browser Is a Sister to Konqueror
On January 13th, 2003 Anonymous says:
What is Linux Show, and where can I find more information about it? Thanks! If possible, it would be great if you could also forward your reply to my e-mail address, jclark@nps.navy.mil.
Take care,
John
Re: Surprise: Apple's New Browser Is a Sister to Konqueror
On January 13th, 2003 Anonymous says:
Maybe it is about "The Linux Show": a talk show broadcasted online (Thursdays?) with (seemingly) Americans talking about Linux/Opensource/Freesoftware events of the week.
Look at www.thelinuxshow.com.
Sorry, can't forward the message to your account since it is military and I'm a foreigner and you like weapons too much and I don't want fellows with guns at my porch -- but do come without weapons and have a good time over here... foreigners are always welcome, including those who want to settle here in Brazil.
Post new comment