Declarative CSS, the death of Scriptaculous?
Examples of declarative CSS transitions and animations, which are available in recent versions of Safari. Many of the Scriptaculous features are more elegant using this approach.
Examples of declarative CSS transitions and animations, which are available in recent versions of Safari. Many of the Scriptaculous features are more elegant using this approach.
An extension to mobile Safari that makes tabbed browsing easier. It’s a clever use of bookmarklets and iconic hovering menus that is just plain old fun to use.
Some details on CSS-friendly elements in Safari 3.
Yet another reason for Safari on Windows. Or, queue up the tinfoil and read Cringely’s slant.
I’ve heard a few people wonder how Apple ported Webkit to Windows, so I cracked open depends.exe and took a look at what Safari was linking to. A few of the more interesting dependencies:
So it’s not based on QT, and it doesn’t seem to match the iTunes set (which has no Core* dependencies). Looks a lot like a straight port of some of the base Cocoa libraries.
Apple announced Safari for Windows today at WWDC. The question most people are asking is why?
I see a few likely reasons:
<tin_foil reason="$profit" />I think #1 is a good enough reason, but any of the rest may have been enough to push them to do it. It’s as good as Opera so far, but not likely to replace Firefox for web development (for me).
Update
It looks like the 37Signals guys came to the same conclusion.
Here’s GetWebKit.org, a Windows version of Apple’s Webkit as a Safari-like browser.
Nifty corners (now version 3), implementing rounded-corner div magic (by inserting elements into the DOM). Works in IE 5.5 (and better), Opera, Safari, and Firefox/Mozilla browsers. Here’s an example of what the library can do.
Safari and KHTML again
I just wish to weigh in on debacle to clear up some mistakes. First of all I would like to say I agree with Zack. The annoying part is not that Apple don’t cooperate as much as they could. They are actually helpfull in answering questions and tries at least to separate OS X specific features in the code (allthough they fail miserably at it). No, our problem are users who think Apple does more and underestimate the effort it takes for us to implement patches from WebCore. We are doing this for free and for fun, all we really want is appreciation for our effort.