Slashdot Mirror

I just downloaded Google Chrome 3.0.192.0 for Mac and it crashed before I could even open a page. There is no excuse for this; my Mac Pro is perfect in every way with eight 2.93 GHz cores, 32 GB RAM, and a fresh install of Mac OS X Leopard v10.5.7. Ergo any crashing Google Chrome does is Google Chrome's own fault!

Why is it that Apple and Mozilla can do this but Google can't? I ran Internet Explorer 8 for months before its final release, Firefox 3.5 since its 3.1 days, and found Safari 4 Developer Preview more stable than Safari 3. In fact, even WebKit is more stable than Chrome.

What really baffles me, however, isn't the instability I've come to expect from Google, but that Google has the audacity to ask for personal user info to improve its browser. Is the search engine maker datamonger really so desperate for my private information that it's stooped to the level of Trojan horses to get it?

They should ask me that when it doesn't crash on launch.

Everything Google does is just another way to sieve personal data away for targeting ads. This kind of Big Brother crap is more repulsive than the fat programmers that make it possible. Google, with its deep pockets and doctoral scholars, thinks that by holding user data hostage it can maneuver around Apple and Microsoft. While this may be true, I'm not willing to be a part of it.

In using Google's search, Gmail, Chrome or whatever else the faceless robot of a company invents, the user is surrendering their personal information to a giant hivemind. No longer are their personal preferences some choice they make; they're a string of data processed by a Google algorithm: Google dehumanizes its users!

So while Google is arrogant enough to paint spyware shiny so it can parse our browsing habits, the least they could do is make sure it doesn't crash. If Apple, Microsoft, and Mozilla can get their preview releases right, why can't Google? And now they're making their own operating systems?

Get real, Google! I'll use your crashing codebloat when my Mac is cold and dead and I'm looking for handouts. Until then, quit mining my personal data!

Much of GNOME is moving to WebKit for their HTML needs in it's help system.

http://trac.webkit.org/wiki/ApplicationsGtk

I just downloaded Google Chrome 3.0.192.0 for Mac and it crashed before I could even open a page. There is no excuse for this; my Mac Pro is perfect in every way with eight 2.93 GHz cores, 32 GB RAM, and a fresh install of Mac OS X Leopard v10.5.7. Ergo any crashing Google Chrome does is Google Chrome's own fault!

Why is it that Apple and Mozilla can do this but Google can't? I ran Internet Explorer 8 for months before its final release, Firefox 3.5 since its 3.1 days, and found Safari 4 Developer Preview more stable than Safari 3. In fact, even WebKit is more stable than Chrome.

What really baffles me, however, isn't the instability I've come to expect from Google, but that Google has the audacity to ask for personal user info to improve its browser. Is the search engine maker datamonger really so desperate for my private information that it's stooped to the level of Trojan horses to get it?

They should ask me that when it doesn't crash on launch.

Everything Google does is just another way to sieve personal data away for targeting ads. This kind of Big Brother crap is more repulsive than the fat programmers that make it possible. Google, with its deep pockets and doctoral scholars, thinks that by holding user data hostage it can maneuver around Apple and Microsoft. While this may be true, I'm not willing to be a part of it.

In using Google's search, Gmail, Chrome or whatever else the faceless robot of a company invents, the user is surrendering their personal information to a giant hivemind. No longer are their personal preferences some choice they make; they're a string of data processed by a Google algorithm: Google dehumanizes its users!

So while Google is arrogant enough to paint spyware shiny so it can parse our browsing habits, the least they could do is make sure it doesn't crash. If Apple, Microsoft, and Mozilla can get their preview releases right, why can't Google? And now they're making their own operating systems?

Get real, Google! I'll use your crashing codebloat when my Mac is cold and dead and I'm looking for handouts. Until then, quit mining my personal data!

I just downloaded Google Chrome 3.0.192.0 for Mac and it crashed before I could even open a page. There is no excuse for this; my Mac Pro is perfect in every way with eight 2.93 GHz cores, 32 GB RAM, and a fresh install of Mac OS X Leopard v10.5.7. Ergo any crashing Google Chrome does is Google Chrome's own fault!

Why is it that Apple and Mozilla can do this but Google can't? I ran Internet Explorer 8 for months before its final release, Firefox 3.5 since its 3.1 days, and found Safari 4 Developer Preview more stable than Safari 3. In fact, even WebKit is more stable than Chrome. So what's with Google's Chrome?

What really baffles me, however, isn't the instability I've come to expect from Google, but that Google has the audacity to ask for personal user info to improve its browser. Is the search engine maker datamonger really so desperate for my private information that it's stooped to the level of Trojan horses to get it?

They should ask me that when it doesn't crash on launch.

Everything Google does is just another way to sieve personal data away for targeting ads. This kind of Big Brother crap is more repulsive than the fat programmers that make it possible. Google, with its deep pockets and doctoral scholars, thinks that by holding user data hostage it can maneuver around Apple and Microsoft. While this may be true, I'm not willing to be a part of it.

In using Google's search, Gmail, Chrome or whatever else the faceless robot of a company invents, the user is surrendering their personal information to a giant hivemind. No longer are their personal preferences some choice they make; they're a string of data processed by a Google algorithm: Google dehumanizes its users!

So while Google is arrogant enough to paint spyware shiny so it can mine our browsing habits, the least they could do is make sure it doesn't crash. If Apple, Microsoft, and Mozilla can get their preview releases right, why can't Google? And they're going to come out with their own operating system?

Get real, Google! I'll use your crashing codebloat when my Mac is cold and dead and I'm looking for handouts. Until then, quit trying to syphon off my personal data in between crashes!

I just downloaded Google Chrome 3.0.192.0 for Mac and it crashed before I could even open a page. There is no excuse for this; my Mac is perfect in every way with eight 2.93 GHz cores, 32 GB RAM, and a fresh install of Mac OS X Leopard v10.5.7.

And they want my personal data to help make their browser better? They should ask me that when it doesn't crash on launch.

Why is it that Apple and Mozilla can do this but Google can't? I ran Internet Explorer 8 for months before its final release, Firefox 3.5 since its 3.1 days, and found Safari 4 Developer Preview more stable than Safari 3. In fact, WebKit nightlies run circles around most websites with nary a freeze or crash. So what's with Google's Chrome?

What really baffles me, however, isn't the instability I've come to expect from Google, but that Google has the audacity to ask for personal user info to improve its browser. Is the search engine maker datamonger really so desperate for my private information that it's stooped to the level of Trojan horses to get it?

Everything Google does is just another way to sieve personal data away for targeting ads. This kind of Big Brother crap is more repulsive than the fat programmers that make it possible. Google, with its deep pockets and doctoral students, thinks that by holding user data hostage it can maneuver around Apple and Microsoft. While this may be true, I'm not willing to be a part of it.

In using Google search, Ads, Gmail, Chrome or whatever else the faceless robot of a company invents, the user is surrendering their personal information to a giant hivemind. No longer are their personal preferences some choice they make; they're a string of data processed by a Google algorithm: Google dehumanizes its users!

So while Google is arrogant enough to paint pretty Trojans to try to mine our browsing habits, the least they could do is make sure it doesn't crash. If Apple, Microsoft, and Mozilla can get their preview releases right, why can't Google? And they're going to come out with their own operating system?

Get real, Google! I'll use your crashing, sneaking, spyware when my Mac has gone dead and cold and I'm looking for handouts. Until then, quit the crashing and quit syphoning off my personal data!

That's not an accurate way of looking at it. WebKit has no support for video codecs, period. WebKit delegates media decoding to the underlying platform, much like it does with image decoding. The WebKit tree (at http://svn.webkit.org/) supports three different media backends: QuickTime for Mac and Windows, GStreamer for GTK+, and Phonon for Qt. Both QuickTime and GStreamer have pluggable codec support, and WebKit-using applications will load any video that it has codec support for.

I ran the SunSpider JavaScript benchmark on Chrome 2.0.172.33, Firefox 3.5, and IE8. Firefox was almost 7x faster than IE, and Chrome almost 8x faster. Of particular interest are the contraflow and recursive tests. Chrome: 4.4ms. Firefox: 55.4ms. IE...? 218.4ms. Chrome is fifty times faster than IE in those benchmarks. Embarassing!

Hey did you go through and pick all the non-free bits? Your list certainly isn't a random sampling of software on a Mac. It's possibly a random sampling of GUI software on a Mac. Of course, things like iWork and Aperture are not part of the actual distribution. They're applications that are sold separately.

However, even from your list, XCode is merely a GUI front end for gcc and Safari is just a GUI front end for webkit. Particularly in the case of Safari, you can write a Safari clone with basic functionality on top of webkit in about two minutes.

Happy source browsing!

Many of the UNIX command line utilities are based on open source projects covered by a BSD (or similarly entirely free license), and some are covered by GPL licenses (which are more restrictive and by simple definition are thus less "free" or "open"). The most important GPL software in Mac OS X is arguably the GNU compiler, gcc. Apple is a major contributor to the LLVM project, which will at some point replace gcc as the primary compiler tool chain on the Mac OS X.

Apple has also sponsored a few other interesting open source projects such as Darwin Calendar Server, WebKit, and of course the Darwin UNIX kernel. Most of these projects are covered by a BSD or similar license.

Apple's implementation of the Cocoa Framework is not an open source framework, but it is based on an open specification, OpenStep specification, although it has evolved past the specification. There is an alternative, open source implementation, GnuStep.

There. Fixed it for you.

Do you know of any hotspot or JIT compilers for HTML or JS?

You mean like http://www.mozilla.org/projects/tamarin or http://webkit.org/blog/214/introducing-squirrelfish-extreme for JS?

I assume the root image indicates modifications to GPL source, like Webkit.
Have they published the changes?

WebKit is not GPLed. Their main page states that they are an open source project (their words) with portions available under BSD and LGPL licenses.

Palm doesn't have to release anything if they use BSD code in their software stack. If they use LGPL code then I believe that they have to release their changes and provide a method allowing the end user to replace the LGPLed library with a different library. I'm no lawyer, so I'd suggest that you look at the license for the details.

I assume the root image indicates modifications to GPL source, like Webkit.
Have they published the changes?

WebKit is not GPLed. Their main page states that they are an open source project (their words) with portions available under BSD and LGPL licenses.

Palm doesn't have to release anything if they use BSD code in their software stack. If they use LGPL code then I believe that they have to release their changes and provide a method allowing the end user to replace the LGPLed library with a different library. I'm no lawyer, so I'd suggest that you look at the license for the details.

I assume the root image indicates modifications to GPL source, like Webkit.
Have they published the changes?

WebKit is not GPLed. Their main page states that they are an open source project (their words) with portions available under BSD and LGPL licenses.

Palm doesn't have to release anything if they use BSD code in their software stack. If they use LGPL code then I believe that they have to release their changes and provide a method allowing the end user to replace the LGPLed library with a different library. I'm no lawyer, so I'd suggest that you look at the license for the details.

I assume the root image indicates modifications to GPL source, like Webkit.
Have they published the changes?

WebKit is not GPLed. Their main page states that they are an open source project (their words) with portions available under BSD and LGPL licenses.

Palm doesn't have to release anything if they use BSD code in their software stack. If they use LGPL code then I believe that they have to release their changes and provide a method allowing the end user to replace the LGPLed library with a different library. I'm no lawyer, so I'd suggest that you look at the license for the details.

Yes of course the original KHTML code was the original constituent that was used to create WebKit... but WebKit is a lot more than just html rendering (which is all that KHTML was) and Apple's engineers significantly refactored both the original KHTML and the KJS scripting engine (in fact there is no longer any trace of the original KJS scripting engine in WebKit, that is why everyone only makes reference to the original KHTML now). http://en.wikipedia.org/wiki/WebKit#History. This was the original bone of contention - Apple built completely new engines and was trying to force these back into the main KDE streams

What many people do not realise is that Apple didn't publish their folk for a year, while they worked on it. By the time Don Melton (the lead engineer at Apple) announced it to the KDE community on 7 Jan 2003, over half the original KHTML and KJS code had been replaced because it required other components from KDE and Qt. Don informed the KHTML/KJS teams in an email http://lists.kde.org/?l=kfm-devel&m=104197092318639&w=2 saying: "Both WebCore and JavaScriptCore, which account for a little over half the code in Safari [WebKit], are being released as open source today." The idea was for the KDE team to incorporate WebCore back into the KHTML project. This was only a partial success as some of the WebCore and JavaScriptCore code was never successfully incorporated into the KDE branch.

On 7 June 2005 Apple announced that it was open sourcing all of WebKit [Safari rendering and scripting engines] and not just the abstraction frameworks.

So, already by 2005 (as of Jan 2003, actually) the vast majority of WebKit was already Apple code!

Later in 2005 Apple engineers ported support for Scalable Vector Graphics into WebKit http://dot.kde.org/1121021917/

By the end of 2007, Apple had incorporated HTML 5 Media features http://webkit.org/blog/140/html5-media-support/

A few months later in 2008 the WebKit team announced that they had rewritten JavaScriptCore as "SquirrelFish", a new bytecode interpreter http://webkit.org/blog/189/announcing-squirrelfish/, which was later advanced to SquirrelFish Extreme by the end of that same year. SquirrelFish Extreme compiles JavaScript into native machine code, eliminating the need for a bytecode interpreter and thus speeding up JavaScript execution http://webkit.org/blog/214/introducing-squirrelfish-extreme/. My tip for the future is to watch this space for Apple to out-Pre the Pre with respect to natively compiled HTML5/JavaScript applications that run at machine speed within WebKit.

Keep in mind the fact that there are lots of other bits and pieces that were never part of the original KHTML rendering engine or the KJS scripting engine that now make up WebKit, such as the Drosera a JavaScript debugger, etc.

By this stage, it was clear that Apple's platform abstraction framework and adapter library called KWQ (and pronounced "quack") that replaced the KDE and Qt components that KHTML and KJS relied upon made WebKit the most platform versatile and standards compliant web client; having passed the Acid3 test "with pixel-perfect rendering and no timing or smoothness issues on reference hardware" http://webkit.org/blog/280/full-pass-of-acid-3/. This is when Google, Nokia, Palm, et al started looking in at the true cross platform potential of WebKit.

Now keep in mind that all these developments and innovations to WebKit, since 2003 (at which time half the code was already Apple's code) were added almost entirely by Apple engineers.

Then in June 2007 Ars Technica in

Yes of course the original KHTML code was the original constituent that was used to create WebKit... but WebKit is a lot more than just html rendering (which is all that KHTML was) and Apple's engineers significantly refactored both the original KHTML and the KJS scripting engine (in fact there is no longer any trace of the original KJS scripting engine in WebKit, that is why everyone only makes reference to the original KHTML now). http://en.wikipedia.org/wiki/WebKit#History. This was the original bone of contention - Apple built completely new engines and was trying to force these back into the main KDE streams

What many people do not realise is that Apple didn't publish their folk for a year, while they worked on it. By the time Don Melton (the lead engineer at Apple) announced it to the KDE community on 7 Jan 2003, over half the original KHTML and KJS code had been replaced because it required other components from KDE and Qt. Don informed the KHTML/KJS teams in an email http://lists.kde.org/?l=kfm-devel&m=104197092318639&w=2 saying: "Both WebCore and JavaScriptCore, which account for a little over half the code in Safari [WebKit], are being released as open source today." The idea was for the KDE team to incorporate WebCore back into the KHTML project. This was only a partial success as some of the WebCore and JavaScriptCore code was never successfully incorporated into the KDE branch.

On 7 June 2005 Apple announced that it was open sourcing all of WebKit [Safari rendering and scripting engines] and not just the abstraction frameworks.

So, already by 2005 (as of Jan 2003, actually) the vast majority of WebKit was already Apple code!

Later in 2005 Apple engineers ported support for Scalable Vector Graphics into WebKit http://dot.kde.org/1121021917/

By the end of 2007, Apple had incorporated HTML 5 Media features http://webkit.org/blog/140/html5-media-support/

A few months later in 2008 the WebKit team announced that they had rewritten JavaScriptCore as "SquirrelFish", a new bytecode interpreter http://webkit.org/blog/189/announcing-squirrelfish/, which was later advanced to SquirrelFish Extreme by the end of that same year. SquirrelFish Extreme compiles JavaScript into native machine code, eliminating the need for a bytecode interpreter and thus speeding up JavaScript execution http://webkit.org/blog/214/introducing-squirrelfish-extreme/. My tip for the future is to watch this space for Apple to out-Pre the Pre with respect to natively compiled HTML5/JavaScript applications that run at machine speed within WebKit.

Keep in mind the fact that there are lots of other bits and pieces that were never part of the original KHTML rendering engine or the KJS scripting engine that now make up WebKit, such as the Drosera a JavaScript debugger, etc.

By this stage, it was clear that Apple's platform abstraction framework and adapter library called KWQ (and pronounced "quack") that replaced the KDE and Qt components that KHTML and KJS relied upon made WebKit the most platform versatile and standards compliant web client; having passed the Acid3 test "with pixel-perfect rendering and no timing or smoothness issues on reference hardware" http://webkit.org/blog/280/full-pass-of-acid-3/. This is when Google, Nokia, Palm, et al started looking in at the true cross platform potential of WebKit.

Now keep in mind that all these developments and innovations to WebKit, since 2003 (at which time half the code was already Apple's code) were added almost entirely by Apple engineers.

Then in June 2007 Ars Technica in

Yes of course the original KHTML code was the original constituent that was used to create WebKit... but WebKit is a lot more than just html rendering (which is all that KHTML was) and Apple's engineers significantly refactored both the original KHTML and the KJS scripting engine (in fact there is no longer any trace of the original KJS scripting engine in WebKit, that is why everyone only makes reference to the original KHTML now). http://en.wikipedia.org/wiki/WebKit#History. This was the original bone of contention - Apple built completely new engines and was trying to force these back into the main KDE streams

What many people do not realise is that Apple didn't publish their folk for a year, while they worked on it. By the time Don Melton (the lead engineer at Apple) announced it to the KDE community on 7 Jan 2003, over half the original KHTML and KJS code had been replaced because it required other components from KDE and Qt. Don informed the KHTML/KJS teams in an email http://lists.kde.org/?l=kfm-devel&m=104197092318639&w=2 saying: "Both WebCore and JavaScriptCore, which account for a little over half the code in Safari [WebKit], are being released as open source today." The idea was for the KDE team to incorporate WebCore back into the KHTML project. This was only a partial success as some of the WebCore and JavaScriptCore code was never successfully incorporated into the KDE branch.

On 7 June 2005 Apple announced that it was open sourcing all of WebKit [Safari rendering and scripting engines] and not just the abstraction frameworks.

So, already by 2005 (as of Jan 2003, actually) the vast majority of WebKit was already Apple code!

Later in 2005 Apple engineers ported support for Scalable Vector Graphics into WebKit http://dot.kde.org/1121021917/

By the end of 2007, Apple had incorporated HTML 5 Media features http://webkit.org/blog/140/html5-media-support/

A few months later in 2008 the WebKit team announced that they had rewritten JavaScriptCore as "SquirrelFish", a new bytecode interpreter http://webkit.org/blog/189/announcing-squirrelfish/, which was later advanced to SquirrelFish Extreme by the end of that same year. SquirrelFish Extreme compiles JavaScript into native machine code, eliminating the need for a bytecode interpreter and thus speeding up JavaScript execution http://webkit.org/blog/214/introducing-squirrelfish-extreme/. My tip for the future is to watch this space for Apple to out-Pre the Pre with respect to natively compiled HTML5/JavaScript applications that run at machine speed within WebKit.

Keep in mind the fact that there are lots of other bits and pieces that were never part of the original KHTML rendering engine or the KJS scripting engine that now make up WebKit, such as the Drosera a JavaScript debugger, etc.

By this stage, it was clear that Apple's platform abstraction framework and adapter library called KWQ (and pronounced "quack") that replaced the KDE and Qt components that KHTML and KJS relied upon made WebKit the most platform versatile and standards compliant web client; having passed the Acid3 test "with pixel-perfect rendering and no timing or smoothness issues on reference hardware" http://webkit.org/blog/280/full-pass-of-acid-3/. This is when Google, Nokia, Palm, et al started looking in at the true cross platform potential of WebKit.

Now keep in mind that all these developments and innovations to WebKit, since 2003 (at which time half the code was already Apple's code) were added almost entirely by Apple engineers.

Then in June 2007 Ars Technica in

Yes of course the original KHTML code was the original constituent that was used to create WebKit... but WebKit is a lot more than just html rendering (which is all that KHTML was) and Apple's engineers significantly refactored both the original KHTML and the KJS scripting engine (in fact there is no longer any trace of the original KJS scripting engine in WebKit, that is why everyone only makes reference to the original KHTML now). http://en.wikipedia.org/wiki/WebKit#History. This was the original bone of contention - Apple built completely new engines and was trying to force these back into the main KDE streams

What many people do not realise is that Apple didn't publish their folk for a year, while they worked on it. By the time Don Melton (the lead engineer at Apple) announced it to the KDE community on 7 Jan 2003, over half the original KHTML and KJS code had been replaced because it required other components from KDE and Qt. Don informed the KHTML/KJS teams in an email http://lists.kde.org/?l=kfm-devel&m=104197092318639&w=2 saying: "Both WebCore and JavaScriptCore, which account for a little over half the code in Safari [WebKit], are being released as open source today." The idea was for the KDE team to incorporate WebCore back into the KHTML project. This was only a partial success as some of the WebCore and JavaScriptCore code was never successfully incorporated into the KDE branch.

On 7 June 2005 Apple announced that it was open sourcing all of WebKit [Safari rendering and scripting engines] and not just the abstraction frameworks.

So, already by 2005 (as of Jan 2003, actually) the vast majority of WebKit was already Apple code!

Later in 2005 Apple engineers ported support for Scalable Vector Graphics into WebKit http://dot.kde.org/1121021917/

By the end of 2007, Apple had incorporated HTML 5 Media features http://webkit.org/blog/140/html5-media-support/

A few months later in 2008 the WebKit team announced that they had rewritten JavaScriptCore as "SquirrelFish", a new bytecode interpreter http://webkit.org/blog/189/announcing-squirrelfish/, which was later advanced to SquirrelFish Extreme by the end of that same year. SquirrelFish Extreme compiles JavaScript into native machine code, eliminating the need for a bytecode interpreter and thus speeding up JavaScript execution http://webkit.org/blog/214/introducing-squirrelfish-extreme/. My tip for the future is to watch this space for Apple to out-Pre the Pre with respect to natively compiled HTML5/JavaScript applications that run at machine speed within WebKit.

Keep in mind the fact that there are lots of other bits and pieces that were never part of the original KHTML rendering engine or the KJS scripting engine that now make up WebKit, such as the Drosera a JavaScript debugger, etc.

By this stage, it was clear that Apple's platform abstraction framework and adapter library called KWQ (and pronounced "quack") that replaced the KDE and Qt components that KHTML and KJS relied upon made WebKit the most platform versatile and standards compliant web client; having passed the Acid3 test "with pixel-perfect rendering and no timing or smoothness issues on reference hardware" http://webkit.org/blog/280/full-pass-of-acid-3/. This is when Google, Nokia, Palm, et al started looking in at the true cross platform potential of WebKit.

Now keep in mind that all these developments and innovations to WebKit, since 2003 (at which time half the code was already Apple's code) were added almost entirely by Apple engineers.

Then in June 2007 Ars Technica in

I thought you could totally do that in webkit w/ whatever this: http://webkit.org/blog/55/high-dpi-web-sites/ turned into.

That page recommends SVG, higher-resolution images scaled down in the <img> element, and use of a new, IE-incompatible CSS attribute to scale background images and list bullets. It doesn't help the bandwidth problem that you will want to send less-detailed vectors or less-detailed bitmaps to a device with fewer dots per inch or bits per second.

You can resize images with CSS, but you can't keep the larger size from being transmitted, and you can't make the client-side scaling look good.

I thought you could totally do that in webkit w/ whatever this: http://webkit.org/blog/55/high-dpi-web-sites/ turned into. Did that feature ever happen?

Google was contemplating compiling JavaScript to pure native code in a story I read here on /. a while back, but how well they would maintain this for both x86 AND ARM remains another story,

Yeah, God knows that nobody who has a browser that runs on x86 and a variant that runs on ARM has ever thought about compiling JavaScript to native code, and that Google haven't done more than just contemplate making a JavaScript engine that translates to machine code, much less made versions for both x86 and ARM, and, of course, the Firefox people haven't done anything like that, either.

WebKit is open source. You can get the code if you want - for free, in the same spirit as it was licensed to them via KHTML. Ue Subversion to grab it: http://webkit.org/building/checkout.html

Now, App Store DRM is another kettle of fish, but to rant about WebKit being supposedly closed betrays a lack of understanding.

I think it might be because you're misreading it, having followed PPK (author of QM) for many years I'd be shocked if he had it wrong, he's very thorough!

On that page ( http://quirksmode.org/css/contents.html ) in the "CSS 2.1 Declarations" section under table columns you'll note that all the WebKit based browsers have "incomplete" - ie quirksmode says that WebKit is incomplete for CSS2.1.

What's your reference from the other side, what are the WebKit guys saying isn't finished, does this confirm or contradict?

I found http://webkit.org/projects/css/index.html which says:

Finish CSS2.1 Support
        Most of CSS2.1 has been implemented in WebKit, but a few holes remain. The new white-space values pre-wrap and pre-line are not yet supported. Some of these features have been implemented in the current KHTML tree, and a merge may be possible for some of these features.

However testing those features using Konq3 and Saf4beta2 I find them to work fine. Perhaps WebKit haven't updated this? Particularly one notes that pre-wrap and pre-line are part of ACID3 which the WebKit team claim to have passed with nightly builds of the WebKit engine ( http://webkit.org/blog/280/full-pass-of-acid-3/ ).

I think it might be because you're misreading it, having followed PPK (author of QM) for many years I'd be shocked if he had it wrong, he's very thorough!

On that page ( http://quirksmode.org/css/contents.html ) in the "CSS 2.1 Declarations" section under table columns you'll note that all the WebKit based browsers have "incomplete" - ie quirksmode says that WebKit is incomplete for CSS2.1.

What's your reference from the other side, what are the WebKit guys saying isn't finished, does this confirm or contradict?

I found http://webkit.org/projects/css/index.html which says:

Finish CSS2.1 Support
        Most of CSS2.1 has been implemented in WebKit, but a few holes remain. The new white-space values pre-wrap and pre-line are not yet supported. Some of these features have been implemented in the current KHTML tree, and a merge may be possible for some of these features.

However testing those features using Konq3 and Saf4beta2 I find them to work fine. Perhaps WebKit haven't updated this? Particularly one notes that pre-wrap and pre-line are part of ACID3 which the WebKit team claim to have passed with nightly builds of the WebKit engine ( http://webkit.org/blog/280/full-pass-of-acid-3/ ).

How up-to-date is that page? For example, it says that white-space pre-wrap is not supported, but a quick google search found that they were fixing bugs with pre-wrap in 2008 - which means support for it was implemented at least a year ago.

"Not yet CCS 1 compliant" is a joke. Look at the bugs that remain. They are things like this. If you hold WebKit to such a strict standard, you'll have to do the same with other browsers as well. I guarantee you'll find such bugs in Firefox too, as you will in IE8 when it ships.

The first two lines after the title on the CCS 2.1 test suite page are: "This is a development version of the CSS 2.1 Test Suite. It is woefully incomplete and may contain incorrect tests." If you're using that as the basis to gauge CSS 2.1 compliance, I have a bridge to sell you.

How up-to-date is that page? For example, it says that white-space pre-wrap is not supported, but a quick google search found that they were fixing bugs with pre-wrap in 2008 - which means support for it was implemented at least a year ago.

"Not yet CCS 1 compliant" is a joke. Look at the bugs that remain. They are things like this. If you hold WebKit to such a strict standard, you'll have to do the same with other browsers as well. I guarantee you'll find such bugs in Firefox too, as you will in IE8 when it ships.

The first two lines after the title on the CCS 2.1 test suite page are: "This is a development version of the CSS 2.1 Test Suite. It is woefully incomplete and may contain incorrect tests." If you're using that as the basis to gauge CSS 2.1 compliance, I have a bridge to sell you.

How up-to-date is that page? For example, it says that white-space pre-wrap is not supported, but a quick google search found that they were fixing bugs with pre-wrap in 2008 - which means support for it was implemented at least a year ago.

"Not yet CCS 1 compliant" is a joke. Look at the bugs that remain. They are things like this. If you hold WebKit to such a strict standard, you'll have to do the same with other browsers as well. I guarantee you'll find such bugs in Firefox too, as you will in IE8 when it ships.

The first two lines after the title on the CCS 2.1 test suite page are: "This is a development version of the CSS 2.1 Test Suite. It is woefully incomplete and may contain incorrect tests." If you're using that as the basis to gauge CSS 2.1 compliance, I have a bridge to sell you.

http://webkit.org/projects/css/index.html

So let me understand this...

WebKit isn't yet CSS 1 compliant.

WebKit isn't yet CSS 2.1 compliant, and does not currently pass the CSS 2.1 suite.

WebKit isn't yet CSS 3 compliant, but CSS 3 isn't a finished standard yet anyway. ( http://www.w3.org/Style/CSS/current-work )

IE 8 is coming out with full CSS 2.1 compliance that passes the CSS 2.1 test suite entirely.

CSS 2.1 is the newest *completed* CSS standard level.

But according to the Intarnets, Microsoft should replace their IE Trident engine with WebKit.

Which would reduce their CSS standards support...

I'm confused.

http://webkit.org/projects/css/index.html

So let me understand this...

WebKit isn't yet CSS 1 compliant.

WebKit isn't yet CSS 2.1 compliant, and does not currently pass the CSS 2.1 suite.

WebKit isn't yet CSS 3 compliant, but CSS 3 isn't a finished standard yet anyway. ( http://www.w3.org/Style/CSS/current-work )

IE 8 is coming out with full CSS 2.1 compliance that passes the CSS 2.1 test suite entirely.

CSS 2.1 is the newest *completed* CSS standard level.

But according to the Intarnets, Microsoft should replace their IE Trident engine with WebKit.

Which would reduce their CSS standards support...

I'm confused.

CSS Animation! and other CSS and HTML5 goodies!
http://webkit.org/blog/138/css-animation/

Hate Apple all you want, at least when it comes to the web they care about standards.

As a developer working on WebKit, this is completely wrong and more than a little insulting.

The versions of WebKit included with Safari releases are built directly from the public tree. There is no secret version of WebKit that Apple fixes bugs in for Safari releases before eventually landing the changes in the WebKit tree. The WebKit tree is Apple's official WebKit tree, and is where all of Apple's development on WebKit for Mac OS X and Windows takes place.

For sake of reference http://trac.webkit.org/browser/releases/Apple/Safari%204%20Public%20Beta contains the exact source code of WebKit that was built and released as Safari 4 Public Beta earlier today. There are no secret changes in the version of WebKit that Apple shipped. The changes are all there in the open for the world to see.

I downloaded it onto a MacBook with 3 gigs ram Core2Duo 2.0 ghz latest Leopard 10.5.6 and the first thing it did was replace my stable Safari install WTF!!!???

Then it beach balled as soon as it launched on apples own web site.

So I went through a renaming rigarolmole to see if I could run both 3.21 and 4 beta running (I couldn't).

Then it crashed mail.app when reading rss feeds with a message about being incompatible with growl.

So then I had to run the uninstaller and reboot (again), grand total 40 minutes down the drain with nothing to show for it. If you want to tests squirrelfish use the far more stable nighties:

http://nightly.webkit.org/

I've been using webkit nightly for a while now, but SFX IS much faster than safari3 was the last time I used it. It's about 12 times faster on sunspider:

http://webkit.org/blog/214/introducing-squirrelfish-extreme/

If nitro is simply SFX, then a more honest factoid would be something like typically 33% faster than ff.

Nope.

http://webkit.org/blog/168/gdi-text-on-windows/

The fonts look pretty good in Safari 4. If they're rendered through CoreGraphics rather than GDI, I sure as heck can't tell. (Unlike the heavily overweighted fonts in 3.1.)

Falling Leaves Animation: http://webkit.org/blog-files/leaves/index.html
Bouncing Box Animation: http://webkit.org/blog-files/bounce.html
Rotate and Fade Animation: http://webkit.org/blog-files/pulse.html
CSS Recipes for Effects: http://developer.apple.com/safari/articles/webcontent/cssrecipes.html
CSS Gradients: http://developer.apple.com/safari/library/documentation/InternetWeb/Conceptual/SafariVisualEffectsProgGuide/Gradients/chapter_2_section_1.html#//apple_ref/doc/uid/TP40008032-CH7-SW11
Video tag (requires Quicktime): http://webkit.org/blog/140/html5-media-support/
CSS Gradients: http://webkit.org/blog/175/introducing-css-gradients/
Background Shaped Clipping: http://webkit.org/blog/164/background-clip-text/
Local Database Example: http://webkit.org/misc/DatabaseExample.html

Falling Leaves Animation: http://webkit.org/blog-files/leaves/index.html
Bouncing Box Animation: http://webkit.org/blog-files/bounce.html
Rotate and Fade Animation: http://webkit.org/blog-files/pulse.html
CSS Recipes for Effects: http://developer.apple.com/safari/articles/webcontent/cssrecipes.html
CSS Gradients: http://developer.apple.com/safari/library/documentation/InternetWeb/Conceptual/SafariVisualEffectsProgGuide/Gradients/chapter_2_section_1.html#//apple_ref/doc/uid/TP40008032-CH7-SW11
Video tag (requires Quicktime): http://webkit.org/blog/140/html5-media-support/
CSS Gradients: http://webkit.org/blog/175/introducing-css-gradients/
Background Shaped Clipping: http://webkit.org/blog/164/background-clip-text/
Local Database Example: http://webkit.org/misc/DatabaseExample.html

Falling Leaves Animation: http://webkit.org/blog-files/leaves/index.html
Bouncing Box Animation: http://webkit.org/blog-files/bounce.html
Rotate and Fade Animation: http://webkit.org/blog-files/pulse.html
CSS Recipes for Effects: http://developer.apple.com/safari/articles/webcontent/cssrecipes.html
CSS Gradients: http://developer.apple.com/safari/library/documentation/InternetWeb/Conceptual/SafariVisualEffectsProgGuide/Gradients/chapter_2_section_1.html#//apple_ref/doc/uid/TP40008032-CH7-SW11
Video tag (requires Quicktime): http://webkit.org/blog/140/html5-media-support/
CSS Gradients: http://webkit.org/blog/175/introducing-css-gradients/
Background Shaped Clipping: http://webkit.org/blog/164/background-clip-text/
Local Database Example: http://webkit.org/misc/DatabaseExample.html

Falling Leaves Animation: http://webkit.org/blog-files/leaves/index.html
Bouncing Box Animation: http://webkit.org/blog-files/bounce.html
Rotate and Fade Animation: http://webkit.org/blog-files/pulse.html
CSS Recipes for Effects: http://developer.apple.com/safari/articles/webcontent/cssrecipes.html
CSS Gradients: http://developer.apple.com/safari/library/documentation/InternetWeb/Conceptual/SafariVisualEffectsProgGuide/Gradients/chapter_2_section_1.html#//apple_ref/doc/uid/TP40008032-CH7-SW11
Video tag (requires Quicktime): http://webkit.org/blog/140/html5-media-support/
CSS Gradients: http://webkit.org/blog/175/introducing-css-gradients/
Background Shaped Clipping: http://webkit.org/blog/164/background-clip-text/
Local Database Example: http://webkit.org/misc/DatabaseExample.html

Falling Leaves Animation: http://webkit.org/blog-files/leaves/index.html
Bouncing Box Animation: http://webkit.org/blog-files/bounce.html
Rotate and Fade Animation: http://webkit.org/blog-files/pulse.html
CSS Recipes for Effects: http://developer.apple.com/safari/articles/webcontent/cssrecipes.html
CSS Gradients: http://developer.apple.com/safari/library/documentation/InternetWeb/Conceptual/SafariVisualEffectsProgGuide/Gradients/chapter_2_section_1.html#//apple_ref/doc/uid/TP40008032-CH7-SW11
Video tag (requires Quicktime): http://webkit.org/blog/140/html5-media-support/
CSS Gradients: http://webkit.org/blog/175/introducing-css-gradients/
Background Shaped Clipping: http://webkit.org/blog/164/background-clip-text/
Local Database Example: http://webkit.org/misc/DatabaseExample.html

Falling Leaves Animation: http://webkit.org/blog-files/leaves/index.html
Bouncing Box Animation: http://webkit.org/blog-files/bounce.html
Rotate and Fade Animation: http://webkit.org/blog-files/pulse.html
CSS Recipes for Effects: http://developer.apple.com/safari/articles/webcontent/cssrecipes.html
CSS Gradients: http://developer.apple.com/safari/library/documentation/InternetWeb/Conceptual/SafariVisualEffectsProgGuide/Gradients/chapter_2_section_1.html#//apple_ref/doc/uid/TP40008032-CH7-SW11
Video tag (requires Quicktime): http://webkit.org/blog/140/html5-media-support/
CSS Gradients: http://webkit.org/blog/175/introducing-css-gradients/
Background Shaped Clipping: http://webkit.org/blog/164/background-clip-text/
Local Database Example: http://webkit.org/misc/DatabaseExample.html

Falling Leaves Animation: http://webkit.org/blog-files/leaves/index.html
Bouncing Box Animation: http://webkit.org/blog-files/bounce.html
Rotate and Fade Animation: http://webkit.org/blog-files/pulse.html
CSS Recipes for Effects: http://developer.apple.com/safari/articles/webcontent/cssrecipes.html
CSS Gradients: http://developer.apple.com/safari/library/documentation/InternetWeb/Conceptual/SafariVisualEffectsProgGuide/Gradients/chapter_2_section_1.html#//apple_ref/doc/uid/TP40008032-CH7-SW11
Video tag (requires Quicktime): http://webkit.org/blog/140/html5-media-support/
CSS Gradients: http://webkit.org/blog/175/introducing-css-gradients/
Background Shaped Clipping: http://webkit.org/blog/164/background-clip-text/
Local Database Example: http://webkit.org/misc/DatabaseExample.html

Safari has Webkit @ it's core.

FF devs can look @ the Webkit source. FF devs can also look @ the Google Chrome Source, which is also based on webkit.

In fact, webkit is licensed under BSD + GPL, so IANAL, but I think this mesans FF can even *use* webkit's code directly in their browser ...

> how can the FF figure out how Safari does it?

Man they'd have to like, use the Internet or something: http://trac.webkit.org/browser/trunk

That's the source code to webkit, the rendering engine behind Safari. It's licensed under the LGPL.

The reason, in case you were wondering, is because it was started from an open-source rendering engine called KHTML, which was written by the KDE project. The LGPL made sure that when Apple started improving it their improvements would stay in the open.

And so you *can* in fact see all the nice things Apple has done with Safari and all the speed tricks they're working on.

So if Safari has this great performance, how can the FF figure out how Safari does it?

By heading over to WebKit.org and downloading the open source rendering engine it uses?

I am a fanboi

Right you are! I am a HUGE fan of web standards and the new features that HTML5 is bringing. And because I have experience with browser developers like Apple, Opera, and Mozilla, I trust that they'll do a good job in making the features a reality. Especially since they're the same people writing the standards.

For those who actually care, I've managed to pull up some demos in Safari 4:

http://webkit.org/blog/138/css-animation/
http://webkit.org/blog/176/css-canvas-drawing/
http://www.alistapart.com/articles/cssatten

I must say, I'm impressed! We'll see how well they work in real-world usage going forward.

The browser itself appears to be leaning more toward the UI design of Chrome. Which fits it well, IMHO. The new Coverflow feature is surprisingly slick and doesn't feel tacked on at all. The bonjour integration feels like a new management console for the network. I can surf all the devices and get important information on their location and status. I can even change the settings!

Which makes me wonder if the next version of OS X is going to use Safari-based widgets for network and printer management. Hmm...

At the very least, this is a nice way to surf the network on Windows. ;-)

I am a fanboi

Right you are! I am a HUGE fan of web standards and the new features that HTML5 is bringing. And because I have experience with browser developers like Apple, Opera, and Mozilla, I trust that they'll do a good job in making the features a reality. Especially since they're the same people writing the standards.

For those who actually care, I've managed to pull up some demos in Safari 4:

http://webkit.org/blog/138/css-animation/
http://webkit.org/blog/176/css-canvas-drawing/
http://www.alistapart.com/articles/cssatten

I must say, I'm impressed! We'll see how well they work in real-world usage going forward.

The browser itself appears to be leaning more toward the UI design of Chrome. Which fits it well, IMHO. The new Coverflow feature is surprisingly slick and doesn't feel tacked on at all. The bonjour integration feels like a new management console for the network. I can surf all the devices and get important information on their location and status. I can even change the settings!

Which makes me wonder if the next version of OS X is going to use Safari-based widgets for network and printer management. Hmm...

At the very least, this is a nice way to surf the network on Windows. ;-)

I think you'll find that actually Apple has more openness than Windows

http://webkit.org/
http://developer.apple.com/opensource/index.html

Apple's iPhone may not be as open as it should be but then the same thing could be said about Xbox 360 or even Windows.

I know slashdot hivemind loves to hate apple and I myself am not a fan of this whole iphone lock-in crap (I won't buy one just because they make you sign a $70/mo. contract with AT&T & they won't let you officially tether it), but just to make this discussion a little more even-handed, I'll point out a couple of cases where Apple has "played nice" with open source.

Exhibit A: CUPS. Apple owns it. Nothing bad has happened. In fact it has worked so well that I've been using free gutenberg printer drivers for a laser printer that Apple stopped supporting in Leopard. Works fine.
Exhibit B: Webkit. Apple forked khtml and now there are several browsers for windows, linux browsers are based off it. Nothing bad has happened, and I think we can all agree that webkit is a darn fast browser engine.
Exhibit C: Darwin is open source. That's right, the OS X operating system is open source and released by Apple. Granted, the window manager (quartz) is not, nor are a lot of the apps (like the Finder), but you can always use X11, which btw, apple provides also.

So, it's a little disingenuous to portray Apple as completely proprietary: How many open source projects does Microsoft participate in? Yes I agree that Apple does try to lock you into their hardware, and that sucks, but they're not being completely evil.

The WebKit CSS extensions added in Mobile Safari are interesting. I wish for people to agree on a version of this for all browsers, as it would replace Flash in at least some areas.

http://webkit.org/blog/324/css-animation-2/

You jest, but WebKit is at 100/100 on Acid3 and passes the smooth animation requirement as well.