Welcome to WebKit's Open Source Anniversary. I'm Geoff Garen. I'm an engineer on the WebKit team at Apple. Thank you, Mom. I'm going to cover three topics today. One, the year in review. It's been 15 software updates and one major OS release here at WWDC since we started developing WebKit out in the open. And I think this is a really great opportunity to take a step back and look at some of the things we accomplished over the last year.

Two, getting involved. Whether you're elite C++ hacksaw who pones noobs for a living, or a web developer or a simple end user, we have a very clear set of steps that you can take to get involved in the project and the community very quickly and easily to suit your needs.

Finally, three, where we're going. For many of you, that's what you come to WWDC to learn. And so we'll try to tell you some of the directions that we're trying to take the WebKit Open Source project in, and some of the things we're trying to accomplish. So, let's get started with the Year in Review.

Like I said, a year ago is when we began the WebKit Open Source project. And at that time, this is what the WebKit development team looked like. A group of very talented and dedicated engineers, but all in Cupertino, California. Today, the WebKit team looks like this. So you can see we have more dots.

We've grown both in number and in diversity, and that's had a very important influence on the project, and I'll talk about that more in just a minute. Now, throughout my presentation today, it's important for you to bear in mind what I mean when I talk about the things that we have accomplished. I'm not just talking about the things that Apple developers have done, but rather all of the developers working on the WebKit open source project.

That includes developers here at Apple, but also private volunteers who get involved because there are certain bugs in WebKit that really bug them, or because they want to be a part of a really interesting software development process. And it also includes employees at other companies like Google, Backbase, Corellia Software, Nokia, other companies that are interested also in making WebKit the best web rendering engine that it can be for their own purposes. So I'll try to give specific credit where it's due, but always bear in mind that the things I talk about today are things that we've all done together.

So let's talk in bare numbers about some of the things that we've done over the year as the project has grown. And let's begin with bug reports. 767 people contributed bug reports to our open source bug reporting database over the last year. That's two new bug reporters per day.

They contributed a whopping 4,188 bug reports. And about 66% of those were contributed by non-Apple employees. So you can see there's a lot of activity in this public bug database, both by Apple employees and by public contributors. Okay, so WebKit has bugs. That's good to know. Not great to know, but good to know.

Let's see what we've been doing about that. Over the last year, 78 people contributed code changes to the WebKit open source project. They contributed a whopping 3,826 changes, which is more than 10 per day. And just over 20% of those changes were by non-Apple employees. So really great activity there as well.

Now, more important to me as a developer, but not necessarily as flashy, are regression tests. Because no matter how great our code is today, it's very important that we ensure we don't make the same silly mistake tomorrow that we made yesterday. So at the beginning of the project, we had 700 regression tests that we would run every time we made a code change to search for regressions. Today, we have 7,000. So the SETI at Home project may be a bit of an exaggeration of the power with which we search for regressions, but it's important to bear in mind that in only one year, we've grown by an order of magnitude there.

Let me give you a few examples of some of the higher level projects and features that all these changes have added up to. First, SVG, Scalable Vector Graphics. If you attended WebKit for Web Content Developers, you know a lot about how this works, but I'd like to cover the development side of things. SVG began, the engine itself began, inside the KDE repository as a project there.

Then, WebKit open source developers integrated that engine into the WebKit rendering and layout engine so that it could actually be a part of web pages. And that's what you see on the leopard's seed today. XPath is a search querying language for the Document Object Model, and there was a very similar development process there. Improved right-to-left text.

For us native English speakers, this may not seem like such a big deal because we never notice it. However, you may be surprised to learn that the most glowing review ever written about a piece of Macintosh software was not written by Walt Mossberg. Rather, it was written by a Middle Eastern Mac user group when they first tried a WebKit nightly build and saw the incredible improvements made to right-to-left text. You should have seen this letter. They offered to send us flowers. I promise you they did. They invited us over to their homes for dinner. They asked us if we were single. It was incredible.

So there you have it, right to left text. And that's one of the great benefits of having developers who use that kind of language every day. JavaScript getters and setters. This is a method for data abstraction. If you're building libraries for JavaScript, it really helps with that. And finally, many, many CSS features. And I'm just going to breeze through a few of them right now. They are media queries, HSL colors, resize cursor, background size, background origin, border radius, border image, overflow X and overflow Y.

We've also added some developer features, web developer features, and WebKit and Cocoa developer features through the open source database. The Web Inspector, which you may have seen earlier and hopefully you've tried it out. This enables you to see an element in the web page from the perspective of the engine.

So you can understand the style that we've applied to it, the style that we applied and then unapplied because it was overridden, the metrics of the element on the page, JavaScript properties, custom properties that you've set on the element, everything you need to know about how the engine understands your web page. We've also added a JavaScript API that you can use on the Leopard Seed. JavaScript Core is now a first class framework on Mac OS X so that you can embed JavaScript in your applications and script them using JavaScript just like we do in WebKit.

and finally a JavaScript debugger that we call Dracera. Now the Web Inspector and the JavaScript debugger are a really compelling example of the kind of synergy that can develop in an open source process. We have this guy on our team, Tim Hatcher. He's right there. And he used to be a web developer, so he has a very strong understanding of the kinds of tools you need to get that job done.

At the same time, he has a great talent for user interface design, which is one of the many reasons we hired him, and you can see that here. But we tend to work him like a dog on a little something I like to call leopard. And so he doesn't have as much time to devote to these tools as he would like.

He checked the tools into the open source repository, and now a number of other people are contributing fixes and enhancements to them, and they're really coming along. They haven't yet shipped as an Apple product, but they are available in the open source repository, and they're really useful already. Really great stuff.

Now, I want to give you a high level understanding of why all of the contributions that you make are so important and the influence that they have on Mac OS X. So in the spirit of Conan O'Brien's "If They Made It," I've developed some artist's renderings of what Mac OS X would look like without open source contributors. So here is Safari today, and here is what Safari would look like without open source contributors.

Not too good. Of course we know that not only Safari uses WebKit, many applications throughout the system use WebKit. And so here's Mail today. And here's what Mail would look like without open source contributors. Dashboard. Dashboard without open source contributors. And finally, here is Darren Adler, manager of the Safari and WebKit team. And here is what Darren Adler would look like without open source contributors.

So we don't want that. It's important for you to understand that the contributions you make, while they have a substantial influence on Mac OS X, also have influence beyond Mac OS X. KDE is one example. KDE developers have recently announced the Unity project, which will attempt to reunite all of the work that we've been doing over the past few years on WebKit with KHTML, the engine from which WebKit originally derived.

Nokia is another example. Nokia's phones use WebKit as the engine inside their web browser. And Nokia developers have been working very hard to integrate the WebKit version that they use with the version that we release and call Tip of Tree. So the statistics that I gave you earlier about all the development work going into WebKit didn't even include the incredible efforts by KDE developers and Nokia developers right now.

And you can imagine how much larger those numbers will be if we continue to move forward together and merge our source trees. So that was the year in review. Now, hopefully you're excited about WebKit and let me show you how you can get involved in a way that's tailored to your needs.

The main tool that you need is our developer website, webkit.opendarwin.org. There you'll find instructions for all of the things that I'm going to tell you about and demo for you today, and also all of the URLs that you won't be able to write down while I'm skipping through them. The most important tool is our public source repository, our public Subversion repository, where you can get the code and do what you like with it. This is a change from last year. Last year we were using CVS, and this year, Subversion.

We have a developer mailing list to which you can address your questions to the field of WebKit developers if you're working on a part of the project and you would like their input.

Finally, we have a public bug database, bugzilla.opendarwin.org, where you can contribute those bugs that we like but do not love and track them in the open.

An interesting bit of news here is that we're going to move all of our tools into a new unified domain name, WebKit.org, which should make things simpler and clearer for everybody. The old domain names will continue to forward to WebKit.org, so it's nothing that you need to worry about. It will be a seamless transition. But soon, you'll be able to use WebKit.org instead, which should make your lives easier, and ours too.

We have some new tools this year that I'm really excited about that we didn't have at last year's presentation. And I don't really know how we ever did development without them, frankly. First, Nightly Builds at nightly.webkit.org. There you can download a bundle with a pre-built package of the latest and greatest in WebKit. If you double-click the bundle, it will launch your system Safari using the newest WebKit. So you can test out your website and see what it will look like on the next version of Mac OS X.

Or you can just see what's been happening in our development process and test out some of the new stuff that wasn't available before, like SVG. An important thing to understand about the Nightly Builds is that they're entirely self-contained. You download the bundle, you launch Safari with it, and then when you're done, you quit Safari, throw the bundle away, and your system is totally unaffected.

So it's a very risk-free way to try out the latest and greatest in WebKit. Another thing you can use the nightlies for is tracking down a regression. You can check out a window of time, say a month worth of nightly builds, and figure out where a portion of your website or something that you're working on started to break.

We also have a build bot at build.webkit.org that routinely checks out the code, runs all of our regression tests, and lets us know if something's gone wrong. The build bot is a great way to get started in the project if you haven't done coding in WebKit before, because routinely there will be someone who forgets to run the test before making a code change, and so the bot will be red, and it will say that something has broken. If you go back in time, you can look at exactly what code change caused something to fail, and a very small regression test that has started to fail, and try to work back exactly why that piece of code affected this test and what has gone wrong.

Finally, we have online change tracking at track.webkit.org, which is basically a web interface to our Subversion repository. It allows you to do a lot of powerful browsing of the source and of the history of the source without having to check out your own repository. Now all of these tools I've mentioned here were actually contributed by someone who is not an Apple employee.

And so they're another example of how you can get involved in the project and the community, even if you're not actually hacking on the engine. These are, you know, Perl and Python and all kinds of stuff that I would never touch, but you might, and that would be great.

So I mentioned that it really is easy to download and build the code. And in the spirit of reading Rainbow, don't just take my word for it. Kevin Decker is going to demo it for you. You may remember that last year, Kevin was tasked with proving that it's easy to use WebKit by building a web browser with WebKit in under 60 seconds. So this year, continuing the tradition, Kevin will prove that it's easy to download and build the WebKit source by doing so using only his mouse. Kevin. Thanks, Geoff.

So, I can only use my mouse. So I'm going to open Safari and we're going to go to webkit.open.org, which is here. And the first step to actually getting the code, believe it or not, is clicking on getting the code. So I'll click getting the code. And there's three steps here.

Now these three steps, the first step is to install Subversion. And if you have Leopard right now, you already have Subversion. If you have Tiger and don't have Subversion installed, you need to install Subversion. But this machine has Subversion, so I'm going to skip that step. Next step is to open Terminal, which I'll do here. Cool? And lastly, I'm going to copy this command right here, svncheckout, because I can't type. And I'm going to paste this into terminal.

Okay, cool. I'll hide this Safari window here. So everything is being checked out right now, not just the engine and its sources, but all the scripts and all the tests. I mean, it's kind of like those cable TV premium packages. It's like you're getting everything. And it doesn't just say fast because it's going by fast. These are actually all the layout tests.

Nice. Thank you. So that, by the way, has nothing to do with checking out the sources. So that's okay. So these are checking out, but you know, you guys saw Time Machine, and that was all about going back in time. But as exciting as it is to watch these tests check out, I really don't want to sit up here on stage while I'm being hammered on IRC. So we're going to actually, through the magic of WWC and TV, we're going to fast forward through time. And look at this. We're done checking out. So we've checked out the code.

So now we've checked out the code. It'd be cool if we actually built the code. So we'll go back. And I'll just click on Building WebKit. And there's two ways you can build. You can build with debug and without debug. And let me explain what this means. If you build with debug, debug means you're going to be slower and you're going to crash more.

And you may say to yourself, self, why would I want to crash more and be slower? Well, the answer is crashing in this case is good because these actually compile with assertions. And assertions catch problems that may have no obvious or visible symptom. And so when that happens, that's good because we can prevent major problems.

So in fact, if you ever wonder if you hit one of these assertions, if you look at the crash report and look at the address, it will say 0xBadBeef. You will know you've hit an assertion. In this case, I actually wanted to build a debug version because a little bit later, we're going to be doing some debugging. So I'm going to choose debug. So I'll just paste this in here.

And now we're going to build a debug version of WebKit. This computer is all fast and all, but still, it's not as fast as those cooking shows. But is it? So again, through the magic of TV and WWDC, we're going to fast forward and be done with this. Check that out. Latest Intel processors.

So now we have this built, let's run it. And so I'll go back to Safari. I promise you, I have not used the keyboard. And I'll click on Building WebKit. And there's a script right here. Normally you would keep this in the dock, but in this case I'm going to copy it. Paste this guy.

I'm going to also quit Safari too, just so you can see the difference. Paste. And now this is running. And so we're now running with your Safari and /Applications Safari app with the latest and greatest bits from WebKit. And that's just how -- if I can do this with one hand with my mouse, imagine what you can do with two hands. That's it. Thanks, Geoff.

You're welcome. Slides, please. So let's talk about what you'll find when you download the WebKit source. I'm going to cover the major folders that are of importance to you. There are some that I'm leaving out, not really that important, and you probably won't have to deal with them.

JavaScript Core is the JavaScript Core framework on Leopard. It's where we store the JavaScript engine and a little bit of the WebKit Cocoa WebScript Object API. Now you may be wondering why we have something as high level as a Cocoa API with something as low level as the bits of the JavaScript engine. And I'll let you in on a little secret.

We wonder that too sometimes. One of the projects that you can get involved with if you're a Cocoa developer is moving that code up into WebKit with the rest of the API where it belongs. Layout tests is where you'll find all of our regression tests. It's named layout tests because we created it in the halcyon days of old where the only regressions that we needed to test for were actual layout problems.

Now in the Web 2.0, AJAX, DHTML world, many web pages are entirely generated by JavaScript and so our regression tests are a little more complicated from time to time. WebCore is where you'll find the meat of our engine. There you'll find the document engine, the rendering engine, and the platform layer. Since this is the meat of everything, I'm going to go into more detail here in just a minute.

WebKit is where you'll find the Cocoa WebKit API and a little bit of the loader. Once again, we sometimes wonder what the loader is doing mixed in with the WebKit API. And you can help us move that code down into WebCore with the rest of the engine where it belongs.

WebKit site is our website, which is also open source, webkit.opendarwin.org. And earlier this year, we had an open source contributor revamp the site with a facelift. It looks a lot better now, as you saw. So that's yet another way you can become involved in the community, even if you're not necessarily hacking on the code. WebKit Tools is where you'll find useful scripts in your development process. Build WebKit is the tool that Kevin just used. Run WebKit tests will run all of the regression tests. There are some other interesting ones in there as well.

So I promised I would go into more detail about the WebCore Engine and let's do that now. I'd like to give you a pictorial overview of the different components inside the Engine. DOM is the Document Object Model, which is the heart of the WebCore engine. There you'll find all of the basic operations on a document as defined by the W3C standard. So the idea of what a node is, what an element is, how to iterate through nodes, all of that is inside DOM.

Building on top of DOM and extending it are XML, HTML, and SVG, which are themselves Document Object Models, probably things you're already familiar with. Alongside that we have CSS, Cascading Style Sheets, which defines all the styles in your document and how they apply based on the structure of the document and certain attributes of nodes inside the document.

Underneath everything is the platform layer, which we use for platform abstraction. For example, in the case of an image, the platform layer would handle loading the image over the network or from disk and decoding it and storing it in memory. Because it's platform independent, we don't use something like NSImage because that wouldn't be useful on platforms like KDE and Nokia. The Platform layer also contains elements that you might not traditionally think of as platform abstraction, like representing a point on the screen or a rectangle. There again we use our own data structures rather than NSPoint or NSRect, for example.

So there you have everything we need in the Engine to represent a web page in memory. On top of these components, we build two key software components. One, the rendering engine. The rendering engine will merge the structure of the document with the style that applies to it and lay everything out, determining position, width, height, etc. And finally, paint everything to the screen.

The second component we have sitting on top of the document are the language bindings. Currently we support JavaScript and Objective-C. Web developers will be familiar with the JavaScript bindings, which is the way you script a page on the web. And WebKit developers will be familiar with the Objective-C bindings, which is the way you access the document through Cocoa. There are three key things that I want you to understand about this model.

One, the language bindings and the rendering engine share the same underlying document. This is why, for example, in the case of an input element, if you change the contents of the element using JavaScript, you'll see that change on the screen. Similarly, if the user types into the input element, changing its contents on the screen, you'll see that change in JavaScript. This is not because JavaScript and the rendering engine are talking to each other, as much as it is because they share the same underlying data. And so if one changes that data, the other sees the change.

The second thing you need to understand is that the language bindings are distinct from the underlying document. So if you reference the document in JavaScript, say you use the document variable, we'll create a JavaScript object with a reference to the underlying document. But the two objects are distinct and the JavaScript object will simply forward requests for properties and functions to the underlying document object model.

Finally, you need to understand that the JavaScript binding layer in WebCore is distinct from the JavaScript engine that lives in JavaScript Core. We'll receive bug reports that say things like, "You know, I tried to use attach event from JavaScript. It didn't work in Safari, so there's a bug in your JavaScript engine." And you know what, maybe you should try using SpiderMonkey instead, which will fix all of your compatibility problems and also make really cute puppies rain from the sky.

Now, this is a misunderstanding. First of all, cute puppies don't rain from the sky, they grow on trees. Secondly, whether WebKit supports AttachEvent has as little to do with the JavaScript engine as it has to do with the Objective-C runtime. The key question is whether the Document Object Model provides an interface for AttachEvent. So the JavaScript engine knows how to ask WebCore for AttachEvent when you use it in your web page, but if WebCore doesn't support that interface, the engine throws an exception, as it should.

So let me give you a specific example of an image element on a web page and how it maps to the structure I've described. Inside the Document Object Model, you would have the image element itself. Here we have a picture of a cat. In CSS, I can style that element, and I've given it a 10 pixel border because in preparation for WWDC and making up my slides, I've learned that borders make everything prettier.

In the platform layer, we would handle loading kitty.jpg from disk or over the network, decoding that JPEG image, and storing it away in memory. Inside the rendering engine, we would merge the document with the style that's been applied to it, give the cat a border, and paint it to the screen.

And finally, in the bindings layers is where we would create objects when you reference the document from the programming language of your choice. In JavaScript, the familiar get element by ID, and in Objective-C, the structure is very similar. So here's the overview again. Let me show you where each of these parts of the engine live on disk and in our Xcode projects which map to the disk file structure.

The DOM is stored in the DOM folder inside WebCorp. XML, HTML, and SVG are in XML, HTML, and KSVG2, which is a little divergent. We should probably just call it SVG. But we've kept the name to keep the name that they use inside KDE for source compatibility. CSS is in CSS. Platform in platform. You're probably noticing a pattern here.

Rendering in rendering. And finally, the language bindings are in bindings. Bindings.js for JavaScript and bindings.objc for Objective-C. So we really do try hard to make this mapping of where things are and what they do very clear to you, because that way it's clear to us as well, and we all have to work in this code. So I'm going to invite Kevin to the stage again to show you all these different parts of the engine with a very simple web page. And this time, he gets to use both the keyboard and the mouse. Kevin.

Thank you. Okay. So the reason why we want to show this to you is because if you've never worked on a web browser before, you know, you may think it's this, you know, it works in mysterious ways. Sometimes we do too. But no, really, things happen in a very methodical and logical process. And it helps when you're first starting to get familiar, to learn the code.

It helps to see how things work. And I kind of want to show you that now. So I'm going to show you how to do that. Lots of stuff are in the debugger. Running our built WebKit. So I'll click on Debug here. This is the project. Make this a little easier to see.

Running our built WebKit. So I'll click on Debug here. This is the project. Make this a little easier to see. So here's the WebKit site, but I want to show you this page. This is Geoff-- this is not my cat. This is Geoff's pet cat. And it's cute and all, but this is a very simple web page. It has an image and it has some text. And of course, there's more complicated web pages, but this is going to illustrate the point nicely. I'm going to show you what the source looks like.

You should be able to see that. Cool. And so you have an image tag, there's some rendering that goes on, and then there's JavaScript. And so what I want to do is I want to, since I've never done this before, I want to step through, I want to set breakpoints on key parts of the engine. In this case, it looks like we have an image. So let's look in the code and let's see what images look like. Let me close this guy out of the way.

So I'm just going to type in the word image. You get a whole bunch of stuff. But in particular, when you go back to this page right here, we have an image tag. So I'm probably going to want an HTML image element. So I'm going to set a breakpoint on its constructor, HTML image element. And you know what? Here's actually two constructors. And I don't know which one's going to get called, but that's OK. One of them will. And we'll just see what happens.

And I also want to set, Geoff talked about rendering, so I click on rendering. And here's, instead of seeing a whole list of image, of things that relate to images, here's renderImage.cpp. So this is the renderer for images. So I'll click on render and I'll set a breakpoint on its constructor. And lastly, in binding, jsHTMLImageElement.

And what this is, is when you set a breakpoint on this, on its constructor, when you reference an object, when you reference anything in HTML from JavaScript, that creates this binding. In this case, we have an image element. But the same, it's called js and then the name of the element. But if we were dealing with an embed or an object, you would see the same thing there. So I set a breakpoint on that. And now I want to go back to my page here. I think this is the old Safari.

And now I'll refresh. And now it looks like we caught this in the debugger. So what's really important to look at when you're first learning how to do this stuff is look at the sequence of events. Look at this backtrace right here. You can see the sequence of events on how we get from an image tag in HTML, you know, from just a separate -- from a page to an image, how an image element is created.

And so that's the first step. Now we attach a renderer to that. So as Geoff said, now that you've created that image element, the renderer needs to know about that because ultimately somebody is going to have to paint those bits on screen. And that's going to be the renderer, renderer side. And finally we have JS -- this is the binding. So we hit these -- that's the sequence of events. And I could go back in here. And then there's Geoff's -- okay.

I actually want to have some fun with this. So I'm going to take this cat and I want to go back to this page. And you can see where we said kitty.source equals kitty.jpg. And often when you're working on the engine, it helps just to set variables to something else, change a value and see what happens. It's a very helpful step in not only learning the code, but also debugging problems.

So I have an image element, and I'm setting its source attribute. So I'll look back in HTML image element. Right here. And I'm going to look for a set source, which should be right here. Set source. And I'm going to set a break point on this now. And I'll go back, refresh this guy.

So here is the actual HTML image element constructor. Now it's being attached to a renderer. Here's where we reference it from JavaScript. So far, so good. And now we've just caught the set source. So in the code that we just saw, that's where we say kitty.source equals kitty.jpg.

But let's change this to another kitty. So I'm going to open up the console here. And the first thing I'm going to do is make this bigger so everyone can see what I'm typing. That should be pretty good. So this is a concept. So I'm just going to say, first I'm going to print the existing value, print value.ascii. And now I can see it's kitty.jpg. So I'm going to change this to another cat. So I'm going to say setValue = string UglyKitty.jpg.

Oh, it's ugly. And now, just so you can see, I'll print value now and we'll see what it looks like. So you can indeed see now the value has changed. So we've directly manipulated the contents of memory here. So I'll click continue. And my friends, this is Geoff's cat without open source.

So that's just, you know, this is a simple example. Okay, I gotta get this off screen. This is a... This is a simple example, but it illustrates how valuable it is if you just want to dive right in to set breakpoints on constructors and just look at the sequence events, look at backtraces, see how things tick. And it's quite easy and fun to actually hack on WebKit. So back to you, Geoff.

It's not my cat. OK, so here's the file system we were looking at before. Kevin took the stage. And what he showed you inside the document object model was HTML image element dot CPP. So that's in the HTML folder. The JavaScript wrapper and bindings JS was JS HTML image element dot CPP.

And as he mentioned, we follow this pattern often. So for an embed element, you'd have HTML embed element and JS HTML embed element. The H1 that you saw, the heading element that you saw on the Web page, that's HTML heading element, JS HTML heading element, et cetera. And finally, in the rendering layer, we showed you render image dot CPP.

You'll notice that we didn't touch the Objective C bindings, SVG, XML, the platform layer, but they follow a very similar structure. And you can try that out on your own if you want to download and build WebKit over lunch, set some breakpoints, see how things work. We have a lab later today that I'll show you. And you can come to the lab and ask us questions about things that didn't make sense to you. So that's getting involved. Now let's talk about the about where we're going.

First, we're trying to develop a new look for the WebKit open source project. Historically, WebKit has been tied to Safari, but even if that strong tie was once appropriate, it really isn't anymore. First of all, many different applications use WebKit, not just Safari. Some of the applications I showed you, Dashboard and Mail, but many others as well. iWeb, Aperture uses WebKit, many applications.

Geoffrey Garen, Kevin Decker First, we're trying to develop a new look for the WebKit open source project. Historically, WebKit has been tied to Safari, but even if that strong tie was once appropriate, it really isn't anymore. Geoffrey Garen, Kevin Decker In addition, WebKit is an open source project, and Safari is an Apple application. The tie isn't appropriate there.

In addition, WebKit is an open source project, and Safari is an Apple application. Geoffrey Garen, Kevin Decker We really want to throw off some of the old cruft and give WebKit its own image that conveys that it is this open source project, that it's a system framework, and that it's used in many other projects as well, KDE and Nokia, for example.

Let me tell you about a few of the projects that we're trying to work on with WebKit over the next year. Compatibility and standards. WebKit is a web browsing engine, so it's important that it's able to browse the web. And that means both support for ancient websites that are written in funny ways and modern websites that are written according to standards that try to close the divide between web browser developers and web application developers by giving a clear definition of how the web browser can be expected to behave. Performance. Once again, because WebKit is used all the time by so many different applications, it's really important for it to be snappy. And for similar reasons, we're working on stability. It's important for WebKit not to crash.

Developer Tools. Our belief here is that the more that we work to support developers with WebKit, the more that they will work to make sure that their websites behave well in WebKit. SVG, Scalable Vector Graphics. We've done a lot of work here and you can see and view SVG documents inside WebKit, but there are a lot of parts of the SVG specification that we have not yet implemented. Some interesting transformations and scaling operations that we need to add to fully support SVG.

IDL, this is an interesting one. IDL stands for Interface Declaration Language. And the goal here, as I showed you before, we have the document object model and then a number of language bindings for it. And right now we write all of that by hand. It would be really neat if we could, in one file, describe the interface that the document object makes available and then automatically generate bindings to other languages like JavaScript and Objective-C.

Currently, we do that for most of JavaScript, but not all. And we don't do it at all for Objective-C. And we'd like to work to move everything over to IDL so that we can add things to the document object model much more easily and in a less error-prone fashion. So if you're interested in working on some of these projects and you get involved and you're not exactly sure what's going on, a quick thing that you can do is ask for help on IRC and Kevin's going to show you how to do that.

So the IRC program we use on the Safari team is Colloquy, also written by that guy right over there. Wave. You can use any IRC client. The IRC server is irc.freenode.net. And the channel, guess what? It's the channel WebKit. So I'm going to just connect on, I should be connected to IRC, but I'm going to join the channel here. WebKit. And so here we are. We're on IRC right now. There's 77 people. Oh my God, you're right, we are.

So, you know, it's a little flavorful right now, but really, guys, it's a lot of fun. You never know what you're going to get. Thank God this is NDA. But you know, this guy Tim, uh... This guy Tim is right here. Hey Tim. Wait, this isn't the keynote.

DRM is yours. So I'm going to say, Tim, what is a good bug I can work on with the Web Inspector? And so, good question, let me see. Try searching Mozilla, yeah. So here's the bug I can work on. So IRC is really cool because you can have very interesting conversations at all times, night and day. I mean, people from all over the world work on this. And our internet's a little slow. Well, here it came up.

But if there's something that you want to tackle, whether you want to work on a regression, a reduction, or you want to fix a patch, or you just want to talk and meet the people behind this stuff, they're really smart and they're a lot of fun. I highly encourage you to get on IRC. And like I said, if you have questions, don't spend hours noodling on it. Just ask. And chances are there's someone who can help you out. So I'm afraid to look back what's on IRC here.

So, let me show you who can help you when you get on IRC, depending on what you're working on. For everything, there's always Darren and other maché. That's Darren Adler, whose picture you've seen, and Maché Stachowiak. Those are the managers of the Safari and WebKit team and the WebKit engine team. If you're working on layout and rendering, the people to talk to you are Hyatt. That's Dave Hyatt. You may have heard of him. He's kind of famous.

Death Bacon is Beth Dakin, and Mitts, Mitts Petal, Dan Bernstein I talked about earlier. They can help you with that. For the DOM and JavaScript, there's me. I've always wanted my name in lights. Anders Ka is Anders Carlsen. And finally, AP, I'm going to do my best here. Alexei, proshkur yarkov. Thank you.

SVG, there's MacDome, Eric Seidel, who is an Apple veteran. And also, the two other names there are actually the original developers of the KDE SVG engine, at least two of them. And they hang out in our channel a lot, and so they can obviously help you with some of the internals of that engine. For form controls and editing, we have Adele Peterson and Justin Garcia.

Some of the tools I mentioned earlier, Xenon is Tim Hatcher. He developed the original Web Inspector and the JavaScript debugger. And some of those other tools, the Nightly Builds, for example, that was B-Dash, who is Mark Rowe. Mark Rowe, by the way, also registered the WebKit.org domain, which we did not register.

And so he's been really kind helping us out with that. And for Bugzilla, questions about bugs and how to file bugs and what kind of information we need. Alice Liu, Altha, who's Altha? Sorry, Yustavok, and finally, Dave Kilzer. For more information on this session, you can contact Mark Malone, who is our Internet Technologies Evangelist.

And we also have a lab later today. That's the WebKit and Safari lab. It's in Mac OS X Lab C at 3:30. So just to close up here, three things to take away. One, we've accomplished a lot together. 15 software updates, one major OS release, hundreds of contributors, thousands of bugs and bug fixes. It's been a great year and I hope it's another great year this year.

Two, it's easy to get involved if you want to hack on the engine, if you're a web developer, if you're just an end user and you want to try out the nightly builds, we try to make it as easy as possible. Our website has instructions for everything and many of the things you can do using only your mouse.

Finally, this is the session that doesn't end. If your question doesn't get answered today, if you don't have time to check out the source over lunch and you end up going home and working with it later, we're always on IRC. It's a part of our workflow every day. And so we'd love to see you there.