Actually, before Darin gets going, you know, if you ever catch this guy in the hall, okay, make sure you don't ask him something, a question about something he's really interested in, because he'll just never stop talking, okay? No. All right. Well, welcome. We're going to talk about not just about web standards, but we're also going to talk about how we support web standards inside the Safari technology, if you're using Safari, the application, or if you're using WebKit inside your own app.

So first of all, I was thinking about this talk, and I was trying to figure out who would be interested. Who does it matter to? "Developers, developers, developers, developers, developers, developers, developers, developers!" All of you. It matters to all of you. And so there's a few different types of developers who'd be interested in what we're going to talk about here.

If you're a website developer, you'll be interested. Now, it's kind of funny to say if you're a website developer. I mean, everyone is a website developer these days. Some people just do a little website of their own. Other people might be designing a whole professional website. No matter which category you fall into, I'll have some stuff that's valuable for you. If you do a Macintosh application, there's a chance you're going to want to embed WebKit.

And the things you learn here about standards are going to help you understand why you would want to embed WebKit. Everything I say about standards applies to Apple Help. And also, if you want to know something about the guts, what's inside a web browser, this is also going to be great for you.

So here are some of the things we're going to cover. The WebKit, the support for web standards in WebKit, the approach that the WebKit takes to compatibility with websites, also the WebKit and open source. You've heard about that in a bunch of other sessions. I'm going to repeat some of what you've heard, but tell you a few new things, and also some of our goals for the future in this area. So let's get started. Let's review a little bit. If you've been to the conference for the last three days, I hope you've already heard this stuff. But let's talk about it again to set the stage for the rest of what I'm going to say.

First of all, we're very proud of Safari. It was a big success. We released our public beta this January. More than 5 million copies were downloaded since then, which, you know, I'm not going to say how many we expected. Let's just say this is more. And Safari 1.0 was released this week, and, you know, we couldn't be more pleased with that. But one of the questions we think about is why was it so popular? We think the reasons are mainly these three.

The impressive performance of Safari, the great innovative features, and the quality. So now let's talk about the WebKit. Again, if you've been to presentations over the past couple days, I hope you already know this. What is the WebKit? The WebKit is the engine inside Safari. And so this engine is now available to you for any application on Macintosh.

And so what that means is if you're a website developer, any kind of content developer who's using web standards, Safari support is vitally important to you because it not only affects how the Safari web browser is going to show your content, but also any other Mac OS X application that uses the WebKit.

and it's available now. So again, a reminder of something you should have already heard. You can use the WebKit right now in Cocoa or Carbon applications. On 10.2, you just have to have Safari installed to use the WebKit. On Panther, it's there all the time. And there's some details about the API that you've heard before. I won't repeat them again.

So let's put the WebKit in context. Just one more little bit of review. The WebKit is a framework. It's built on top of many system frameworks. These aren't all of them. This is just kind of a sample to give you some idea. The application kit that it uses for a lot of its work. Foundation, where the new URL APIs are that it uses to read in data.

And then applications built on top of it, Safari's one. New applications that you develop are also fitting there. And then also inside WebKit, there are the two open-source frameworks that WebKit uses to do a lot of the heavy lifting. WebCore, which is the library based on KHTML from the KDE project, and JavaScriptCore. And when we get to a part of this talk that focuses on open-source, we'll discuss this a little bit more. So there's some words that say the same thing that picture just did.

So let's start talking about the web standards themselves. Let me begin by putting up there a list of some of the most important goals that we had in mind when we were designing the WebKit. You know, standards-- we wanted to make sure that web pages looked good when they were displayed by the WebKit.

And we also wanted to make sure that they worked, they did the job they need to. And in addition, supporting standards was kind of a goal in and of itself. But supporting standards is also a means to the end. It's something that allows us to work with those existing web pages.

And you know, one of the things we sometimes talk about is showing web pages the way the designer intended, which is a very tricky thing, because you don't know-- you need to know what was in their head at the time. It's not enough to just look at the content of the page. And so this is what we had in mind when we were working on web pages.

So what we did is we had a list of standards that we had in mind when we were designing the WebKit. And we had a list of standards that we had in mind when we were designing the WebKit. And we had a list of standards that we had in mind when we were designing the WebKit. So what you see here is a list of some of the most important standards that are in the WebKit.

And what I'm going to do now-- and you're going to be seeing this slide for a while, so better read it and then look at me, because it's going to be really boring up there. So I'm going to talk a little bit about each of these standards here. And what they mean inside a web browser. So first of all, there's the HTML standard. And this is really the cornerstone of web technology. Originally, it was a standard for web development.

But now it's a standard for web development. But now it's a standard for web development. Originally, in the old days, there were a couple image formats, the HTML standard, and the HTTP standard for getting web pages. And that was it. That really was already recognizable as the web that we see today.

And so the HTML standard, currently version 4, there's lots of things you can do with just HTML alone. HTML describes the content of the web pages, what comes first, what goes next. It includes things that allow you to put images in the page, links to and from pages, and of course, a form elements like buttons and lists.

And also part of HTML are the tables, which actually is one of the most difficult standards to deal with. Because tables are sort of this de facto standard. Nowhere can you find written down the exact rules of how wide tables should be and given various specifications. And it's one of the trickiest parts of being compatible with existing websites. So we'll come back to that in a minute. Then there's also an important standard called XHTML.

And XHTML is the XML version of the HTML standard. And one of the really -- there are lots of reasons to move into this new XML world. But one of the main reasons is it creates a future possibility of having a single XML document that inside it has an XHTML portion. In another part of it, it might have an SVG portion or any other for vector graphics and any other XML-based languages. And they should be able to all intermingle and interweave. And so that's a reason why XHTML is very important.

HTML was always conceived to be a language to describe what was on the web page, and not how it should look. And so its ways of letting you control exactly where things are positioned on the page are all sort of almost unintentional. People really had to push it to its limit to get an image exactly where they wanted. And mainly what they did was use tables, tables inside tables with another table here and a table around that.

And as I mentioned before, that was one of the least standardized aspects of how browsers work. And a real revolution in this came with the next standard on the list, which is cascading style sheets. Cascading style sheets, as you can see there, which had already had a version one and version two and version three has been being worked on now, is a way to describe how a page should look separate from the content.

So you still use HTML to say what's on the page, but you use cascading style sheets to describe how it should look. We'll talk about that a little more in detail.

And in addition to the DOM level 1 and 2 standards, we support some extensions. DOM level 0 is some of the most important DOM stuff, and it's not in any standard, but we have to support that, and we support some Microsoft extensions to DOM.

So there you have it, a list of our supported standards. But wait, there's more. Besides all these basic standards for the web, there are even more things you need before you can work with the real-life websites that are out there. Very important standards, some of which aren't standards at all.

The Netscape cookie standard, which is not really a standard any standards body defines. The plug-in API. This is the way we get things in WebKit applications like Flash content from Macromedia or Shockwave Director or real player content. And even QuickTime, that's the way it plugs into the programs that use the WebKit.

We support Java applets, and our Java team has done a great job of making Java applets work really well inside WebKit programs. And when it comes to character sets, when it comes to working all around the world, it's amazing how many different character sets there are and how many different names there are for them. And so many of those names are documented in the central repositories and official names, and then so many of them aren't documented anywhere, and you just have to discover them on the websites that use them.

Inside WebKit, it uses Unicode, and this means that you can use different pages with different character sets, and it all works together nicely. JavaScript always gets the same kinds of character codes. And then finally, we have support for the kinds of bidirectional text and contextual letter form stuff that you need to work with languages other than English.

But wait, there's more. So this third page is also a list of some important ones that are supported inside the WebKit. In fact, almost all of these are things that are supported in the Foundation URL API layer. And these are standards that have to do with getting the content inside the WebKit, pulling it out from the web. The basic protocol, HTTP, including some of the more recent additions in the history of HTTP for chunk transfers, which are for pages that come a bit at a time, and persistent connections, which make using a website with lots of images much faster.

The authentication standards that you need to support, the secure HTTP standards, and also support for some proxy standards. So anyway, there's the big laundry list. And so now, with that out of the way, having listed those out of the way, let's talk a little bit more about these, just so you can get some understanding of what they are and how they relate to WebKit.

So let's zoom in for a moment on contextual style-- on cascading style sheets. Ha! I keep saying that. The CSS standard. So as I said before, the important thing about the CSS standard is that for the people designing it was completely separating the appearance of a page from the content of that page.

I'll show you what that means in a minute. But besides that, it meant something more to the web community when it arrived. And that is it allowed you to do real design with each element placed where you wanted it and the page laid out just the way you like without using tables.

And so this really creates the possibility of making a page that looks the same on all the browsers without navigating this tricky world of how tables work in each browser. And the basic structure of cascading style sheets is that you have a predicate-- in this case, this little example I put in the box, the predicate is form, so it says all-- that means it applies to all form elements.

But there are ways to do predicates that apply to certain named elements, certain classes of elements, not just which tag. And then you specify the styles you want to apply. And styles are everything from the mundane, like the color or the font family, to incredibly sophisticated things that are browser features that are expressed as styles.

So that's a little bit about cascading style sheets. Now, another-- another thing that I want to talk about is the fact that there's a lot of stuff that's going on in the web. And I think that's a good thing. And I think that's a good thing. Now, another-- another one of the standards that's worth discussing in a bit more detail is the DOM. Again, one of the main things this lets you do is manipulate the document, manipulate the objects in the web page from inside JavaScript.

And this is how you achieve dynamic effects on web pages. I just gave a little example here. You might have a form with a checkbox in it for the language, and this line of JavaScript code would let you check that checkbox. And so that's-- that's a little example of-- of use of the DOM. Well, thank you.

So let's talk in depth about a couple more of the standards, and then I'll show you some web pages. So the plug-in support that we have is another de facto standard from Netscape. Netscape documents how plug-ins worked in their original versions of the Netscape browser, and that really establishes how plug-ins work today. Existing plug-ins that worked on Macintosh, that worked with browsers that existed before Safari, will work in any WebKit application. There's nothing you have to do to make plug-ins work. And so if you're writing a plug-in, you know it'll work inside any app using WebKit.

And you can actually make a Mac OS version of your plug-in, and that'll load even faster. I wanted to mention that here because I wasn't sure what other talk we'd have a chance to mention it in. And also, this is an area to look to in the future. We're going to make significant enhancement-style plug-ins work in the future.

And then, besides plug-ins, there's one other area worth highlighting, which is Java. Java is... Java applets are a big part of many websites and have great support for Java applets. You need the whole suite of libraries that Java programmers expect to be there. And in Mac OS X, you have the latest released version of Sun's Java Standard Edition. And you get that through software update if you're using Jaguar or it's included in Panther.

And the plug-in that we have for Java that makes Java applets work, it's actually a plug-in that comes with Java that connects with a WebKit, supports all the Sun Java plug-in features, including a debugging console. And it's all--and--excuse me. And if plug-ins manipulate cookies, that works-- that is integrated with the WebKit's own use of cookies.

So let's move over to the, uh, onto this demo machine here. And I'll show you a couple examples just to illustrate what I'm talking about with the types of web pages. So let's start with, uh-- let's start with a simple HTML example. Now, I actually-- believe it or not, I was actually gonna show Google as this simple example. But when I tried to load Google before the demo, it didn't load.

So, I don't know about the rest of you guys, but I kind of count on that page being there. But anyway, Yahoo is another good example. This is simple, old-fashioned HTML. Now, the page has lots of elements on it. It has pictures and stuff. It has bold-faced text.

It has a nice layout. It uses some tables. But this is really basic HTML. And another page here to look at that's a little more complex, but still is just really HTML, is CNN.com. And they do all kinds of things with these nested tables and stuff, but they're not using any. They're doing all of this using techniques that have been around for a long time, not really using some of these more recent standards.

Let's take a look at one page that I think really illustrates what CSS is really about. This site is called the CSS Zen Garden. And basically, all the text that you can't read is describing the purpose of the site. And the people who came up with this site realized that a lot of designers didn't get what you could do with CSS in terms of changing the look of a site without changing the content. So I'll just page down a little bit just so you can see.

Oh, I should have used a Panther machine. This is a Jaguar machine. Well, anyway, it scrolls nicer on Panther. So, basically, what you're going to see now when I click on this link is the same web page. Okay, we're just going to change the style sheet. So, let's go to this one here.

So this is the same HTML. Nothing has changed about the HTML. The only thing that changed is the style sheet, and you'll notice all kinds of things have changed. Everything from the font, these different capitals, the layout. These sections were all vertical in the other style sheet. Now one is to the side, one is above the other. And here's one I really like. Oh yeah, the way things highlight when you move over them is controlled by the CSS. So here's one I really like.

This actually changes the whole website to have a horizontal orientation. It's the exact same HTML. Nothing has changed in the HTML. In fact, all the HTML does is kind of say, you know, this section has this name, this other section has that name. And completely separate from the HTML, the HTML is the same.

HTML, the style sheet determines how the page looks, but not just in trivial ways, in the major ways, how the layout is done. So just trying to illustrate what CSS really means. Now here's an example of a kind of crazy page done with a DOM that gives you some idea of what you can do with the DOM. Oh, wait a second. What version of Safari is this? You know, I think I shouldn't do this. This is beta 2.

Oh, my god. OK, well, anyway. So I can't really show you this page very well. OK, well, forget this one. So here's an example of something someone did with a DOM. And this looks like an animation. It looks like it might be a suite of images. But this is actually just text.

There's layer upon layer of text here. And it's just being moved around on the page. Using the DOM, you can use the elements on the web page, the plain text itself, in your program. So you can write little demo programs. I thought this might illustrate that using the DOM, you program a web page.

Boy, I hope Beta 2 is really good on my other demo pages. Well, let's go back to the slides, and we'll come back to the... Yeah, no thanks. Not during the talk. So anyway, that's a basic overview of standards inside Safari. So now let's talk about website compatibility, designing to work with these standards, and also designing WebKit to work with websites that are out there.

So first of all, what you see is a list of some of the most important things to do if you want to create a website that actually is standards compliant, that's actually going to work. And so one of the first things to do is to actually learn something about the web standards.

It's worth doing a little bit of studying. You know, a lot of people make web pages by taking an existing one and tinkering with it and changing it a bit. But if you want to make a really great website that's going to work with all the browsers, it's worth reading up a little bit about these standards. And like I said, the most important ones to learn about are really HTML itself and CSS and the DOM.

And then another way to understand how well you've done that is to actually test your site with a lot of different browsers. You start to understand what--that you're--when you are and aren't relying on browser-specific behavior by actually trying the page with more than one browser. And we highly recommend testing with Safari.

And also, there are some tools out there that will validate and check for mistakes. There's all sorts of mistakes that you make that can be found by an automated tool, and the W3C has some of those tools. In fact, I'll give URLs for one of those at the end of the talk.

To understand what we're even talking about when we talk about a standards-based website or a standards-compliant website, it's worth looking back a little bit into the history of the web. It wasn't long ago when there was really one important browser. I know it's hard to remember back then, but the browser from Netscape was really the one that defined what advanced websites did. And the quirks that this browser had, the particular way it worked, were more important than any standard, really. People programmed around those. I mentioned the way tables worked as a great example of that.

But then a new one showed up on the scene, Microsoft Internet Explorer, and it quickly became a very important second browser. And so lots of websites discovered that they didn't look the same in this new browser as they looked in the old browser. And they thought it was vitally important to look the same. And so tables had different quirks. And so lots of sites started to check which browser it was and give you totally different content for the two browsers. Sometimes they take you to a whole different web page.

And this led to this body of knowledge on how to do that. And a lot of it was done by checking the string that identifies which browser you're talking to. It's called the user agent string. And so you'd check to see if it was the Microsoft browser using that. Now, uh...

So another thing is, you should be able to build your whole website without ever parsing the user agent string.

Because by definition, if you're looking at the user agent string to figure out what kind of content, then you're not going to work with a new web browser. How can you predict what the user agent string of some future web browser is going to have in it? There was a time when this was the only way to check things, but that time is long past.

And right now, the main thing to do with user agent string is to tell people the name of the web browser. You know, that's about the only thing I can think of to do, or log what web browser someone used, not to figure out what kind of content to give.

And then another thing to avoid, and this may sound obvious, but you have to read the standards enough to know what things are non-standard extensions. So don't just use them because they happen to be there on the one browser you test with first. And in a lot of cases, there are standard alternatives. Those are a few of the things not to do. Just a couple high-level tips on that. And let's talk about some of the things that you should do.

So first of all, when I say don't check at all, don't check the user agent string, don't check document.all, you know, if you are going to use a feature that is not in every browser, but you want to be compatible with others, then you will need to do some testing for capabilities, probably in your JavaScript code. So there are ways to do this that work really nicely, and the best way I can summarize is use object detection.

So what this means is in JavaScript, you can go at any object, and that includes methods. Methods themselves are objects in JavaScript. You can get the object, and if the object isn't there, you'll get undefined. And so you can very easily check before calling something, just see if the object is there. And that's a much better check than to check which browser is there. and then based on that, guess which feature is going to be present.

Another thing, another particular specific tip that people who've done lots of websites tell me is important is to use the getElementByID method to find objects on the web page. There are lots of ways that work in one browser that don't work in another. This is an area where there's lots of extensions. And this method works in all the most important browsers, and it's part of the standard. So this is a specific example where there's a standard way to do something, so don't use an extension, because you can do it the standard way.

Now, I wanted to mention, this is kind of a little bit of a side trip, but it's worth mentioning. Lots of people have asked us about improving JavaScript debugging in Safari, and a big part of making web pages work well with WebKit is actually debugging your pages, trying them out in Safari, seeing what's going on. And so a lot of people had these pages that weren't working quite right, and they've asked us for a little bit more help. And we've provided something new in 1.0, if you've used Beta 2. It's not in Beta 2.

And it's the ability to log JavaScript exceptions to the console. And it sounds like a small thing, but it really makes a big difference when debugging a web page. And all you need to do is turn on the Safari debug menu. And, you know, I hardly need to write this tip up there, because I believe everyone in the big room said they already knew how to do this. But you just type this in the command line to turn on. And then the next time you start up Safari, you'll see the debug menu.

And then there's a menu item, log JavaScript exceptions. You turn that on, and then in the console, you will see information about JavaScript exceptions. And it's a little thing, but it can really help you out when you're trying to figure out why your JavaScript isn't running. Now, I actually, when I'm doing JavaScript stuff, I tend to also put, like, lots of alerts in, because it's easier than, like, looking at a console window.

But this is--you don't even have to change the web page to do this. All right, so I've talked a little bit about what you can do on your websites to be compatible, but I also want to talk about what WebKit does to work with the realities of the web.

So in the real world, we've got web pages that don't do any of the things we said, do everything wrong that I just mentioned, and 100 other things wrong. And we still want them to work with a WebKit. And the reason is that we're putting WebKit into our new applications, and you don't want to make excuses why they can't work with these existing websites.

So, what can you do about this? Well, there's a couple things you do that we did in WebKit that I want to go into detail on, just because they're kind of geeky and fun. And these have a lot to do, these have more than you'd, it's surprising the amount this has to do with making web pages work with the site.

So, the WebKit's user agent string has to look just right to all the websites that are going to do various checks. So, I already said it's vital that it not have the word compatible in it, because everyone knows that means Microsoft Internet Explorer. So, every user agent string has been designed for compatibility in a major web browser. The very second web browser already realized they couldn't change things from the first web browser too much because people were checking user agent string.

So, one of the goals for the WebKit's one was to look like other standards compliant browsers. So, code where someone tried to look for a standards compliant browser in a kind of bad way, it was important that it got the idea it was on one. So, that it gave Safari the kind of content that works well for a standards compliant browser.

And also, it's important to remember that the user agent string has a real purpose, too, which is to identify which web browser it is. So we couldn't fill it with lies. It couldn't say, you know, I am Mac IE version 5.2 or something like that, even if that gave us good web pages, because you have to tell the truth. You have to say that's the WebKit, and you have to say which the application it is. And some people may have a reason to check a version, and so we've got to include those version numbers.

And all the same things I said apply to some important methods in the DOM. There's a navigator object in the DOM which has all sorts of user agent-like strings that tell you who wrote the web browser, you know, all that sort of thing, and it has the same kind of goals as the user agent string.

So let's look at a user agent string. So this is pretty much what the user agent string looks like from an application using Safari. So let me just go through it. I'm going to go through it a little, because I don't know. I just think it's fun. So in the beginning it says Mozilla 5.0. You have to say that.

In fact, I would predict that five years from now, user agent strings of all the major browsers will still start with Mozilla slash 5.0. And really it's just because the first version of Netscape said Mozilla, and there are Mozilla checks in ancient code that I won't do anything interesting unless this browser is Mozilla.

And then inside the parentheses are where all sorts of platform identification stuff goes. You'll notice that the primary language of the user goes in there. You set that in the system preferences on Macintosh. And I did this for my own machine, so it says U.S. English in there.

And some various platform identifiers. You know, it's embarrassing to admit, but I forgot what the U means. There are experts in the crowd who could tell me, I'm sure. But there's some, the salient features start on the part that's wrapped on the second line. The string says the word Apple WebKit. Now, if you find that none of these other techniques work for you, and you really want to do something specific in the case of the WebKit, please look for that string. Don't look for the name Safari, which just happens to be the first WebKit application's name.

But look for Apple WebKit. And in fact, even look for the slash after it, because, you know, to be sure, you're not seeing the string somewhere else. So the version of the WebKit appears right there. And if you had some need to check the version, you could read it out of there. But, you know, please don't, because it's hard to parse these strings. JavaScript doesn't really have, like, regular expressions to help you. Well, it does have regular expressions, but it doesn't really have an easy way to parse these apart correctly. But the version is in there.

That's, like I said, telling the truth. So then the next parentheses part is just a perfect example of what you've got to do to make the pages work. The word gecko is in there. You see it says, like gecko? And gecko is the engine inside Mozilla. And you might ask yourself, why the hell are they mentioning gecko in the user agent string for WebKit? And the answer is that for a huge amount of the web, there's code that says, if the string gecko is there, use the new standards-compliant way of doing things. And if the string gecko isn't there, do things in a way that only works with Microsoft Internet Explorer. And so, this is vital to making web pages work, that the word gecko be there somewhere. But we didn't want to lie, so we say we're like gecko.

So just before, like GECKO, you see the words "KHTML" there. And this is so that if there are quirks of our engine, which shares its innermost code with the KHTML library-- it is the KHTML library-- we wanted to make sure there was one thing in our user agent string that was also in the user agent string from the KDE project with their browser using the KHTML library. So that's why the word "KHTML" is in there.

And then finally, your application name will go in there. And you get to set that when you use the WebKit. If you do the codeless browser, there won't be anything there. But if you go and start to use delegates to customize the behavior of the WebView, you'll be able to put your own application name and version in there.

So I'm not going to go through this in quite as much detail, but here are the navigator properties I talked about. And similarly, these are driven in the same way by these compatibility issues-- what existing web pages check and what they expect. The only one here I'll mention specifically is I like product sub. That's one of my favorites. Because you'll notice it's this mysterious eight-digit number.

And it's actually the ages of all the Safari engineers multiplied together-- OK, not really. What it is is that's the date of the-- on the Gecko project, they use that for the date of the Gecko build. So there's a lot of websites out there that say, OK, if I got Gecko, then I'll do-- I'll do it the standards-compliant way.

And if I've got a new enough Gecko greater than a certain build date, then I'll use this suite of features that they didn't get into that date. And it's not like people are doing this a lot now, but they did it like a year or two back. And so it has to be greater than some date. So this had to be a year, month, and date that was newer than some old Gecko build.

So we picked completely at random January 7, 2003 is our date. So I can't remember. There was something happened that day that made us-- I don't know. So anyway, let me show you a couple more examples. Let's go back to the demo machine. And we can see how Safari Beta 2 used to render these pages.

So, I'm so proud of how 1.0 renders, they were pretty good in beta 2. So this is wired.com. And this is an example of a real-world web page that was done entirely with standards. There is none of this old-fashioned way of doing stuff, very little, you know, checking user agent kind of glop. And it's a beautiful page, does lots of stuff, very attractive layout, all kinds of neat features like changing the size of the text from a link in the page.

And the reason I'm showing this, the reason I'm showing these pages is just to give you an idea that you can make a really great web page just sticking to the standards. You don't have to use special extensions to make a great web page. So let me show you one other page. page that was done with that kind of philosophy.

This is ESPN.com, and although it is designed for a certain window width, so it looks better. I should have left the window that wide. This site has a lot of really cool stuff. I like this section here where you can change around between different pages, and all this is done just with the standards. There's no sneaky, weird stuff here.

A lot of designers think you can do things that look really good only by designing to one browser, and it's just not true. So let's go back to the slides here. In fact, here's something that the designer of that website said about Safari. A lot of people were asking him, What did you do to make it work well with Safari? Other web designers. You know, obviously you spent a lot of time working to make it work well. And he said, "We did nothing to make it work with Safari." In fact, we didn't even-- we just tested it on Safari.

Most of it worked, then we tested it with the next beta, and it all worked. And, you know, this is what he said about, "If you're doing a standards-based web page, you don't have to know anything specific about Safari because Safari just works." So I was really happy to see he said that, so that's why I put it up there.

So that's most of what I have to say about standards and compatibility. Let's talk a little bit about a big part of how we achieved this, and that is how we use, inside the WebKit, open source and what that means to you. So let's look again at this picture of the WebKit. Inside the WebKit are two open source frameworks, the WebCore framework and the JavaScript Core framework. So let's dig in into each of these.

The WebCore framework does most of the HTML and HTML-related standards like CSS and DOM heavy lifting for the WebKit. It includes two big libraries, well, not big in terms of lines of code, but the two major subsections of WebCore. One is the KHTML library, which comes from the KDE project. That same library is used inside KDE's web browser and file manager, Conqueror.

And what we've done to the KHTML library is keep it basically the same structure and the same concept. In fact, our code can be used as is back in the KDE land. You can just move the code right back there. But we needed to connect it to Mac OS X.

KDE uses an underlying library called QT, which is a library that does all the sorts of toolbox things in its own way. It doesn't do them the exact same way that OS X does. We wanted something that was really using all of the OS X native technologies for everything from text drawing, drawing the buttons, event handling, you know, top to bottom, all sorts of things.

And so that's why we built the Quack library. It's spelled K-W-Q, pronounced quack. And the Quack library connects KHTML to the OS X underpinnings. And the way I think of Quack is if it quacks like a duck, then it is a duck, is kind of the concept of the library.

So, WebCore with KHTML and Quack, there's one important piece that comes from outside of WebCore, which is the JavaScript language, the JavaScript interpreter. And that's inside the JavaScript Core framework. Now, JavaScript Core didn't really need a big adapter layer like Quack, but we did need to do a couple things to take the KJS library, again from the KDE project, and combine it with some code that we wrote ourselves to connect it well with certain OS X technologies, excuse me, and some other libraries that work really well with it.

For example, we really were able to improve its regular expression support by using the Perl-compatible regular expression library. It does a great job and handles Unicode perfectly. And there's some other support libraries in there, too, even smaller than those. They're all part of JavaScript core. So, WebCore is the only part of the system using JavaScript Core. Actually, WebKit uses JavaScript Core through WebCore.

So why do we choose KHTML and KJS? So again, I hope you heard about this the last couple days, but I'd like to repeat this again. We looked at a lot of different alternatives, but in the end, the big reasons were that this was a code base that was easy to modify, was fast, and it was easy to make it faster-- and we've shown that time and time again-- and was small. And small in terms of lines of code, number of different concepts, small in every dimension you could think of.

I didn't even mention how well it worked. I'm really missing a bullet point on that slide, because it already did so many of those standards we talked about. We really worked on it to round it out. So we collaborate with the folks at KDE who are still working on KHTML and KJS. And the way it works is we keep enhancing KHTML and KJS in the context of JavaScript Core and Web Core. They keep enhancing it, and we exchange changes. They send changes they've made. We send them changes we've made.

So I wanted to, since we're going a little bit in-depth about this relationship, I just wanted to talk about a few of the contributions we've made to KHTML and KJS. So, you know, it's not complete detail, but I thought it would be neat to call them out. So what you see here is a list of them.

So in terms of site compatibility, we've made hundreds and hundreds of changes to correct a small bug or an omission or a way of handling things so that it's more compatible with the standards and more compatible with the websites. And the way this is really driven for us is that we find websites that don't work, we track them down, we figure out what it is, and then we make the change in a way that works both for us and for the original KHTML and KDE.

We've also made performance enhancements, and we're particularly proud of these. We sped up KJS. We did these JavaScript benchmarks, and we sped it up at least 10 times and even more on certain subparts of the benchmark. That was fun, just some little changes in data structures, keeping the basic concept the same.

We changed, we had some experience, a couple members of our team came from the Mozilla project, so they had some understanding of the way that Mozilla handled certain things, like white space. And we realized that Mozilla's handling of white space really was needed to correctly handle the DOM standard. And so we changed the white space handling and the line breaking to be in line with the standard.

And then, I'm not gonna, well, there are only three more listed here, and there's probably like 30 more I could list. But I just wanted to give you some idea of, there's a wide variety of changes we're making inside HTML and KJS. So we're not only, we're not just taking it and putting it on our platform, we're giving a lot back, too.

So I want to be clear on this point. We've talked about it over and over again, but I'd like to-- I think we can't emphasize it enough time. These are open source libraries. So we can't tell you what to do with them. The license tells you what you can do with them. You can download them. You can do whatever you want. You can port them to some other platform, whatever it is that turns you on.

What should you do with them? Use them via the WebKit. Use the WebKit. Take advantage of them through the great WebKit API. If you link to them directly, you and we both are in for a world of hurt, because we change their interfaces all the time. They're not the kind of polished public APIs that we put in and commit to in the system.

WebKit's APIs are in that category. And also, if you just use WebCore directly, you're not going to--a lot of the benefits come from the way WebKit is connected to the WebCore, to really connect it up perfectly to OS X. Some of the performance tuning is only there if you use it all together.

All right, so we've talked about the standards and how we achieve compatibility. Let's talk a little bit about the future. First of all, we do use our own stuff. Okay, this stuff is brand new. The WebKit SDK is brand new. But even though it just got to the point where we really could have people using it, we already have a lot of applications using the WebKit and the Foundation URL APIs. And so I'm not going to list them again. You've probably even seen this list before. But we use it ourselves.

We're completely serious about the WebKit. Okay? We're not -- This is not something that we're just doing this year, and then next year we're going to do something else. There's going to be more from Safari, more features from Safari, improved standard support of each of the standards we support, improved compatibility with websites, all kinds of things from future Safaris. There's going to be more in the WebKit. A lot of those things I said that we -- that will affect every WebKit application. And as I talked about before, an area we plan to improve is plug-ins.

There's also, we also plan to enhance the networking APIs in all the ways I talked about, improving standard support, adding features. We're in this for the long haul. And we're also a member of the most important standards body, the W3C, and we're participating in committees that define future standards. So standards for us doesn't just mean implementing what websites are already using or what other people have already decided, but it means getting in their hammer and tongs and helping figure out what the future of web technologies are going to be.

So, the one request I have from you is we'd like you to be serious, too. We'd like you to take the WebKit seriously as a website designer, and we'd like you to adopt the WebKit. I think when you take a look at all the stuff we have to do inside the WebKit to make it work well with the web, there really is no reason to try to roll your own. There's just so much in there for you. So, I'm just going to, before I switch to some of the books and resources that I want to tell you about, I'd like to summarize some of those advantages that the WebKit offers.

One is it's easy to embed in an application, so if you're a programmer with an app, no problem. It's fast. You're going to get the same kind of speed that we get when we use it in Safari if you use the WebKit. The WebKit supports a panoply of standards.

And it also supports the real-world websites that skirt the edge or ignore the standards completely. Safari's continued development is going to be one of the many drivers that will keep driving improvements to the WebKit. And the WebKit is built right into the OS. It doesn't make your app any bigger and will have almost no effect on startup time of your app.

So I'm not sure that these slides are in the right order. Before John does the wrap-up, I want to talk a little bit about some of the resources. So let's come back to this roadmap and who to contact. I want to talk about some places you can look for more information. Here are a few of the places in our documentation website that you can find relevant stuff to the-- relevant documentation for the things I've been talking about.

In addition, there are some really valuable Apple websites. The Apple Internet Developer website has tons of information about developing content, web content, in ways that work well with our web technology, including one page I call out there, the Safari Resources for Web Developers page that has all kinds of stuff. It includes pointers to documentation about exactly what's supported by various versions of Safari 1.0, tips for using CSS and the DOM, and all that sort of thing. And then the SDK website.

I wanted to mention a few of these books. In particular, the CSS book, which is the second one down there, and the DOM book, which is dynamic HTML, a good way to describe both the DOM and other features. Those are incredibly useful, some of the best references on these subjects. And that's how you're going to know what the standards are.

In addition, there are some great websites about standards in specific and why standards are a good idea. Some of these I hadn't seen until I was preparing my talk, and they're really great. They make the compelling case. And the validator.w3.org up there is the URL for a suite of different validation tools that the W3C offers. And then these are kind of fun.

There are a couple standard experts who have some of the best resources out there for CSS and the DOM. And Eric, well, it says right there, the one that's great for CSS tips and another amazing for stuff about the DOM. And they talk specifically about Safari, too, so that'll help you as well.

So anyway, now--OK, sure, sure. So let's go back to the roadmap. And then--OK, so because this is gonna be on the DVD, there's a previous sessions. The first two are previous sessions you might want to look at, the open-source session and the Safari overview. But after this session, there's three more that I think you may find really interesting.

The Advanced Foundation URL API session is going to go into detail about the URL loading APIs and what they are, how to use them. The Advanced WebKit API session will tell you all sorts of interesting things about the WebKit. I actually think there are parts of that that are interesting even if you aren't gonna program with the WebKit. So it's--definitely go to that one.

And then there's a feedback forum for all the internet networking technologies, which is on Friday--not day, 10:30 a.m., but Friday, 10:30 a.m. So if you have feedback about WebKit and standard supports, please send it to John. His email address is there. And thank you very much. I think it's time for Q&A.