Yes, WebKit still supports Tiger, though some of the newer WebKit features (hardware-accelerated compositing, 3D transforms, etc) aren’t available as they require support from the underlying OS that isn’t present on Tiger.
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.
What the hell do you think WebKit will use to be built? LLVM.
Err, what? WebKit is compiled with GCC on Mac OS X (4.0 on Tiger, 4.2 on Leopard), and Visual C++ on Windows. Compiling WebKit with llvm-gcc is possible, but I'd only recommend it if you want something that's slower and takes longer to compile.
It's likely that the grandparent is referring to the SquirrelFish Extreme (AKA Nitro) JavaScript engine developed by Apple for WebKit.
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.
The media and video elements are part of HTML 5, are implemented in the WebKit version on which Google Chrome is based, yet are disabled in Google Chrome. Same story for HTML 5's structured storage (local SQL database) support. Google Chrome has significantly worse support for HTML 5 than the WebKit version on which it is based, and thus, than the corresponding Safari release.
Despite using the latest branch of WebKit (the same branch to be used in the next version of Safari),
That is also untrue. Google's currently released version of Chrome is based on the version of WebKit that shipped back in March with Safari 3.1. That version contains all of the HTML 5 goodies that I mentioned earlier. The development version of WebKit, which will eventually be used in the next version of Safari, contains all of this, plus much more.
Don't buy into the Google Chrome hype. Much of it is just that.
Sadly, some of the MPEG video patent holders have big voices in the W3C and demanded that there be no baseline. (What a shock: they don't want to have have a more level compatibility playing field because they don't want to have to compete on quality and price).
If you were to read and understand the discussion rather than spewing bullshit you'd realise that everyone involved, Apple and Nokia included, want to arrive at a common baseline format for the HTML 5 specification. The industry-standard MPEG suite of codecs was considered unacceptable by representatives of Mozilla and Opera due to the licensing costs, while representatives from Apple, Nokia and Microsoft considered Ogg unacceptable due to the risk they would be opening themselves to by adopting these new codecs. Until a solution is found that addresses the concerns of both groups there is absolutely no point in including a baseline in the specification as at least one group would simply ignore the requirement.
Sure, but Mozilla could have been reacting to features in a nightly build of WebKit or a developer seed of Safari, trying to get its own improvements out before the next Safari went final. It plays both ways, and amounts to nothing more than uninformed speculation.
Virtually all of the improvements in Safari 3.1 are in the WebKit engine rather than at the browser application level.
WebKit has/had an open development process. Test builds of WebKit have been available to anyone who wishes to try them, basically since the day after Safari 3.0. Firefox developers, like the rest of us, would have had a very clear and unhindered access to the new WebKit features in Safari 3.1 as it was being developed. I guess this shows that Safari development can improve other browsers even before it releases its own browser.
And what annoys me the most is that WHEN Safari crashes (which are within a day more often, ranging from an hour to 2 days.) all my tabs are lost for all eternity with all the information I was waiting to look at.
Select History -> Reopen All Windows From Last Session after relaunching Safari. If you'd like to see that mechanism improved, head over to http://bugreport.apple.com/ and provide your feedback.
If a browser passes all 100/100 subtests and gets the rendering pixel-for-pixel correct (including the favicon!), then it has passed the standards-compliance parts of the Acid3 test. The rest is just a competition for who can be the fastest.
Firefox 3rc1 displays a red cat favicon when viewing the Acid3 test page, but no favicon when viewing the reference rendering. A quick inspection of the source of the reference rendering shows that the lack of favicon is intentional:
<link rel="icon" href="http://example.invalid/">
WebKit correctly displays no favicon for both pages. The 100/100 score and pixel-perfect rendering leaves only the performance of test 26 to beat.
Firefox and Seamonkey do not implement a HTML rendering engine, the underlying Gecko engine does. Konqueror and Safari use two different HTML engines, KHTML and WebKit. Two of the rendering engines would need to support it, not two browsers built on top of the rendering engines.
No, the blog post is just worded in a somewhat misleading manner. The text used, "WebKit is an open source web browser engine. WebKit is also the name of the Mac OS X system framework version of the engine that's used by Safari, Dashboard, Mail, and many other OS X applications.", is taken from the homepage of the WebKit project over at http://webkit.org/. It is most definitely the same thing used in Safari on Mac OS X.
Just to clear things up a little... The initial port of WebKit to Windows was done by developers that were already active in the WebKit community. This involved refactoring the WebCore library to be less tied to Mac OS X, and implementing Windows-specific portions of the code when required. A small browser-like application named Spinneret was developed for use in testing WebCore on Windows, the first version of which made its way into the WebKit source code repository in January this year.
For the majority of the time since Janurary, WebCore has continued to function on Windows. Various improvements have been contributed, both from people within Apple and members of the open source community. The most common changes in recent times have been minor fixes to ensure that the code compiles on Windows (most of the developers on WebKit work on Mac OS X and some of their changes cause the Windows port to fail to compile).
The Swift web browser makes use of WebCore in a similar way to how Safari uses it: it embeds the WebCore-rendered page in a host application which provides the browser user interface. To suggest that the port of WebKit to Windows was done "by one or two people working in their spare time" is grossly misleading, and is assigning credit for the work to those that did not perform it.
Apple announced that the Xray developers tool in the upcoming Leopard version of Mac OS X will leverage dtrace to perform application tracing, amongst other things. Take a look at the bottom section of http://www.apple.com/macosx/leopard/xcode.html for more information.
Based on the topic if the post, I would suggest that personality conflicts probably played some part in the split of the project.
That said, the majority of your post seems based on the idea that the original project is using significant pieces of code from the new project -- the post clearly says "changelog of the spinoff for small changes that could be used. So, whenever we've found an interesting piece of code (mostly GUI stuff, nothing longer than 20 lines of code)". Your argument would be completely valid, and I would probably agree with it, if the original project was rolling in the new features that they objected to which resulted in the split in the first place.
Slashdot Mirror
Mac OS X software and security updates have updated the Flash plug-in. Safari updates have never updated the Adobe Flash plug-in.
The tiger version of web kit isnt being changed though. It works on tiger and the new version only has to support leopard.
This is simply untrue.
Yes, WebKit still supports Tiger, though some of the newer WebKit features (hardware-accelerated compositing, 3D transforms, etc) aren’t available as they require support from the underlying OS that isn’t present on Tiger.
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.
Err, what? WebKit is compiled with GCC on Mac OS X (4.0 on Tiger, 4.2 on Leopard), and Visual C++ on Windows. Compiling WebKit with llvm-gcc is possible, but I'd only recommend it if you want something that's slower and takes longer to compile.
It's likely that the grandparent is referring to the SquirrelFish Extreme (AKA Nitro) JavaScript engine developed by Apple for WebKit.
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.
It doesn't. Google Gears is not HTML 5.
The media and video elements are part of HTML 5, are implemented in the WebKit version on which Google Chrome is based, yet are disabled in Google Chrome. Same story for HTML 5's structured storage (local SQL database) support. Google Chrome has significantly worse support for HTML 5 than the WebKit version on which it is based, and thus, than the corresponding Safari release.
That is also untrue. Google's currently released version of Chrome is based on the version of WebKit that shipped back in March with Safari 3.1. That version contains all of the HTML 5 goodies that I mentioned earlier. The development version of WebKit, which will eventually be used in the next version of Safari, contains all of this, plus much more.
Don't buy into the Google Chrome hype. Much of it is just that.
Sadly, some of the MPEG video patent holders have big voices in the W3C and demanded that there be no baseline. (What a shock: they don't want to have have a more level compatibility playing field because they don't want to have to compete on quality and price).
If you were to read and understand the discussion rather than spewing bullshit you'd realise that everyone involved, Apple and Nokia included, want to arrive at a common baseline format for the HTML 5 specification. The industry-standard MPEG suite of codecs was considered unacceptable by representatives of Mozilla and Opera due to the licensing costs, while representatives from Apple, Nokia and Microsoft considered Ogg unacceptable due to the risk they would be opening themselves to by adopting these new codecs. Until a solution is found that addresses the concerns of both groups there is absolutely no point in including a baseline in the specification as at least one group would simply ignore the requirement.
If you're not seeing 100/100 on Acid3 with a WebKit nightly build on Mac OS X or Windows you should file a bug report.
Sure, but Mozilla could have been reacting to features in a nightly build of WebKit or a developer seed of Safari, trying to get its own improvements out before the next Safari went final. It plays both ways, and amounts to nothing more than uninformed speculation.
Virtually all of the improvements in Safari 3.1 are in the WebKit engine rather than at the browser application level.
WebKit has/had an open development process. Test builds of WebKit have been available to anyone who wishes to try them, basically since the day after Safari 3.0. Firefox developers, like the rest of us, would have had a very clear and unhindered access to the new WebKit features in Safari 3.1 as it was being developed. I guess this shows that Safari development can improve other browsers even before it releases its own browser.
It works both ways.
To which update do you refer?
You're right, Tamarin has been targeted for integration with SpiderMonkey for more than a year now. And that *still* remains its current state.
And what annoys me the most is that WHEN Safari crashes (which are within a day more often, ranging from an hour to 2 days.) all my tabs are lost for all eternity with all the information I was waiting to look at.
Select History -> Reopen All Windows From Last Session after relaunching Safari. If you'd like to see that mechanism improved, head over to http://bugreport.apple.com/ and provide your feedback.
Apple released Safari 3.1 as a reaction to Mozilla releasing Firefox 3 nearly three months later? That's a rather creative way to spin things.
Apple does very little of the core work for Safari. They just take the open-source WebKit engine and slap their own UI over it
You are incredibly misinformed. A quick glance at recent WebKit changes readily shows how blatantly false your claim is.
Ian Hickson says:Firefox 3rc1 displays a red cat favicon when viewing the Acid3 test page, but no favicon when viewing the reference rendering. A quick inspection of the source of the reference rendering shows that the lack of favicon is intentional:WebKit correctly displays no favicon for both pages. The 100/100 score and pixel-perfect rendering leaves only the performance of test 26 to beat.
Firefox and Seamonkey do not implement a HTML rendering engine, the underlying Gecko engine does. Konqueror and Safari use two different HTML engines, KHTML and WebKit. Two of the rendering engines would need to support it, not two browsers built on top of the rendering engines.
No, the blog post is just worded in a somewhat misleading manner. The text used, "WebKit is an open source web browser engine. WebKit is also the name of the Mac OS X system framework version of the engine that's used by Safari, Dashboard, Mail, and many other OS X applications.", is taken from the homepage of the WebKit project over at http://webkit.org/. It is most definitely the same thing used in Safari on Mac OS X.
Just to clear things up a little... The initial port of WebKit to Windows was done by developers that were already active in the WebKit community. This involved refactoring the WebCore library to be less tied to Mac OS X, and implementing Windows-specific portions of the code when required. A small browser-like application named Spinneret was developed for use in testing WebCore on Windows, the first version of which made its way into the WebKit source code repository in January this year.
For the majority of the time since Janurary, WebCore has continued to function on Windows. Various improvements have been contributed, both from people within Apple and members of the open source community. The most common changes in recent times have been minor fixes to ensure that the code compiles on Windows (most of the developers on WebKit work on Mac OS X and some of their changes cause the Windows port to fail to compile).
The Swift web browser makes use of WebCore in a similar way to how Safari uses it: it embeds the WebCore-rendered page in a host application which provides the browser user interface. To suggest that the port of WebKit to Windows was done "by one or two people working in their spare time" is grossly misleading, and is assigning credit for the work to those that did not perform it.
The US Treasury would disagree with you: http://www.ustreas.gov/education/faq/currency/lega l-tender.shtml#q1. Then again, what do they know?
Apple announced that the Xray developers tool in the upcoming Leopard version of Mac OS X will leverage dtrace to perform application tracing, amongst other things. Take a look at the bottom section of http://www.apple.com/macosx/leopard/xcode.html for more information.
Shit, you've convinced me now. The blogs are saying it so it must be true.</sarcasm>
... were confounded by the move to usb and firewire (the latter of which is also being dropped.)
Bullshit.
Based on the topic if the post, I would suggest that personality conflicts probably played some part in the split of the project.
That said, the majority of your post seems based on the idea that the original project is using significant pieces of code from the new project -- the post clearly says "changelog of the spinoff for small changes that could be used. So, whenever we've found an interesting piece of code (mostly GUI stuff, nothing longer than 20 lines of code)". Your argument would be completely valid, and I would probably agree with it, if the original project was rolling in the new features that they objected to which resulted in the split in the first place.