Welcome. I'm Darin Adler. I'm the director of Safari and WebKit Engineering. We're going to talk a little bit today about Safari and WebKit. Now, you use Safari for website development, but maybe you've never thought about what underlies Safari, WebKit, the engine. Or maybe you're coming to the back in Tosh and you're not really familiar with Safari. You've heard it's the name of the web browser.

or you may be someone who programs with WebKit and uses WebKit and you'd like to hear the latest about what's happening with the technologies. No matter which of these three describes you, this is the right session for you. So let's talk about Safari and WebKit. We're going to cover three things. First of all, I'll talk about what is Safari, what is WebKit, how do they relate, all that stuff, and there's a few announcements and new things to talk about there.

Then we'll talk about the approach we use for WebKit development. We call this open development and it's open source and goes even beyond that. and then we'll also tell you what's new and show you some of the new stuff we've been adding and give you pointers to a whole bunch of sessions throughout the week that cover new developments in Safari and WebKit.

So let's start with the basics. As most of you know, there's the icon of Safari. Safari is the web browser on Mac OS. But it's recently been joined by Safari for Windows, which is the same Safari on Windows. It's absolutely the same browser on both. And in addition, there's Safari on iPhone. So this is the family of Safari web browser. Inside all of these is the same engine, the browser engine, what we call WebKit. and the same WebKit that's inside Safari is available to you when you're writing native applications on both Mac OS X and on iPhone.

Now, what's been happening recently with Safari is lots more people have been using it. In fact, if you take a look at the market share from three years ago, and that was when we first talked about our new WebKit Open development here at the Developers Conference, you see that it's tripled in those three years. And with Safari being used by a lot more people, when you're developing a website, how Safari behaves matters a lot to you.

Today, we'd like to announce a developer preview of a new version of Safari. The Safari 4 developer preview is both on your Snow Leopard developer preview DVDs for those of you attending the developers conference. But it's also something you can download. And you can download it for Mac OS X to work with either Tiger or Leopard. And you can also download it for Windows.

And to get that, you just go to the Apple developer website. So if you go to connect.apple.com and look at downloads, you'll see the Safari 4 developer preview download along with the others. And so a lot of things we're talking about today and things we'll talk about throughout this week are in these new versions, the Safari 4 developer preview and also iPhone 2.0. And we'll mention that as we talk about individual things. So.

One of the things that I want to help you understand is how sharing the same underlying engine affects these different versions of Safari. So let's just talk just for a moment about how the same WebKit in all the different browsers, there still might be some differences. Now, if you went to a session this morning, the one just before this, it was great. And if you didn't go, you can get the audio of it after the developers conference about Safari development on iPhone.

One of the things you heard is that Safari 3.1 on both desktop and iPhone, it's the same basic version of Safari. But there still are some differences. One thing to understand is that every release is always a snapshot. Development is moving fast all the time. We're doing all kinds of great stuff.

And so every release is a point in time. And, you know, they're not going to be identical points in time. Also, there are differences between the platforms. And this morning's session was really about that in depth. How it affects you, whether you have browser windows that can be resized or using the whole screen on iPhone, the mouse input versus touch screen.

and in general though, same engine means you get the same behavior. And so that means for 90% of what you do on websites, the fact that WebKit underlies all the versions of Safari means that the work you do to make it work well with one version of Safari extends to making it work well with all.

One thing mentioned up on the slide here is the way a Safari update means something different to an end user or a website developer or to an application developer using native apps. Safari updates not only include a new version of the web browser, but they almost always include a new version of the underlying WebKit framework as well.

So if you're a native application development, some of those improvements and new features are available to you in WebKit. So we call them Safari updates because to the end user or customer, that's what it is, a Safari update. But to you as a programmer, you may think of it as a Safari and WebKit update.

Now, to understand how to--what's going on with Safari, and in particular, to understand things like if there's a bug, should I report this to Apple or, you know, should I--what system might be responsible? I want to show you a little picture of how WebKit works with the platform.

Now, this is different from a lot of other browser engines. WebKit tries to use--well, not just tries, actually uses platform resources and open source projects for all sorts of things rather than having them built right into the engine. So there's a bunch of areas up here. I'm even going to list them because they're pretty interesting. The networking and cookies, that's really pretty unusual to use a separate networking library. It's not part of the browser. There's a great networking library to use.

Graphics, obviously, don't write--we don't write all of our own custom graphics code. We use the platform graphics. Unicode handling, there's some great sophisticated libraries for handling Unicode. XML, the processing XML files, parsing them correctly. The XSL language, which is a custom language just for manipulating XML. And also, more importantly, what's something that's become much more important recently as we added more and more features that really rely on this capability, database functionality that's used for everything from storing--.

The web pages that make up web applications, you'll hear about that later, all the way down to the smallest bits of data like storing the little icons that show up next to your URLs in the address bar. So for all of these pieces, there's an underlying library that's used.

So WebKit doesn't try to do all this stuff itself and it uses these underlying libraries. So if there are database problems, sometimes the issue is something that is fixed by a new improved version of SQLite. If there's a new encoding to be supported, it's the industry standard ICU library that--where that shows up.

And so that's helpful when you're trying to understand the relationship of WebKit to other Now just a few words about how WebKit, itself, is structured. Just briefly, there are two major pieces of WebKit-- three major, excuse me, pieces of WebKit. The high-level one called WebKit is the outside of WebKit. It's how you get to WebKit. It's where the WebKit API lives.

Inside WebKit is a library called WebCore. And WebCore is a platform independent core, whereas WebKit gives you the perfect programming interface for whatever platform you're working on-- one that fits well, for example, with Cocoa when you're on Mac OS X, fits well with Cocoa Touch when you're on iPhone. WebCore is the platform independent core.

In addition, there's a separate library called JavaScript Core with its own API. And that lets you use JavaScript even when you're not in the context of a web page. So you're free to use that high-speed interpreter for any situation where you want a programming library. But you can use JavaScript Core to do that.

And you can use JavaScript Core to do that in any language. Both of these are APIs-- this is where the two APIs live-- the JavaScript Core And of course, Safari is built on top of these APIs. So let's talk a little bit in specific about one of the WebKit APIs. This is just the Cocoa one on Mac OS X. And there are similar issues for the iPhone one, but I just want to go a little in depth about the Cocoa API on Mac OS X.

The basic concept here is it's a classic Cocoa API. It uses the Cocoa idioms. It fits right in with the rest of the Cocoa app kit and other frameworks. And one of the things that it does that I think makes it particularly convenient to use is the WebView class has this good default behavior. It acts like a web browser does by default. You don't have to tell it to do all the various things.

And then you can customize its behavior, and there's a design pattern for this in Cocoa called delegates. So you supply objects, and then the WebView will consult these objects to ask various questions about how it should behave. And this WebKit API is how Safari uses WebKit, and it's also the basis for many other applications. Lots of our system applications use WebKit for all sorts of purposes, not just browsing. And also, there's tons of third-party applications that have been built on this API.

The way we do development on WebKit is a model that I call open development. So first of all, this is something that--you know, part of this is open source. You hear about open source all the time. And what open source really means is that the license is such that the source code is available. And you can take a look at the licenses used in--the license used in WebKit. It means that we'll always give out the source code and the license spells out what you can do with it.

But open development goes beyond just having source code that's open and goes to a process for developing so that you can see the work as it happens. You can get involved in the development, but you can also see each change as it arrives and follow WebKit development a lot more closely than you can follow development that's not done this way.

And you can also, when you file a bug, see the progress on the bug. That's why it's great to use the open source bug database and watch people's comments and what happens as the bug is diagnosed and eventually fixed. Now, I'd like to ask Mark Rowe, an engineer from the Safari and WebKit team, to come up here and talk a little bit more in depth about open development and Safari and WebKit. Thanks, Darin.

Hi, everyone. I'm Mark Rowe. I'm an engineer on the Safari and WebKit team, as Darren just mentioned. The main point I want to get across is that WebKit development is open. It's not just source code. The entire development process is open. I'm going to touch on three main points here. The first is the number of resources that are available to get involved with the development of WebKit.

Then I'm going to talk about the advantages that this development model brings to you as users of WebKit, as users of Safari as well, and to Apple as well. And third, about how you can get involved with the WebKit project and how you can contribute and the advantages that can bring to you as well.

So first, the available resources. The most obvious one is the source code repository is publicly available. You can download the source yourself, you can compile it yourself, and you can see changes as they happen. Two other important things are the public bug database, which Darin touched on earlier, and the downloadable nightly builds. These two things go hand in hand.

You can download new builds of WebKit every day. You don't have to bother checking out the code if you don't feel like it. You can test out the latest changes, and you can file bug reports. When the bug reports are resolved, you can download a new build, verify the issue has actually been fixed.

Other important factor is communication. We have developers spread out all over the world. We've had developers working from Russia, Israel, Australia, New Zealand, Canada, all over the place. So communication in this case is very important, not in the same office. So we've got IRC channels, we've got a website with a blog on it, you've probably seen the blog before, and we've got mailing lists that we use to communicate as well.

Okay, so on to some advantages the Open Development Model brings. The first is bug and feature visibility. This means that you can file bug reports, you can see bug reports other people have filed, and you can see features as they're being developed. Then there's also the widespread adoption that having the open source development encourages. And third, there's the rapid change that the Open Development Model also encourages.

So as I just mentioned, there is good communication in bugs. The bug database is publicly available. You can log in. You can search for bugs before you file them to see what other people have encountered. You can interact with the engineers that are working on resolving your issues.

And you can basically see exactly when the fix for your bug has been landed. When we land fixes, we say exactly which revision in the source code repository it was fixed in. You can make sure you've got that revision nightly build or source code of that revision, and you can test the fix out.

This also applies to features. When features are landed, we tend to mention them on the blog occasionally. Or if you track the might be builds, you'll see them pop up and you'll be like, well, this is really cool. When you see these new features on the blog, one thing we like to get is feedback on the features.

There are a lot of features we adopt from upcoming standards like HTML 5. These standards are still in heavy development. So feedback that you get about uses of the new features can help shape the way the web standards are moving in the future. This means that it helps ensure that the APIs that are being adopted in the future and the new syntax is the most elegant and simple ones, yet still really powerful.

So WebKit is a great easy to understand code base. It's three quarters of a million lines of code, more or less, which is relatively small compared to other browser engines, but yet it's also really easy to understand and get involved. It has a great feature set. It supports a lot of new upcoming standards. It has great support for existing standards, and it also has exceptional performance. It's one of the fastest browser engines out there. And it does all this in a very small footprint, both in terms of memory use when it's running and the footprint on disk.

This has led to being adopted heavily throughout the system applications in Apple. Obviously, Safari uses it, and iChat uses it for displaying message transcripts, and Dashboard uses it heavily, obviously, as well. It's also used by a lot of third-party applications. It's used by the OmniWeb browser from the Omni Group. It's used by Sandbox from Corealia Software. It's used by many other third-party applications from instant messaging programs through to newsreaders and things like that.

It's also being adopted heavily on different platforms. It's being adopted by Nokia on the S60 platform and by Google for their upcoming Android platform. You might be wondering, why do I care if it's adopted on these other platforms? There are a couple of good reasons to care. The more people that use WebKit, the more testing it gets, the more engineers that are working on it. This leads to improved performance, improved stability, and more bug reports, more bugs fixed. Um, As a wise man once said, many eyes make all bugs shallow.

The second reason is that it promotes web standards. Traditionally, on mobile platforms, web standards have not been something that vendors have cared about. By having WebKit, which is a great standards-compliant browser on lots of more devices, it means you can code to the web standards and things just work great.

It also allows you to adopt WebKit features more widely. Most WebKit features that are WebKit-specific have gracefully degrade on other devices, so it's great to enhance your applications or sites for WebKit and have them work great on other devices as well. So the third main point is, how do you get involved with this project? There are three big ways to get involved, starting from testing, then filing bug reports, and then moving on to contributing of code.

So since the WebKit project, we moved to open development model in June of 2005. We've had over 250 people contribute. This is a huge number of people, and we're very excited about this. But I want it to be even more people. Working with these open source contributors is probably the best part of my job. Dealing with people from all around the world, learning lots of new things about different countries, and also the new skills that these people bring to the project is great.

So there are a lot of different reasons why these people come to the project and contribute. Some of them want to contribute a pet feature. A great example of this is some developers from the KDE project decided that they really liked SVG, Scalable Vector Graphics. So they had a partial implementation of SVG, which they reworked to work with WebKit and then contributed this code to WebKit, which was the basis for WebKit's SVG support.

The second big reason is to fix a pet bug. You may be a user that uses Safari, come across a bug in a website that you use every day and this bug annoys you. Filing bug reports, fixing the bugs is a great way to get those issues resolved.

A third big reason is contributors like to port WebKit to all sorts of crazy platforms. A couple of mainstream ports that we've got in the WebKit Subversion Repository are to the QT toolkit from Troll Tech and to their GTK toolkit as well. People have ported it to all sorts of strange platforms like, what have we got, Aros and some Beos clone as well.

This is not saying that we want open source developers to do all the work and Apple to sit back and take lots of code from everyone. At the moment, it's about 80% of the contributions are from Apple engineers. One reason for this is that Apple has got a habit of hiring all the talented engineers from the open source community because we like people working hard on WebKit.

Okay, so how to get involved. Testing with WebKit is by far the easiest way to get involved. It's really simple. You can download a nightly build from nightly.webkit.org, or you can compile from source yourself. Just have to browse around your favorite sites. If you run into any problems, you can head over to the bug database and file a bug report.

It's also really simple to test these nightly builds of WebKit with your own applications. If you're developing an application that embeds WebKit on the desktop, it's great to know that we haven't broken any functionality in your application. Or you can also get a start on adopting these new features ahead of time.

So, as I mentioned, occasionally you'll be browsing the web, go to a website, you're expecting it to look like this, standard Flickr page. Occasionally, the website will look slightly wonky. That's not good. First step there is filing a bug report. Filing good bug reports is really useful. Bug reports that describe a single problem are the best ones.

Downloading a build of WebKit, noticing a dozen different problems, and writing them in a single bug report makes life difficult for the engineers that will tackle those problems. They have to work out which bugs are related, split them up. It gets complicated. Providing clear steps to reproduce bugs is really useful as well. The easiest way for someone to fix your bug is to be able to reproduce it themselves, and then they can investigate the problem directly. Detailed steps to reproduce is great.

Part of that is providing a URL that reproduces the problem if it's a website that's giving you trouble, or a test application if it's a use of the WebKit API or something like that, which is showing a problem. Including the WebKit version number is very useful. Having a bug report against a six-week-old build of WebKit is not so great because the bug may have already been fixed. Bug reports against three-year-old versions of WebKit are even less useful, so it's great to know upfront whether or not the issue is still going to be there when we look into it.

Okay, so given this Flickr page, there's like thousands of lines of HTML. Where do you go? How do you even start looking at where the problem is? Most websites nowadays are a big mass of HTML, JavaScript, and CSS, thousands of lines, hundreds of kilobytes of code. How do you go about tracking down the problem? It's quite simple process. You create a reduced test case.

Basically, what you do is you start with the original page, you remove stuff that you think is probably unrelated to the problem, you test whether or not the problem still exists. If it does still exist, then the code you removed was unrelated, and you're fine. If the problem no longer appears, clearly the stuff that you removed was actually relevant to the problem at hand.

You go through this process several times, and you eventually end up with something nice and simple. This is a reduced test case for that Flickr problem I showed a picture of earlier. It's like eight lines of code down from several thousand of the original Flickr page. From this, it's relatively straightforward to see where the problem is.

So once you have a reduced test case, where do you even start to look in the code to work out where the problem is, how to fix it, things like that? Or even just how to debug the problem. If you have a reduced test case, it might not be immediately obvious why it's failing. Understanding where the code is makes it really a lot easier to debug the problem in a debugger.

So as Darin mentioned earlier, WebKit is broken up into three main components. There is JavaScript Core. JavaScript Core is comprised of two main parts, the virtual machine, which actually executes the JavaScript code, and the runtime, which provides functionality like regular expressions, string manipulation, maths, and things like that.

Web Core handles the meat of the web browser side of things, which is primarily HTML parsing, which is converting the HTML source code into the DOM tree used by WebKit. There is a CSS, which handles parsing, stylesheets, and associating them with parts of the DOM tree. There is a loading, which is talking to the network layer, CF Network, as Darin mentioned earlier, on the Mac, loading resources from the network layer and parsing them off the rest of WebCore. Then there's rendering and the scalable vector graphics implementation that I touched on earlier.

The third main part is WebKit, which is the API layer of the framework. You may notice that I've got platform glue in two places on this slide, both in WebCore and in WebKit. The reason for this is that WebKit adapts to the platform in two main different ways.

The first way, in the WebKit side of things, in the blue box there, is that it provides a platform-specific API. This makes it really easy for platform developers to use the API. The WebCore side of things is more integrating with the underlying system, so this is using the system libraries, the system functionality, and also things like the system look and feel for form controls and things like that.

Okay, so you understand the code, you know exactly where the bug is. I'm not going to cover how to fix bugs right now. If you want to learn a little bit more about that, we've got a WebKit development lab, I think, immediately after this session. Once you have fixed the bug, it's that easy. Contributing the code back is quite straightforward as well.

We have a great policy of regression testing our code. We have around 10,000 regression tests, which we ensure developers run before every commit that they do. This ensures that no regressions are introduced to our code, which means we can develop at a really fast pace and not risk introducing major problems. We also like to try and enforce a rule of every change has to come with regression tests to ensure that the functionality, the behavior that's changed, no longer causes problems.

A second thing we like to enforce is coding style. As I mentioned, WebKit is about three-quarters of a million lines of code. That's an awful lot of code. Having a consistent coding style makes it easy for new developers to approach the project and you get a handle on the code, and also keeps some of the developers working on it every day sane.

Code review is a third important part of code contribution. It's probably the most important part. Before any commit is landed, it goes through a process of code review, where a developer that's been working with WebKit for a long time goes through the code line by line, makes sure that there's nothing odd about it, makes sure that there are regression tests, that the coding style is consistent, and also looks for any bugs that may be in the code that the developer has missed, and points out any issues that may arise.

This is, in my mind, the most important part of the process, because some of the developers that work on WebKit are very experienced developers. They know a lot of stuff, basically. Working with these senior engineers when I was new to the project taught me an awful lot about WebKit, and also just about programming in general. So it's a great way to learn about programming or just polish up your skills.

So once you've got your patch reviewed, someone on the WebKit team will commit it. Once they're committed, they will eventually make their way out with the WebKit nightly builds and eventually into a release of Safari. Releases of Safari have lots of new features.

Thanks, Mark. So I'm going to tell you about some cool new stuff in Safari and WebKit.

We like coding and we like adding new features, but as we add all this new functionality, we try to keep in mind that we're working for you. We're really listening to web developers and following the world of web technology, and making sure that what we provide is something that really makes sense and will help web developers. We're also listening to widget developers. WebKit is the engine inside Dashboard, so when you're developing all your Dashboard widgets, you can take advantage of all these improvements we've done.

And finally, native application developers are really going to be interested in these new things, too. As Mark mentioned, more and more applications are embedding WebKit to use as part of their display engine or their core user interface. And all of the new stuff-- that we're talking about-- will not only be available in Safari, but in WebKit when you embed it in your app as well.

So we have three basic categories of cool new stuff. We've got standards improvements. All the work we do on WebKit is guided by web standards. These are very important when you're developing for the web, because there's all these different browsers out there. Tragically, not all of them use WebKit yet. So we need standards to sort of file the rough edges off the differences, and make sure everything works consistently.

We also have a lot of great performance improvements. And I'm going to talk about some of the areas where we vastly improve performance. And finally, I'm going to give you highlights of some of the new features that you'll find in this release in the Safari for Developer preview.

So let's talk about standards first. Web standards. There's sort of two areas that we really think about when we're looking at web standards. One is sort of the classics. That all of you will know about if you're familiar with web development. HTML 4.0.1, CSS 2.1, DOM level 2.

These are sort of the core of your web development experience. And it's just sort of bread and butter. And even though these standards have been out for a long time, there's still many fine details where it's taken a long time for the browsers to agree. And we have improvements even down to these basic standards. A lot of bug fixes going on all the time. Another thing that we're looking at is the ability to do a lot of things. Another big area we look at is sort of emerging technologies in the standards world.

Things like SVG. Things like HTML5, the next generation of the HTML standard that adds all sorts of functionality for web documents and web applications. And CSS3, which provides really powerful advanced visual styling. So we're sort of trying to push the envelope on these newer technologies and move the web forward.

and there's also web APIs. These are sort of new APIs that add on to the core DOM interfaces to provide all sorts of additional functionality if you're doing AJAX-style development using JavaScript or what people call Web 2.0 sometimes. These very rich client interactive applications. So, showing a checklist of different standards is well and good, but how do you prove it? Well, In the web standards community, there's this tradition of these things called acid tests.

These are sort of collections of really challenging web edge cases of all the different standards that sort of make sure that you don't have just the most basic support, but that you've really gone and covered every detail of the standard. So let's take a look at how Safari does on the different acid tests.

The original acid test, acid one, was largely a test of CSS layout and the box model. This is something that web developers haven't had to worry that much about in recent years, because most browsers have been passing this test for over five years now, and Safari's been passing it forever.

But this sort of kicked off the tradition of acid tests, and the idea of sort of making their output look like a quirky, funny little picture, so you can see instantly. So, yeah. Whether it looks right, and it's sort of a little amusing. The next acid test to come out was acid two.

Safari was the first browser to pass this, but since then, Opera, and now in their latest beta versions, Firefox and IE as well, also passed this test. This test is actually a lot more challenging than the original acid test. It covers not only CSS, but also many details of HTML parsing and functionality.

It also covers CSS error handling. If you do a lot of web development, you probably know that you often have to put in these hacks to work around certain browsers that may have bugs. I'm not going to say which ones, but its initials are IE. So it's very important for browsers to have interoperable error handlings, that when you put in these hacks, you're sort of trying to go through the error handling of the CSS parser. And it's very important to be interoperable. on that level.

And so, this brings us to ACID 3. And as you can see, here's a pretty little picture with little rainbow-colored boxes. Oh, wait, that doesn't exactly look right, does it? I don't think 41 out of 100 is a very good score. Well, that's what it looked like in Safari 3.0. But since then, we've been working on a lot of improvements.

And in Safari 3.1, released earlier this year, we improved the output a lot. It's looking a lot closer to how it's supposed to look. We fixed many bugs. And now, I'm going to give you a quick demo of what it looks like in the Safari 4 developer preview.

Alrighty, let's just launch Safari here and go to ACID3. And as you can see, pretty picture. So let me show you that again. There it is. So this test, if you follow the web standards world, you probably know there was a lot of discussion a while ago about both Safari and Opera getting very close on that numeric score and also the rendering.

So this test actually has three different pass conditions. One is getting the 100 out of 100 score there, which is passing all the individual sub-tests. But another criterion is matching the reference rendering. And as you can see, I'm flipping tabs back and forth here, and we've got pixel for pixel identical match for the reference rendering.

The third pass condition is smoothness of the animation. And this you can sort of test by looking at the timing of the individual tests. And as you can see, this dialog box reports no timing issues. So I would like to announce today the first browser to fully pass ACID 3, the Safari 4 Developer Preview.

The final area I'd like to talk about is new feature highlights. There's a bunch of new engine features for your web content in the Safari 4 Developer Preview and in iPhone 2.0. I'm not going to cover every last one. I'm just going to give you a couple of highlights of some of the most exciting ones and tell you about the other sessions where you can go to learn more about different feature areas.

Some of the areas we've improved include networking and messaging, where we have a lot of interesting new capabilities. Web applications, lots of things to support offline web apps and that kind of good stuff. Graphics and media, an area that's always been a strong suit for Apple, and now we're pushing all the expertise we have in this area onto the web. And finally, animation, something that's kind of related to graphics and media, but we think it sort of deserves a topic all its own.

So for networking messaging, the key thing we're looking to deliver is to enable secure mashups. Mashups are this new web development technique that's been popular lately that allows you to sort of mix content from two different sites and rearrange it in interesting ways to sort of create something greater than the sum of its parts.

You may have heard, for example, a while ago of an application that someone made that mixes data from Craigslist and Google Maps to give you sort of a map of apartment listings in different cities. Well, we're introducing two things to make mashups a whole lot better. We're introducing cross-site XML HTTP requests.

Thank you. This is a-- we've added security limitations to it, so this is opt-in. But sites can now publish their data APIs to be accessible directly from the client side on other sites. We're also adding cross-document messaging, an API called PostMessage, which is used for sort of the embedding or widget style of mashup.

You may have seen a lot of sites like, for example, iGoogle page that can embed these mini little applets that may come from other sites. So now we've added an API so they can securely communicate back and forth with their containing web page. So this allows you to do a lot richer things with these kind of web widgets.

and a session where you can go to learn more about this is session 403, Using Advanced Ajax Technologies in Safari. That's coming up Thursday. If you just write down the number, you'll hopefully see it on the screens. And this will also cover a lot more interesting Ajax-related stuff. So if you work a lot in that area, you'll be interested in this session.

Next topic I'd like to talk about is next generation web apps. And we have actually two kinds of features that we're bringing to enable better web apps. Some of these are features that are in the WebKit engine itself, and others are in the Safari application. I'm going to talk about both of those.

So for engine features, first feature we introduced is offline data, a SQL database that you can use for local storage, which enables all your data to be stored directly on the client machine. This is available both on the desktop versions of Safari and on iPhone, with iPhone 2.0 and Safari 3.1. So you can use it across the whole range of platforms.

And we think this is going to enable a lot of really interesting things. It's giving you a huge amount of functionality. So for engine features, the first feature we introduced is offline data, a SQL database that you can use for local storage, which enables all your data to be stored directly on the client machine.

This is available both on the desktop versions of Safari and on iPhone, with iPhone 2.0 and Safari 3.1. So you can use it across the whole range of platforms. And we think this is going to enable a lot of really interesting things. It's giving you a huge amount of functionality.

It's giving you a huge amount of rich structured storage that goes way beyond what you can do with cookies. It's giving you a huge amount of rich structured storage that goes way beyond what you can do with cookies. A new feature that we're announcing today is support for offline applications.

This is new in the Safari 4 developer preview. This is very similar to the functionality provided by Google Gears. And we've worked with the Gears team to make this a part of the HTML5 standard. The way this technology works is that you just simply provide a manifest for your application and now automatically, the first time the user visits your web app, all of the resources that make it up, the HTML, the CSS, the JavaScript, and so forth, will be cached locally and it will work offline, transparently.

Combined with the offline data storage, you can use this to build full offline experiences that work just like your real web app. Just the app works offline, you can store the data offline, and you can sync it up the next time the user connects. We also have Safari level features that can make web apps better.

So, a while ago, we introduced Web Clip on the iPhone, which lets you put any website directly on your home screen with its own custom icon, allowing users to sort of treat different websites pretty much the same as they would the native apps of the iPhone. That makes it fit a lot more smoothly into the UI because you don't have to first launch Safari and then go to bookmarks and then pick the right thing. So today, with the Safari 4 developer preview, we're announcing desktop web apps.

This is a feature very similar to what you get with Mozilla Prism. You can have your own custom icons for different applications on the dock and launch them directly without having to go through the browser. And I would like to give you a quick demo of that right now.

Alrighty. Well, this is kind of too boring to be an app, but... I read the Surf and Safari web blog, which follows WebKit development a lot. I think I'd like to have that right on my dock. So I'm just going to go to the File menu and pick Save as Web Application. and boom, there it is. Custom icon, custom name, and we've introduced a few markup level features that let you easily set up your web applications to be launched from the dock. So I'm just going to quit Safari here. Safari's not even running.

And there it is. I got my own app for surfing Safari. Tragically, one of the things that's not in the distraction-free custom web app UI is view source. So I'm going to go back to Safari and show you the very simple things I did to have a custom application name and icon for this site.

Alrighty, here's the application name line. All you have to do is add one meta tag. Meta name equals application name, content equals surf and Safari. A lot of sites have very long titles that may indicate things like status information, like unread count. So this is a way to have a short name for the app, which is what appears in the doc and on the file system. And multi-size icons. You can have a real ICNS file just like you do for Mac apps, which lets it resize nicely in the doc.

This is just the beginning of what it takes to make web applications feel more like native apps. But we think this is a really exciting direction. And now, on the desktop too, users aren't going to have to go through the browser to get to your web apps. They'll be able to save as web application and have an icon straight on their dock to launch your web app. All righty.

Is it for demo? And let's move on. So sessions where you can-- oh, there was my demo slide. OK. Sessions where you can learn more about this. Session 411, Utilizing Offline Data in Safari, will tell you a lot about the application, offline data, and standalone web app features. The standalone web app feature I just demoed.

You can learn how to enable them for your web apps. And that's coming up on Thursday. The other session, unfortunately-- no, wait. Still coming up. Session 352 on Wednesday will tell you a lot about different iPhone development techniques. And that'll tell you how you can use a lot of these web app related features on iPhone.

Next topic I'd like to talk about: graphics and media. So we like to let you do cool stuff. We like to let you make apps that look really smooth and polished and that just make people say "wow" just the moment they first see it. So, We're introducing a lot of features. Starting with Safari 3.1, we support the audio and video elements from HTML5. These make media a first-class citizen of the web. There are no plugins required.

Directly part of HTML, you can reference video and audio files and you have your choice of built-in controls or a rich scripting API that you can use to put audio and video in your web applications and documents and give a rich user experience. We also support SVG as an image. SVG is a technology. It stands for Scalable Vector Graphics, and it's sort of a format similar to PDF or Illustrator in that it has a vector-based scalable description of an image.

And we're now allowing you to use it in the image element or anywhere that CSS images are allowed. So that means if you want to have a fancy scalable background-- All right, thank you, thank you. If you want to have a fancy scalable background, you don't have to waste a lot of bandwidth to send a giant image, you can just have the simple XML file that describes what it should look like. And a lot of the kinds of things you do will totally fit into a very small SVG.

And that's in Safari 3.1, so you can use it today. Next thing we're offering is Canvas Bitmap Access. This is going to allow a lot of amazing things. Apple first introduced the Canvas element to HTML. It's now part of the HTML5 standard. And we will now be allowing you to directly get at the pixels inside the Canvas, which actually, with our new faster JavaScript engine, lets you do client-side image filter effects. And this is really amazing. And when you see the session on this, you will not believe that you can do those kinds of things in JavaScript.

The final thing is Advanced CSS. We supported all the CSS basics for a long time. We like to push the envelope. In the Safari 4 developer preview, we're going to have a lot of awesome new CSS stuff. We are supporting gradients directly in CSS. So no more need to send custom images just to have a gradient background. We know those are very popular.

Now there's direct CSS syntax for it. We support masking, which lets you put little shaped masks around your images or put rounded corners on things, all sorts of cool stuff. And we support reflections. No Web 2.0 app is complete without reflections. Now you don't have to draw a custom image to do it.

All right, and a final topic-- OK, the sessions about this topic where you can learn more are 344, Adding Rich Graphics and Media, which will have those mind-blowing demos that I talked about. That's coming up this afternoon. Don't miss it. And another session, preparing and delivering video for iPhones, Safari, and Apple TV, where you can learn about how to construct your media files to be usable with this new video element to work great on iPhone and all our desktop platforms. So make sure to note these sessions, and you will see lots of cool stuff.

Final topic I'd like to talk about is animation. So in native UI, on the desktop, and on the iPhone, animation is becoming sort of a fundamental paradigm of UI. You don't just automatically switch things and have things jerk around on the user. Everybody wants nice, smooth, flowing animations. And this is becoming very popular on the web too.

And a lot of JavaScript libraries have been written with tons of code to animate your interface elements. And we think that you can do a lot better by providing native animation capabilities in the browser so you don't have to have these piles of script code just to do basic animations.

So the first feature we're introducing in this area is SVG animation in the Safari for Developer preview. This is a standards-based technology that's part of SVG. It sort of lets you make your vector graphics animate different parts of it. And it's sort of like the vector equivalent of an animated GIF.

You can use it for lots of cool stuff. But we think that doesn't go far enough, because SVG is a great technology. But most of you are building with HTML and CSS. And you'd sort of like to animate the content that's already in your web application. So we're introducing CSS transitions on both desktop and iPhone. This is a very powerful technology that lets you, with very simple CSS syntax, animate a transition. from one UI state to another.

We're also introducing CSS transforms, which provide you the full range of affine transforms with CSS syntax. You can rotate things, you can scale them, you can skew them. And these go great with the transitions because often a rotation or a scale is just the kind of thing that you want to animate. So just to give you a taste of what you can do with these technologies, I'm going to do a quick demo of CSS transitions and transforms.

All righty, so I've made this quickie demo of features in Leopard. I know it's a little dated now that Snow Leopard's been announced, but, you know, it was secret. So this is the best you can do. And as you can see, as I hover over these different menu items, they animate smoothly and zoom out. When I click on them, the color changes.

That's also animated smoothly. And as you can see, the image there is rotated. So there's a couple of great things about this besides just the basic thing. One is that I'm doing this all in straight HTML and CSS. There's no fancy plug-ins required just to get this kind of nice, smooth, animated UI. No piles of JavaScript. The other nice thing about it is how easy it is to do.

My HTML is extremely simple here, and if you give me a moment to go to the CSS file, I've had to add very little CSS to get these transitions to animate. Basically, this is it. Just give WebKit transition duration, WebKit transition function, and now when you change the class on an element and its style changes, we'll automatically interpolate the states and give you a nice-looking transition.

So... That's how easy it is. It works right with your CSS-based design. Sure. TextZoom. That is basically all I had to add, those two lines, to this CSS rule to get it to animate. And so you've got the starting background color here. And as you can see, all I've done to affect the transition is there's also this hover rule. This works natively with CSS Hover. And it just adds the styles that changed.

And the transition rules make these automatically interpolate and animate in a smooth way, not a jerky way. So if you want to see what the markup looks like, This is all clean semantic HTML markup. I didn't crup this up. As you can see, I just got an H1 element for the header.

Everything here is an unordered list. In fact, if you try viewing this page without a style sheet, we'll be releasing the code for this demo. If you view this page without a style sheet, you can see that it's perfectly clean HTML, works great with accessibility, works great with search engines, and all that good stuff.

So there you go. Alrighty. And I'm sure you'll be wanting to learn more about these new animation technologies. So you can learn later this afternoon in Creating Rich User Interfaces for Web Content in Safari about this new animation stuff and a whole lot more. And on Wednesday, you can learn about how you can apply these technologies to your iPhone web apps.

So to sum up, The message I'd like to leave you with is this: WebKit is the future of web technology. We're pushing ahead on standards, performance, features and functionality, and we're really pushing the envelope on the web. And we hope that you enjoy using this new stuff in your apps. And now I'd like to hand it back to Darin Adler.

So just before we go and do Q&A, I just want to remind you a little bit more about what was in this session and what's coming up this week. So we talked a little bit about Safari and WebKit, WebKit, the engine inside Safari. We talked about our open development model and this list of new features. And I want you to understand the relationship between these things.

The way our development works and the reason we're able to do so much great new stuff is the rapid progress we can make because of the open development model and the way that we approach it with testing. And that directly translates to more good stuff for you to use.

But even going beyond that, our work is intertwined with the standards work. And so these things that you see in WebKit, and you see them in WebKit first, eventually the other browser engines catch up. A long time ago, ACID 2 was only passing in WebKit. Now the other browser engines are catching up.

The same thing will happen with ACID 3, and the same thing will happen with these other kinds of innovations. So on that note, I'd like to remind you that you can get more information by talking to our evangelists, Vicki Murley and Mark Malone. and I'd like to ask the other speakers and Vicki Murli to come up for Q&A.