Welcome to Session 201. This is the Safari and WebKit Overview. My name is Darin Adler and I'm Director of Safari and WebKit Engineering at Apple.

So we'll talk a little bit today about Safari and WebKit. What are they? [Laughs] How you can get involved in the development. WebKit is an open source project. And so you can be involved directly in a way that you can't always with other projects, and also some new technology in the latest versions of Safari and WebKit. So let's start with Safari.

It's-- really if you want to talk about WebKit, the best place to start is the reason we developed WebKit in the first place, and that's the Safari Project. Now as you know, Safari is the web browser on Mac OS X. It's also available on Windows and the new Safari 4. You can download for Mac or Windows. And Safari is also the browser on iPhone. And iPhone 3 contains a brand new version of Safari. Inside all of these different versions of Safari are the same engines, the open source WebKit engine.

Now, a lot of people ask, if I'm a website developer, why should I think about Safari? And there's a simple answer. Lots of people browse the web with Safari. Here's a graph starts four years ago and shows what's been happening with Safari market share and the line just continues to point up. Safari market share is growing. At this point, it's more than 8%. So, you know, one out of every 12 people come in any website is using Safari. Now, this includes both iPhone and desktop versions of Safari.

If you focus in on the mobile space, it's even more compelling story. Safari is the number one browser for people with mobile devices doing web browser. That's 65%. And then if you go past Safari and look at the other web browsers, the next 14% are also other WebKit based browsers. So the same basic engine as Safari.

And everyone else combined is 21%. Now, the latest version of Safari with all the latest features is Safari 4 and iPhone 3. These-- everything I talked about during the rest of the talk, the new features, the things you're hearing about in other presentations this week are in those newest versions.

Now, let's zoom in from Safari and zoom in on WebKit. Where is WebKit in this picture? Well, it's the bottom part. [Laughs] When you take a look at a web browser and there's the edge and the chrome, the things that you use to control what website you're viewing, those are all provided by the browser. But in the content area, this is really the browser engine, and that's what WebKit is, the browser engine.

At this point, something interesting and new has happened. WebKit has become an industry standard. Anyone building a serious mobile phone looks at WebKit and they're choosing WebKit as the engine to build browsers around. And this is really significant. This means that certain types of advances, when they happen in WebKit, that's enough to move the industry forward.

And we're not the only ones to have noticed this. If you're familiar with the history of the Safari WebKit Project, we began with an open source project called KHTML. And Lars Knoll, one of the founders of the KHTML Project said that "WebKit erodes the boundaries between the desktop, mobile phones, and the web." And really what he's talking about here is that the new-- by putting technologies into WebKit, we can move the web forward. Now, when you go-- when you take a look at what people do with WebKit, you'll see a huge number of different applications and of different types.

So here are some desktop applications and I'm not even touching the many of the 50,000 iPhone Papplications. And here are some of them suing WebKit. First of all, there's a bunch of web browsers built on WebKit and you might recognize one of the icons of your favorite browsers up here. But beyond web browsers there's a whole bunch of communication applications from Apple Zone, iChat, to all sorts of different types of chat applications built on WebKit. There are development tools that make use of WebKit. Apple Zone iWeb, tools like Adobe's Dreamweaver and Contribute.

And these are built on top of WebKit as well. There are all kinds of mail, and I guess another type of communication app, Apple's Mail application is built on WebKit. Microsoft's Entourage makes use of WebKit and these others that you see here are all WebKit apps. Adobe has a platform called Air. That's a platform designed around WebKit. And there's a variety of Mac OS X applications that use WebKit and all sorts of different ways.

For example, Aperture uses it as part of its web publishing features. Dashboard is completely based on WebKit as the architecture for what widgets are and so forth. All in all, there are over a hundred applications that are using WebKit as a fundamental part of what they do. And that means that improvements we make to WebKit aren't just about the web browser. They have in effect on any of these apps, including your own. Now, when it comes to using WebKit inside an application, there are two different APIs you use.

One, if you're working on Mac OS X at a different one if you're working on iPhone. And there's a session that goes in detail about each of these. If you're interested in the iPhone UIWebKit class, that's the displaying web content in iPhone application session. And if you're interested in the WebView class, which is what you use on Mac OS X, that's the leveraging web content in Mac OS X applications with WebKit. And these go beyond the surface and talk about the details of what it takes to really take advantage of those Objective-C APIs.

Alright, so that's the basics about what Safari is or WebKit is, who's using it. Now, let's move on to the WebKit Open Source Project and what it takes to get involved with WebKit. You know, it's one thing to say that WebKit is open source.

Open source means that there's certain kinds of licenses and you're allowed to use that source code. But WebKit goes beyond that and has an open development model. That's truly open. That means that you can get involved and see what's going on and become a part of it. And a lot of people have done that.

Since 2005, more than 540 people have gotten involved by contributing. So this is not just someone who came by to see what was going on but have actually had an effect made a bug fix, helped with something like the website, and that's a ton of people that's-- believe me, that's way more than work for me at Apple.

And if you take a look at what the breakdown is of who does what kinds of contributions-- excuse me, of how much of the contribution comes, it's still a little bit over three quarters from Apple and about a quarter from all the other folks combined. That's individuals who've chosen to get involved in the project, and other companies who are contributing.

Now, when I say get involved, the question is how do we all work together and what are the resources we use to work together? The most important one, sort of the central thing that everything else is structured around is the source code itself. And we have a public subversion source code repository.

Anyone interested in the project can check out the latest code. And in fact, all the code changes are seen live in real-time. In fact, if you'd watched last week you would have seen the WWDC branch in our source code repository which was us putting the final finishing touches on the Safari 4 version of WebKit.

There's also a public bug database. And so this means that you can file a bug and see what happens to the bug after you file it, have a discussion with other contributors across companies. And then what goes hand in hand with the bug database is you need something to test. You need to be able to-- if someone says I fixed a bug, you need to be able to try out and see if that fix worked.

And that's what nightly builds are all about. They're not really nightly but they're new builds all the time and you can use those to try out and see if someone who thought they fixed the bug has actually done it successfully. It gives you a preview also of what's happening with the WebKit engine.

Now, nightly builds are builds of WebKit, not of Safari. So they let you try the existing Safari that you have but with the latest, greatest, newest version of the WebKit engine, and they're available for both Mac and Windows. And then finally, the communication channels that we use beyond just the bug database, there's-- the website itself, and webkit.org contains a pointer to all these things. And in fact, if that was the only thing you knew, you could find everything else.

And we also have a mailing list with lots of discussion about development and an IRC channel where lots of the design actually takes place in real-time, people around the world talking to each other about WebKit development. Now I mentioned the bug database, there are a few benefits to having an open bug database. You can see what's going on with the bugs and test fixes right after they're checked in.

Similarly, you get a view of what's happening with features. When new features go into WebKit, often, they are discussed soon afterwards on the blog.

So just by reading the blog, you can keep tabs on what's going on with the project. But also, if you participate in the Mailing Lists on the IRC Channel, you can get feedback about these features while they are under development and before they ever go out in a browser release and provide feedback that really helps shape the future of both the WebKit project and of web technology. And we participate in all sorts of standard organizations and many of these have open membership. So you can help polish features and get them ready for the standards process and even participate in the discussion with the standards organization.

For example, the HTML 5 working group, the W3C has open mailing lists. Alright, so if you wanted to go beyond just following along with features and even talking about features, you can get involved more deeply and the big next steps are testing yourself and reporting bugs based on your testing and then actually submitting patches for our fixes and new features. So let's just go quickly though each of these. Here is what you need to do to test. Step one is to download a build.

Step two, browse the web. That's it. There is no step three. So the nightly builds are really usable if you're using Safari with a nightly build of WebKit. It's often a high quality browser that you can use for your day to day work. And John Gruber of the well-known blog, Daring Fireball, said that his main web browser is the nightly build of WebKit.

You don't just have to be someone who's trying to do software development to experiment with our nightly builds and try out our latest engines. Now, once you do that, you're going to have some experiences like this. Let's say here's an example of a Website with the ancient Safari 4 Public Beta, there. You might remember that from two days ago when it was the latest Safari. And it supposed to look like this but one day you download a nightly build and instead it looks like this. So for you as someone testing, that's an exciting moment because you found bug.

So what do you need to do to write a good bug report? Well these applied almost any project. They're not really specific to WebKit. But what you've going to do is describe one problem. We want problem, one bug report. Give the specific URL, not just the name of the website or even better, a specific test case. Provide steps that say here is what is did first, here is what I saw, that sort of thing, and especially important is to say what went wrong.

You know, a lot of times, it's not clear to the people working on the project what's wrong? Now that one with all the text missing, I think that one is almost self explanatory. Now this is what it would-- it looks like when you go dig down inside the website and might be a little difficult to find the bug. There's a whole lot of code and mark up involved in websites. And so that's the reason for this next process which is called creating a reduced test case.

This is one of the most interesting things to do. You actually learn a lot about web technology just from doing this. I really enjoy it. You start with the failing page, you remove things that aren't really-- that necessary to demonstrate the bug. You'd check to see if it is still showing the same problem, and then you keep doing that, and you keep doing that. And when you're done, hopefully, you end up with something like this.

Now if this shows up in a bug report and it explains in old versions of Safari or in other web browsers, it works like this. In the latest version, it's not doing that anymore. That's something really easy for someone to fix. Well, you know, easier and easy to understand.

And so that's reducing a bug. Now if you're taking a look at the WebKit project and you'd like to make a code change, you're going to need to know something about what's where in the WebKit code. So I'm going to tell you a tiny bit, just a little bit of it right here in this session. The lowest level is something called JavaScriptCore.

And inside JavaScriptCore is the Nitro JavaScript engine including the JIT, and the virtual machine to compile to native code, and also the runtime that includes all the things that are-- that go beyond just the constructs of the language and go to the library that's part of the JavaScript Language as well and all the objects. And also, some basic data structures that we use throughout the WebKit project.

Not just for JavaScript but for the higher level pieces as well. The next level up is called WebCore. This is where you find a lot of-- what you think of as the web engine, the HTML parser, CSS and DOM parsing, computing styles, SVG and XML parsing, all the code that-- to do the fairly subtle and complex process of loading a webpage. The glue that attaches WebKit each of the specific platforms that it works on, there's a layer just to abstract those platform differences, and also the rendering engine. Finally, there's a top level and it's called WebKit. And yes, it's true.

One of the pieces of WebKit is also named WebKit. And there's a good reason that this is the part that has the WebKit name. It's the public part of WebKit. It's the face of WebKit. When you're using WebKit API, you'll either be calling directly to JavaScriptCore if you're using JavaScript alone or calling to WebKit if you're using web APIs-- excuse me, if you're using WebKit in your application.

And that's where the public API lives and also some of the platform glue. You can think of they're been glued that attaches to the platform above and then below WebKit. So anyway, that's what's where you'll need to do that if you're going to contribute and there are all kinds of things that you need to know to successfully contribute. We have test-driven development in WebKit which means that there are-- I guess about 11,000 regression tasks that you run every time before you're about to check-in any changes.

And test-driven development means if you're going to make a new change or fix a bug, the first step is to write a new test. And we require tests for bug fixes. There has to be a test that would fail before your fix and succeed afterwards. There's also some coding style. We like to keep the style consistent and others coding style documents on the website. And there's a whole code review process to make sure that we can do development really quickly.

You know, having this process in place and all this contributors enables us to move the project really fast and do all sorts of new features while keeping the web and applications working. So there are all kinds of details on the website. You may want to contribute because there is a bug that is driving you crazy and you'd like to fix it yourself. You might have a feature that you're really interested in, that others other aren't as interested in that you'd like to implement or help with or you might be wanting to port to a new platform.

So those are the kinds of things that draw people to the project. And I think it's pretty exciting how open development makes it possible for you to get involved. Alright, so let's talk a bit now about new technology. It's pretty exciting with Safari 4 and iPhone 3. We've got all kinds of things that we've been working on sometime that are now in your hands. So let's talk a little bit about these. First of all, the approach we take to new technologies, an innovation in the webspace is standards.

What I mean by that is that what we invent something new, we're not trying to create something that's exclusively in one web browser. We wanted to lift the whole web as a platform, that's we want to use standards as a way to collaborate with others working with web technology so that all of this stuff works together.

We also believe that standards are not just important to us for new things that we're doing but they're important for the integrity of the existing web and to help make it possible for the same websites to work with the whole variety of web browsers. That's the reason why we take standards compliance tests like the beautiful Acid 2 test.

That's what it looks like when it runs correctly. And years ago, this test was created to help test some of the trickier bits and edge cases of the CSS standard that were really affecting website compatibility. And Safari was the first to pass this test. And nowadays, many other browsers are now completing the-- fixing the last few bugs they have so that they have the exact same behavior on this test.

A more recent test is the Acid 3, and still, no beauty prize winner. But what's hidden beneath the surface of a test like this is the 100 different individual tests. And I don't mean a 100 single focus tests but 100 tests with many different pieces, each of which tests another aspect of web technology.

And Acid 3 really concentrated on the technologies that are needed for AJAX, or Web 2.0 web applications, and the kind of corner cases that were creating unnecessary complexity and incompatibility for people developing web applications.

As with Acid 2, Safari was the first browser to pass the Acid 3 test.

And we think that these kinds of standards related activities where we make sure that the standards are precise about edge cases that cover all sorts of things are just great for web standards and inoperability between browsers. In the standards world, one of the most interesting and exciting things going on right now that we're really thrilled to be a part of is HTML 5.

There is all kinds of great work being done there. HTML 5 is where our own canvas invention, one of the earliest web standard things we did with Safari, creating the canvas element. That's part of the HTML 5 specification. And there are all sorts of other critical exiting new technologies as well as clear documented standardization of existing web behavior that are all part of HTML 5. One of the areas in HTML 5 where there's some truly revolutionary stuff is offline applications.

There are a suite of technologies in HTML 5 that all work together to make possible web technology that works, even if you're not necessarily connected to the internet. There are storage technologies that allow you to store the data of your applications. And also there is the application cache which is a technology that lets a website define what's in the site so that it can be stored locally, so that the whole website can still be present when you don't have a connection to its server. Now to show you a little bit about what's possible with one of these offline applications technologies, I'd like to invite our Safari Technologies Evangelist, Vicki Murley, up on stage.

Thanks Darin. So we wanted to create an application that showed off some of the capabilities of HTML 5 offline data. So we decided to create a calendar application. Here it is. You can see it looks and feels a lot like a native built-in calendar application.

I can add an event right here. I'm going to go snorkeling. But because it's a web application running in Safari, we get a couple of other features that's just kind of come naturally. So for instance, I'm going to put in the location here, and when I tab away I get, oops, an inline map that shows me exactly where I'm going to go.

So the UI for this calendar application looks pretty very good. But some of the real power of this app is happening behind the scenes. So for instance, if I pull up this filtered search field here, I can enter a query and find all of my events that are related to Maui or all of my events that are at Moscone.

So the reason that is so fast is that a copy of all of my calendar events are being stored locally on this machine using HTML 5 local data capabilities.

So which one of the HTML 5 local data features is used here?

This is using the HTML 5 SQL API.

So I'm executing SQL statements in JavaScript and storing these in a local database on this machine, and that's why this filtered search is so fast I can show you more about how that works if I open the Web Inspector and click on the databases tab. You can see I have a database here and a table within it called WebKit Calendar Events.

And if I click on the events database I can type in some SQL statements and execute them right here. And this is super useful if you're testing out a couple of statements that you are adding in JavaScript, very useful for us when we were creating this application.

So I guess if that's a database there could be a lot more than just 50 events in there?

That's right.

Yeah, it can handle anything that you throw at it, industrial strength.

Alright.

OK.

Thanks Vicki.

Sure.

Why don't plug-in--

So we have a lot more to tell you about these technologies in particular, local storage and offline web applications.

There's a session about that. That's this Thursday, right here in this room. And tomorrow if you'd like to learn more about the Web Inspector and development tools, we used a tiny bit there just to look at the database. But there's a whole lot in there, and a whole bunch of improvements since the last version if you've seen it before. And you could see that tomorrow in the Nob Hill room. So let's talk about another area where there's some great new technology in WebKit, and that's the Nitro JavaScript engine. Now this is the JavaScript engine that's in WebKit, it's part of the WebKit open source project.

And it's really been improved a huge amount since our previous releases. If you take a look at desktop Safari, and just let's take the baseline of Safari 3. Now this was at the time Leopard was released, Safari 3 was the browser and it had the fastest JavaScript engine that had ever been in web browser.

And so that's our baseline. That's where we're starting out. So we had a number of releases, a lot of you might be running Safari 3.1 or 3.2 if you are using Leopard. And there was a huge speedup. Safari 3.1 was 2.7 times faster. It's not often you get that big a speedup just from software changes on the same JavaScript.

By the way, these numbers are based on the SunSpider JavaScript Benchmark, the same one you might remember from yesterday's keynote. Now when Safari 4's preview came out at a-- and it was actually at last year's developers conference. We were already up to 4.2 times faster than Safari 3's performance on the same scripts.

We released a Safari 4 Beta, and that was, I don't know a few months ago? And by that time with the new Nitro engine, and that's the first time we used the name Nitro, you saw performance that was 11 times faster than Safari 3, so huge, more than an order of magnitude.

And I'm really proud to tell you about how fast the version of Nitro that's in 64-bit applications like Safari on Snow Leopard. It's almost 20 times faster than the Safari 3 engine. So this is fundamental, 20 times faster means there are things you can do that just weren't practical before. Now I'd like to ask Vicki to come back up on stage and show you a bit about that.

So, when you think of applications that you can develop using web technologies, you might not think of very math-intensive graphics operations. But we actually couldn't think of anything better to show of the JavaScript performance improvement between Safari 3 and Safari 4. So we're using Snow Leopard here and we have a build of Safari 3.

Wait, wait.

Yes?

So I can't do that at home, right?

You can't try this at home, no--

OK, OK--

-- we had to--

-- the Safari 3 on Snow Leopard doesn't exist

-- make some special accommodations here. But what we have here is a fluid dynamic simulator that's done entirely using web technologies, specifically JavaScript and the HTML 5 canvas tag APIs. So as I mouse over the black square here, you can see that some pixels are drawn and they kind of move around the square like a [inaudible].

So JavaScript is doing all the math there?

That's right.

JavaScript is doing all the computations to tell the pixels how to move across the screen. And we're also drawing to the canvas using the canvas JavaScript APIs. So you can see the performance here. I have frames per second down in the corner. It's only about 7 right now.

Oh yeah. That's-- so that-- I mean I know from playing computer games that under 10 usually looks kind of choppy.

Yeah it's not very good, 7 is not good. And even if we bump the resolution up to high, things get even worst [laughs].

So we only have about 2 frames per second here. But lucky for us, the great thing about having a JavaScript engine that is 20 times faster is that you can do all kinds of things that you might not think are even possible. So let's start up Safari 4 and go back to our fluid simulator, same exact webpage here.

And if we have it set on normal resolution, you can see that the-- already that the drawing is just much smoother than it was before. And we're getting up around 60 frames per second. We can even bump this up to high resolution. And there you can see even more. The level of detail that's now possible with our powerful new improvements.

So there we go.

Alright, so I don't think there's anything quite as good as a graphics demo to really make clear performance differences. And while I still think, if you're doing a fluid simulator for scientific research, you'll probably want to use OpenCL. For almost anything else that you're doing with JavaScript, this great speed up can make a real difference. And even if you're just using the web browser, the faster JavaScript contributes to making browsing of website a lot faster. Now, let's talk a bit about other aspect of web technology that are new in these latest versions.

The HTML 5 media elements is particularly interesting area for us. We love to have multimedia sound and video as part of websites. And before Apple proposed these media elements to the HTML 5 standards group, there really was no way to do this without plug-ins. But now, with the audio and video elements, not only do you have video in web pages or audio in web pages in a way that is part of the native web technology, but it works very well with other parts of web technology.

So it can be controlled with JavaScript. The elements, especially the video element can be styled with all the standard CSS styles and anything you would do to another element works equally well with video. In fact, you can overlay elements on top of the video which is really great for uses of video where it's not just a rectangle playing a movie.

Another big area that we've done lots of work on is scalable graphics. Safari has had SVG in sometime-- for some time. But now with Safari 4 and iPhone 3, you've got these SVG elements as a basic part of web technology that you can use alongside HTML and CSS.

And web fonts lets you do the same sorts of scalable-- have the same kinds of scalable text that's going to look good at any size rather than having a pre-rendered image that has the text drawn into it which is one of the most used techniques today to get custom fonts on the web.

That isn't really text, something that looks like an image, doesn't work well with screen readers. It's not going to-- it won't scale as well. And web fonts lets you have a font that comes from the server just the way an image or movie would come from the server.

And then there's a really exciting area called CSS Effects which is another area where we've been inventing quite a few things. And this is-- this is something that is especially compatible with a note-- with the concept of progressive enhancement where you have a website that looks good but you can make it look even better when there are a few extra features. And while these features are extremely powerful when you use them as the sort of centerpiece of a design, they're also very easy to use to enhance an existing design.

So what a mask lets you do is take an image and cut out a piece of the image and so you can have a circular piece of an image inside a web page. Then with gradient, you can take a-- you can have a gradient color that changes from one side or a radial gradient like the one that overlaid on this photo here and make it part of your design, again, without having to download an image that contains the whole gradient in it. That was really the typical technique used when a designer needed a gradient on a web page in the past.

There's also a built-in reflection capability. And I think one of the coolest things about this is the way these features work together, because you can customize exactly what the reflection looks like. And that look there is actually a gradient being used so that the reflection kind of fades as you move further down. So the default reflections you see are actually often a combination of both the reflection feature in CSS and the gradient feature. And then one of the most exciting areas with a whole suite of features that work together is animation.

There's animation in CSS, CSS Effects that achieved animated results. And there are really three key pieces to this that work together. There's CSS transforms, which allows you to take an element and rotate it or move it side to side or skew it. And then you combine that with CSS transitions, which is a simple way to do animations based on changes in the web page.

This is really good when you want animation to be part of normal interaction. For example, you can have a hover style that makes an element kind of grow and seem to move forward from the page a bit without writing any code at all. You simply say that-- tell it to use animation and tell it that when hovered it's bigger and the rest is handled automatically by the web engine.

And then CSS animations, which lets you have animations that are controlled with key frames and all the things you would want to do to do animation, but still using JavaScript only to trigger the beginning of the animation and the whole rest of it handled by the web engine. So these techniques are really powerful. Some-- and they're all available in both Safari 4 and iPhone 3. And I'd like to ask Vicki to come up one more time to show you a quick example of CSS animations at work.

Alright.

Thanks, Darin. OK. So let me zoom in a little bit here so you can see this little better. Alright, so what we have here is a set of photos arranged in sort of a light table arrangement here. And when I tap on these buttons, the photos kind of splay themselves across the screen in different sets of piles.

I can sort them by my favorites. I can go back to the main grid. I can even play a slideshow. But what's happening here is I'm just changing CSS properties in JavaScript to reposition these elements. So we're going to see with just a few lines of CSS how much we can improve this light table application.

So I'm going to switch to the code. So here is my CSS file all and I'm going to add are three properties. I'm going to add WebKit Transition Property, which tells me which property I want to animate, in this case, WebKit Transform. I'm going to add a transition duration, in this case, half a second. And I'm going to add a transition timing function. In this case, I'm going to add ease-in-ease-out. So that's all I'm going to add-- I'm going to hit Save.

Oh, that's actually your web server.

That's right.

And I'm going to reload.

Got to switch the screen.

Taking a moment.

Oh, I'm sorry.

And we're just waiting on Wi-Fi. Everybody pause your browsing and twittering so we can get into action here.

You think since it's Wi-Fi--

Okay.

-- you think it has something to do with the audience being in there?

Maybe. I don't know. So now I'm going to go through those same operations and you can see there's animations now between, you know, when the photos moved from one position to another. Instead of just appearing in one spot and reappearing in another, we can actually see, you know, the path that they're taking from start to finish. When we play the slideshow, all the photos animate off the page and then one reappears and we're going to rotate them through the viewing area here. And this is a really great experience, I think so.

That's great.

So with all the animation handled by the web engine, not only do you get, you know, nice, smooth animation without having to write any code and it's not dependent on JavaScript, but it's also a really small amount of code. You know, basically, you just move an element from one place to another and the engine handles all the rest.

Now, there's a lot more to say about new features and I'm just highlighting a few sessions that will go into detail. The CSS Effects Session Adding Innovative Styling and Animation with CSS Effects goes in deep to this topic we were just demoing and talking about and shows you all kinds of things that are possible at CSS Effects, really interesting stuff and flashy too. So it's worth checking out.

If you're interested in building iPhone web applications that are really integrated and do have all sorts of the properties of native applications, you know, without the bar at the top and bottom handling touch events and all those sorts of things, the iPhone Web Applications from Start to Finish Session has all sorts of details for you. And then to get even deeper in the possibilities of the video and audio tag, there's a whole session talking about these capabilities and also the new HTTP streaming feature of QuickTime X.

And that's the session up here. So we talked a bit about what Safari and WebKit are. How you could get involved in the project, and also a few of the new technologies. There's a lot in the latest version, Safari 4 and iPhone 3 for you to take advantage of.

I talked about a lot of sessions but there are still more. There is a session that concentrates just on how to use these technologies on websites but still had them work in older versions of browsers or other browsers that don't have these capabilities. Vicki will be presenting that in this same room Thursday evening. And there's also a session on Friday about accessibility for web applications.

Users who use tools like voice over, who can't necessarily see the screen at all but still use the web are only one category of the people that you can help by making your web applications accessible. And there are some great new techniques for that. For more information you can contact Vicki by email, the Safari Dev Center has pulled all sorts of documentation about all sorts of-- and examples as well for our web technologies in using WebKit.