Welcome to session 112, Safari and WebKit for Web Content Developers. That means you widget developers too. I'm Adele Peterson. I'm an engineer on the Safari and WebKit team. A little bit later, we'll be hearing from my colleague, Beth Dakin. Today we're going to talk about how you can take advantage of new features in Safari and WebKit and new technologies that we've gone to support.

There are three main topics that we're going to cover today. The first is JavaScript capabilities, including built-in language features and XML technologies. The second is graphics, specifically scalable vector graphics and canvas. And lastly, style, specifically resolution independence and CSS3. But first, before we get into all of that, we're going to have a little bit of a review.

I'd like to talk to you guys about best practices for web compatibility. So I was talking to a friend recently who's a web developer and she was telling me about how she spends hours and hours getting her websites to be pixel perfect, to get the behavior just right.

And then she goes to test her site in other browsers and discovers she has many more hours of work ahead of her to get it to work in as many browsers as possible. So this is a pretty common problem for web developers. So we want to give you a few tips on how to get a leg up and increase your chances of working in more web browsers.

So the first thing that I want to recommend to you is that you all do a little bit of research. Google is your friend, and there's lots of sites out there that can help you find information about how different browsers behave. Specifically, there's a great resource out there called Quirks Mode at quirksmode.org that has these great compatibility tables to show you different behavior in different browsers.

And that will give you some information about how the browsers actually do work. But if you want to find out how they should work, you may want to take a look at the World Wide Web Consortium website at w3.org. And there you'll find specifications for HTML, CSS, SVG, and other technologies.

So the second thing that I'd like to recommend is that you all use standards mode. And to do that, use a document type declaration that will trigger standards mode. Now for those of you who don't know, In standards mode, most browsers will interpret your code in the same standards-compliant way. So this will greatly increase your chances of working cross-browser.

So unless you're out there writing 1990s-style old school HTML, you probably want to avoid those browser quirks that existed for that old code. So use a doc type like the one I'm going to show you here to trigger standards mode, and you'll increase your chances of working in more modern browsers.

Lastly, I recommend that you validate your code. There are some great tools out there. Specifically, there's a few validators at the W3C website that will help you find common problems in your code. Things like misnested tags, or a misenclosed tag, or the incorrect casing. Things that your eyes might glaze over as you review your website for the gazillionth time.

These are just automated tools to help you find these problems quickly. So those are three simple things that you can do to give yourself a leg up in the whole web compatibility game. Research, use standards mode, and validate your code. OK, so now that we got the basics out of the way, let's talk about JavaScript capabilities.

So the things that I'm going to tell you about today can be basically broken up into two different sections. First, built-in language features. These are the types of things that you can use as you're building a JavaScript library or a framework. And also, client-side XML processing. These are things that fit right into the whole Ajax story as far as making dynamic content from JavaScript using XML technologies.

So the first thing that I want to tell you about is called getters and setters. This is a really cool way that you can add active properties to objects. So what does that mean? Well, it means that you can make your properties behind the scenes act like functions.

So let me show you an example of how that works. So in this example, we have a circle object. It has a radius property and two functions set on it, getDiameter and setDiameter that do some basic math. Now, getDiameter and setDiameter, it might be nice if the diameter was just a property.

From the caller's perspective, the caller doesn't really care what goes on in getDiameter and setDiameter. It just wants to get and set. So in this example, you can see how diameter can be used as a property. And you still might want to do that same math behind the scenes.

So here's how that works. Here I've defined a circle object with a radius property and two functions, a get function and a set function, where the name of that function is the name of the property that I'm going to use. Now you'll see here that the content of those functions is fairly simple in this example. This actually gives you a lot of power.

You could add validation code there so that no one could set a negative diameter. Or you could add type checking or even make this a read-only property by leaving out the set function altogether. So this gives you a lot of control from behind the scenes, and it can still appear as if diameter is just a property.

So you can add these active properties to any object. And from the JavaScript library perspective, you're giving your caller-- you're letting your caller sort of ignore all the dirty work that's done behind the scenes. And you can organize that in a pretty cool and powerful way. OK, moving on.

So the next thing I want to tell you about is called DOM prototypes. This is a way for you to make DOM object prototypes available for modification. So why would you want to do something like this? Well, I'm going to show you an example, and let's set up a little situation here.

OK, so let's say you start a new job for a company that involves dealing with a lot of legacy code. And the programmer before you designed this whole web application only for IE. So there's IE-specific extensions sprinkled all throughout the code. Now, you could go through and you could find every instance of these IE-specific extensions and replace them with standard calls that will work in browsers like Safari and Firefox. But using DOM prototypes, you can actually add that IE-specific functionality onto your objects so that they can be accessible.

So here's how you do it. You'll see at the top here we have node.prototype.attachEvent. I'm just finding this function on the node prototype so that this will be available for all nodes in your document. There's some very simple code here that does a little string magic on the arguments and then passes them right on to addEventListener.

So you could add this onto your prototype, and then any caller that calls attachEvent will work in browsers like Safari and Firefox just by calling the addEventListener function through this prototype addition. So again, this gives you a lot of power. And like Keanu, you can bend objects to your will.

OK, so the next technology I want to tell you about is called XSLT Processor. Now, this is a JavaScript object that lets you use XSLT transformations from script. So many of you may be familiar with XSLT as a way to apply transforms to XML data as you're setting up your data on your server. But this is a way you can do that on the fly. And this technology is already in use for things like Google Maps and Zillow.com to do the map markers on the fly.

So here's an example of how that works. So let's say you have your data and your style sheet both on the server. And you use something from script like XML HTTP request to get that data into documents that you can access from JavaScript. So in script, you go and create an XSLT processor object. And that object allows you to specify a style sheet and then apply that style sheet to a document and have that transformed document or document fragment write available from script.

So you could apply your XSLT transformation in script and then append your document fragment to a different part of your page. So this allows you to really mix it up a little bit as far as XSLT goes and do things on the fly. And this fits right into the whole Ajax Web 2.0 story. It just gives you another technology that you can use.

So lastly, I want to tell you about our support for XPath. This is a way you can use XPath queries right from JavaScript. Some of you who have used XSLT may be familiar with using XPath as a way to navigate your XSLT and your XML documents. Well, now you can use that directly to navigate your HTML documents and any other XML documents in Safari.

So let me show you an example of how that could be beneficial as opposed to just using standard DOM calls. So in this example, we have a document, and we have a few different divs in our document. Specifically, we want to find all the divs that have foo class. Now, you could find these by walking your DOM tree, inspecting each element, seeing if it's a div, seeing if it has that class, and a few different functions. But using an XPath query, you can do this in sort of a short and concise way.

Basically, you define a query, you evaluate that query, and you manipulate the result. So on the first line here, you'll see the XPath query. And even if you're not familiar with XPath, it's very simple syntax. We're looking for all divs of the class foo class. On the second line, you'll see we evaluate that query and store the result, which is something called an XPath result.

And once we have that XPath result, there are lots of things we can do with it. But in this example, we're using a call called iterate next on that XPath result. And basically, with just a few lines of code, we can iterate through all these divs of foo class in the document and perform whatever we want on those divs. Here, I'm just displaying the inner text. But you can do anything you want.

So just three simple steps-- creating a query, evaluating it, and manipulating that result. So those are just a few technologies that you can add to your tool belt and use as you're creating JavaScript libraries and Ajax applications. Check them out and see if they'll work for you. OK, so next I want to talk a little bit about graphics, specifically scalar vector graphics and canvas.

SVG, scalable vector graphics. What is it? Well, it's an XML language for defining graphics. So you define all your circles and lines and paths and fills all within XML. Because it's XML, you have a document object model. Because you have a DOM, JavaScript can manipulate that DOM and create animations and modifications on the fly. And right there in the name, scalable vector graphics are scalable. Yay! And this will be important in the future as more and more browsers have support for SVG, and we're looking for a scalable solution.

So SVG is what I like to call an emerging technology. So what does that mean? Well, SVG has actually been around for a really long time, but we're just starting to see it come into its own, I think. Safari has recently added this native SVG support, and you're starting to see more and more complete native support in other browsers.

But previously, you could only view SVG content using a plugin like the Adobe SVG plugin, and that limited the scope of what you could really do with SVG. So you're starting to see, as browsers add this native support, more and more powerful applications of SVG. So how do you create SVG content? Well, there's a few really easy ways and a few more difficult ways.

Graphics programs like Adobe Illustrator and the open source Inkscape allow you to just export right to SVG. So anything that you can create in these graphics applications, you export right to SVG. Now, for those of you who love to write XML, you can hand roll your content using the SVG language. The W3C has that specification right on their website, and there's some great demos out there and tutorials to help you get started.

So like I said before, I think what you're going to start to see in the future is more and more complete native support in browsers. And as that happens, you're going to see it sort of spread like wildfire, I think. So let me show you a demo of how this can be really powerful. Demo? All righty. So SVG is available in the Leopard preview that you all have, and it's also available in the WebKit nightlies, which we'll talk a little bit more about later. So how many of you have played with the World Clock Widget? Anyone? Anyone? It's pretty hot.

So I made a little demo in SVG that resembles the World Clock widget, and I think it's pretty cool. So some of you may not know this, but the rotating hands in the World Clock widget were made using Canvas. So I'm going to show you how to do that in SVG and how easy it can be. All right, so here's my clock. Ooh.

OK, so let's check it out a little bit and watch it scale, watch how it doesn't lose any of its detail and keeps ticking. OK. So you're actually going to be surprised at how little code this took to work. It took me one morning when I was just messing around to get this up and running. And I think you guys will find this pretty exciting. Let's take a look at it.

Okay, so here we go here. I want to have you guys take note that in the body's onload handler, I call start clock. We'll look at that in a minute to see what that does. Here comes the SVG goodness. Here I've defined a linear gradient that I'm going to use later to make the sexy black background.

Here I draw the clock using a circle. There's my gradient. I draw the numbers on the clock using some magic numbers. And here I draw the hands with a few polygons and some circles for the center of the clock. What I want you to take note of here is that I gave each of these polygons an ID, hours hand, minutes hand, and seconds hand, so I can get to those elements later.

Now, when I first drew these, I had them drawing pointed straight up so that I could rotate them however I want them. And if I weren't ever going to start the clock, they would all just be drawn straight up. Okay, so let's take a look at the JavaScript here.

Start clock updates the clock and then calls set interval so that update clock gets called every second. There are other ways you could do this, but this was the easiest. Update clock gets the current date and time and calls a function called rotate hands with the current hours, minutes, and seconds. Oops. Okay, rotate hands is actually a fairly short function. Here, I store the minutes hand, hours hand, and seconds hand.

I can also use the seconds hand by calling get element by ID and storing those in a variable and variables. And then I do just a little bit of math to calculate the correct angle. I construct a string using this rotate function and the angle I've calculated centered around the center point of the clock.

And then, with these three lines of code, I rotate to the correct position. I set the attribute transform with my rotate function, and that's it. That's all I need to do. It does that every second, and that's how I have a working clock. So in about 20 lines of code here, I have a pretty kick-ass looking clock. Let's take a look. Let's go back to the slides. Slides, please.

So I highly recommend you check that out and see what it can do for you. OK. So next, let's talk about Canvas and the changes we've made to Canvas. So for those of you who aren't familiar with it, canvas is a way you can dynamically render scriptable bitmaps. Define a canvas element, and then you can draw into that bitmap any time you like.

So the canvas element has an interesting history. This is an element we introduced in Safari 2.0, and it was used in tons of widgets out there. And because it became so popular, it was adopted by other browser engines. And because other browser engines adopted it, and it was so popular, we worked with the What Working group to define a specification.

So through all of this, we decided that there were a few improvements that we could make to Canvas. And I want to make sure that you guys know about those improvements so that not only can you take full advantage of them, but you can make sure to update your widgets and your websites to work well within these improvements.

OK, the first improvement that I'm going to tell you about is that Canvas now supports fallback content. And for you, this means that a close tag is now required. So in this example, between your begin tag and your end tag, there's some alternate content that browsers that don't support the canvas element, like IE, will display. So this gives you an opportunity to provide that alternate content.

And if you don't provide an end tag, we won't know where that fallback content ends. So include your close tag. All right, next, the size of the bitmap for the canvas element does not have to be the same size of the element. This is a change. So what this means for you is that width and height attributes need to be defined.

So in this example, I've defined a width and height of 150 and 150, and that defines the size of the bitmap. But you can define an entirely different size in CSS for what you want the element to draw in. So for this 150 by 150 bitmap, you could define an entirely different size in CSS for what you want the element to draw in. So for this 150 by 150 bitmap, you could define an entirely different size in CSS for what you want the element to draw in.

OK, next, drawing into the canvas bitmap is no longer tied to rendering. This was a common request we heard that people wanted to be able to draw into the bitmap before layout had even occurred. So what this means is that if you're expecting the bitmap to be clear, you're going to have to clear it yourself. There were some instances before where a rendering change would cause the bitmap to clear, and that doesn't happen anymore. So go ahead and use this clear act function to clear the bitmap yourself.

OK, lastly, functions like fill, stroke, and clip no longer clear the path when they're done. So this means that you need to add a begin path call before describing a new path. Makes sense, right? So just before you go to draw that new path, add begin path. So those are the improvements that we have added to Canvas. And I highly recommend that you check out your current widgets and websites and make sure that they work with these improvements.

So just to wrap up the graphics section, we talked a little bit about scalable vector graphics, which is an XML language that provides that-- for which the graphics that you draw exist in that XML document, so you can modify it later. And for canvas, it's the scriptable bitmap where you draw into it, and then that data only exists as those pixels. So please take a look at the improvements to canvas and the power of SVG and see how that fits into your current web development. So I'd like to invite my colleague Beth Dakin up here to tell you a little bit about style.

Thanks, Adele. Hi, everybody. Let's talk about style. So there are two main things that I want to talk to you all about today. First, creating high definition web content. We think this is going to be a really important thing in the coming years as resolution independence really takes off. And secondly, I want to talk to you about CSS3.

Specifically, I want to tell you about some cool new properties that we've implemented in our browser that we want you all to take advantage of. Some of them will be really helpful in creating high definition web content, and all of them are really helpful for making your sites look awesome.

So first, let's talk about creating high definition web content. So if you all were at Bertrand's keynote yesterday, you heard Peter Graffagnino talking about resolution independence and how that's something we really want for Mac OS X. So that's sort of what's inspiring this whole high definition web content thing. Because as we're making our operating system take advantage of these extra pixels and the details that you can gain from them, we want you all to be able to do the same with your websites, because this is a really great opportunity to have your sites and widgets look even more incredible on certain displays.

So before we talk about creating high definition web content, let's do a little bit of a review so that we're all on the same page with resolution independence. Let's talk about what it is, how it will affect your existing web content, and finally, why you should care at all.

So first things first, what is resolution independence anyway? Okay, so I had this 15-inch PowerBook that I was using for a while for a couple years. It was a great machine. I totally loved it. It was awesome. But then a couple months ago, I upgraded to a MacBook Pro.

So there are a lot of obvious differences between these two machines. You know, my MacBook Pro is way faster. It's Intel inside. It was really exciting. But the very first thing that I noticed as a difference when I turned on my new machine is that everything was a little bit smaller.

And sure enough, another difference between these two machines is that even though they both have 15-inch screens, my MacBook Pro has a slightly better resolution. Now, I'm sure you've all experienced this to a certain extent. Maybe you've even used one of those really tricked-out monitors on a PC with an incredibly high resolution. You have these small little texts that's hard to see, but you have all this space.

But even if you haven't experienced that, I'm sure that you can imagine that if we keep going down this road of creating higher and higher resolution hardware without doing anything to ourselves, we're going to end up with a software. Soon everything is just going to be itty-bitty little dots on the screen, and you'll barely be able to see it at all. So the idea behind resolution independence is that there's more than one thing that you can gain from these extra pixels. You can gain real estate, which you're already getting, but you can also gain detail.

Everything should be able to be whatever size you want it to be, and you should be able to choose to get extra detail from these pixels if that's what you want. So let's talk a little bit about some of the jargon you're going to hear me and other people saying about this.

First, DPI stands for dots per inch. A lot of you probably know this already anyway. This is the idea that there's hardware that's being created with more and more dots per inch. More dots, basically. So, *audience laughs* Mac OS X has had this historical assumption that you're operating at 72 DPI, regardless of the actual DPI of your device.

So another thing you'll hear me saying a lot is a scale factor or a device pixel ratio. So this is, again, the idea with resolution independence, you can apply a scale factor to your UI. And this is based on this historical 72 DPI assumption, so that 72 DPI corresponds to a 1.0 scale factor.

All right. So what does this mean in terms of where the scale factor comes from? A little bit of math for you. You have 72 DPI. It corresponds to a 1.0 scale factor. So let's say you have a 1600 by 1200 display. Let's say it's 15 inches, whatever.

You know, it's this really high-resolution screen, but everything's too small. You're not really happy. You wish that it looked like it did on your old-school 1024 by 768 display. You wish everything were the same size. So in order to achieve that, you would have to apply a very memorable scale factor, 1600 divided by 1024 equals 1.5625, to the user interface of your new high-resolution device so that everything would be the same size as it was on your old device. But of course, you would have to apply a very memorable scale factor. you would be gaining detail from all of these extra pixels.

All right, how will this affect your existing web content? The first thing that I need to stress here is that a PX, the pixels that you specify in your style sheets, do not correspond to actual pixels on the device. One PX is not a device pixel. They're not the same thing. OK, so what is a CSS pixel if it's not the same as one of the little dots on your device that you're getting more and more of? It's a relative unit inside the web view.

Though it is not specified in any standards, it is agreed upon by all browsers that 96 of these CSS pixels correspond to one inch. The idea here is that you have these absolute units, such as the inch, and you want them to look something like an inch in real life as you move between different devices.

So obviously, if you have an inch specified in your style sheet on a really, really low resolution device, it's going to be represented by a different number of actual pixels on the screen than it will have to be represented on a very, very high resolution device. But you still want it to look something like an inch in both spaces.

And in order for the entire internet and the web not to completely misrender between these devices, you need to have a consistent relationship between your CSS pixel and your absolute units, such as the inch, that always need to look roughly the same. So therefore, 96 CSS pixels equals one inch. That's the relationship that has been established.

Finally, we scale them for you. We scale them for you. You don't need to worry about changing your style sheets, the numbers and measurements that you've specified, to account for resolution independence, because it's all being taken care of for you in WebKit. The same things will work. They'll just scale up as you want them to. All right, so why do you care? So as I was just explaining, for the most part, it's all automatic.

Your text is going to look awesome. We've put a lot of work into WebKit and the other parts of Mac OS X so that as everything scales up, it's going to have incredible detail and just look fantastic. So text, text decoration, all of that stuff looks fantastic. Form controls look impeccable. Borders, basically everything that WebKit draws looks amazing. So... So there are some things that WebKit doesn't draw, really. It displays. And probably the most notable example of that are images.

If an image is not a high resolution image, WebKit can't make it look like a high resolution image. So the idea of making high definition web content really comes back to images. There's a good analogy here to be had with television. So you have your old TV, you watch your shows on it, it's great, it's fine. You decide to upgrade, though, to a high definition television.

You can view the same content on your new fancy high resolution display. And it looks pretty much like it did on your old television. Maybe it even looks a little bit better. But there is some content that's made specifically for this device, content that really takes advantage of the hardware, specifically HDTV.

This content just looks incredible. Your old content will work fine, but you have an opportunity here to take advantage of the extra pixels that you're being given and make your web content look even more incredible than it ever did before, just like HDTV. So again, in terms of creating high resolution web content, it comes down to finding ways to integrate high resolution images and artwork into your web content. So that's what I'm going to talk about for the rest of our time talking about high definition web content.

All right, so earlier Adele was telling you all about SVG. You know, it scales, so you might be thinking, this could be a great solution for high-definition web content. It will look fine on regular devices. It will scale up perfectly with other devices, so you don't need to worry about it. So in a lot of ways, this is a great idea. But there are some problems with SVG and other scalable vector graphics, such as PDF, at least right now, so that it's not really a great solution today.

For instance, there is the image tag problem. Safari is the only browser that supports PDF as the valid source of an image tag. So if you use PDFs, it would only work in Safari with your image tags. Safari and Firefox, neither of them support SVG as a valid source for an image tag. So basically what this means is that to integrate these image formats into your web content, you would have to completely abolish the image tag. This would be a whole lot of work for you, So it's really not terribly ideal, at least right now.

What's more, it wouldn't work in old versions of browsers that currently support SVG. Won't work in browsers that don't support SVG at all. And even though this might be a great solution someday, it will never be a very good solution for photographs. Vector graphics just aren't the best format for photographs. So resolution-independent images might work great for high-definition web content someday, and we think that they will, but not yet.

All right, so what about just using high resolution images? What about replacing all of the artwork that you currently have in your web content just with high resolution versions of the same thing? So in a lot of ways, this seems like a great idea. It's a simple bait and switch. You just create high resolution versions of your artwork, replace the little paths that you have in your content. It's fine, right? Well, see, there are some problems here also.

Primarily, these high resolution images tend to be huge. They're big files. You're going to have everybody downloading them, even people who can't take advantage of all of the extra detail that you get, people who don't have high resolution devices to view them on. So everyone's going to be downloading these huge images. You're going to have to store them all. Basically, it's going to increase bandwidth. It's going to make things slower.

It's going to clog the tubes. So we've talked about two solutions that aren't going to work. So why don't we talk about something that will? This is an idea that we've come up with called the resolution-determined image. The idea here is that you could have images available of different resolutions.

And you could have a style sheet in which you specify exactly what you have available. And then the style sheet is smart enough to know which one to display in the browser. This can be achieved with CSS3 media queries. And I'll be talking about specifically how to do this later, but the idea here is that the resolution of the device that is viewing the content and the scale factor that is applied to it determines which image you select, which image is downloaded by the user, and which image they end up seeing in their browser. So it's a resolution-determined image.

CSS3 media queries give you a way to conditionally include certain style rules based on characteristics of the device that's viewing them. And we'll get to how to do that in a little bit. Another thing is that we've extended the DOM so that you can access the device pixel ratio through your JavaScript with window.devicepixelratio. So this is pretty cool.

This has some obvious applications. In that, if you're setting the source of an image tag or an image through your JavaScript, then you can obviously select a higher resolution image if you know that you have a scale factor applied. But you all know the power of JavaScript. You can do crazy things with it. You could render an entirely different web page if you wanted if somebody were viewing it with a scale factor applied.

And why you would want to do that, I'm not sure. But you can. So this is a really powerful tool, and we want you all to know about it and take advantage of it. If you want. So for creating high definition web content, we think this is going to be really important in the coming years.

And this is an ongoing discussion we want to keep having with other browser vendors and people like yourselves about the best way to do it. But right now, we think that some great ways to do it are to use resolution determined images and to take advantage of the fact that you can access the device pixel ratio through the DOM. That is something, by the way, that is currently an extension that we've applied to Safari, and we're pushing it into standardization, much like we did with Canvas, so that hopefully it will soon be implemented in other browsers as well.

All right. Let's talk about CSS3. I'm going to show you how to do some of these high definition web content things at the beginning of this section, too. So first, a little bit about CSS3. It's a specification being developed by the W3C. It is broken up into modules.

Most of them are still drafts. So what that means is that they can still change. And for that reason, for the properties that we've implemented from CSS3, we've appended the -webkit prefix. This is a pretty standard thing to do in browsers. For instance, in Firefox, they append the -moz prefix to things that are still in the draft stage. It's just us saying that we know that this could still change. And once the specification gets beyond the draft stage, we'll make sure we match what the final situation is with the whole thing and remove the prefix. So let's get into the properties.

First, background size. For those of you who have used a background image before, you know that when you use a background image, there is no way to specify what size you want one tile of that image to be. Of course, not without background size. With the image tag, you can specify a width and height as attributes so that regardless of the intrinsic size of the image, you could have it appeared, shrunken, or scaled up in your content, whatever you want. So this is sort of a way to do that same thing with your background images.

Here's an example of how you would use it. Background size expects two values, lengths or percentages, usually. If you give them lengths, like pixel units, it will obviously appear that specific length. With percentages, you're saying that you want one tile of this background image to take up the given percentage of whatever space this background image is tiling. So here I'm saying that I want my image, cupcake.ping, to take up exactly 50% of the background horizontally and exactly 50% of the background vertically for one tile, which means that I want the image to appear four times. So here's what it looks like in Safari.

And now Firefox does not yet support background size, although they will soon, I'm sure. So here's what it looks like in Firefox, where the cupcake is its intrinsic size. So another really cool thing about background size is that it will always hold onto this rule. So here I've specified the rule on the body.

So as I grow and shrink my web view, as I shrink my Safari window, the size of my body is going to change. But this 50%/50% will always hold. So here I've grown it. And so as I grew my window, I still have exactly four cupcakes in Safari. Again, in Firefox, it's still its intrinsic size.

Here I've shrunk it, so I have squishy cupcakes. If you didn't want to have the squishy cupcake effect, you could specify auto for one of the two values, either horizontal or vertical. And that-- that dimension would assume whatever value it needed to in order to maintain the aspect ratio of the image. And here in Firefox, we just have the tops of cupcakes.

So let's talk about how this can be applied to high definition web content. So I mentioned earlier that high resolution images are often really huge. And earlier I meant it in terms of their size in memory. But I also mean it in terms of their size. They're often these really huge images.

So you might have-- you might have a high resolution image that you want to use as a background image that's tiling a smaller space. And so background size is really useful for that. Here I have an image, peacock high res, that is a really huge image. It's something like 1,600 by 1,200.

But I'm saying I want it to fit in a div that has a width of 480 pixels. And I don't want a squishy peacock, so I've specified auto in my vertical direction. So here's what it looks like in Safari. Again, it's shrunk down the image so that it fits nicely into your small div.

And just to show you what this looks like without background size, here's what it looks like in Firefox. You may recognize this as the upper left hand corner of our peacock, the first 480 pixels horizontally and however much vertically. So again, this is another reason why just replacing all the artwork in your web content with high resolution versions of the same thing is not a great solution. Because you're going to run into edge cases like this where you-- just specifying width and height doesn't work, like with background images. So let's talk about using the same example with a resolution determined image, CSS3 media queries. I mentioned these earlier.

Again, this is the idea that you can have rules in your style sheet that will apply conditionally based on characteristics of the device that is viewing the web content. So you can query about different characteristics of the device, for instance, the width and height of the viewport, the screen dimensions.

You could create a style. You could create a style rule that applies only if you're printing to screen at all, so that if you were printing the content to, say, a printer, the style rule would not apply. We've extended the things that you can query about to include the device pixel ratio, so that you can apply a rule based only if you have a scale factor applied.

So here's how to use this. You'll recognize the top part of this as pretty much the same style rule that I had previously, except I'm saying that I want to use a low resolution version of my peacock as the default. This version of the peacock is actually the exact size to fit in the background image.

So it's what you would be doing now if you had a background image like this. But then I've specified a media query below it that says that if I have a user scale factor applied of two or greater, I want to instead choose to include a high resolution version of the image.

So here's what it looks like normally in Safari again. Looks the same. But look, now it works in Firefox too. Yay. So now the next screenshot I'm going to show you is the same content in Firefox with a scale factor applied to my UI. So I've applied a 2.0 scale factor. You can all do this in Quartz debug now on your tiger machines or your leopard machines if you want.

So everything just looks big because it's being viewed on not a high resolution display. So here's what it looks like in Firefox. You know, it looks fine. It's the same image, sort of stretched up a little bit. But here's what it looks like in Safari. How much better is that? Wait, you want to see that again? Hold on.

So without the media query, Safari would look the same as Firefox would. But Safari understands the media query, so it's able to understand to choose the high resolution version of the image instead. And it's really taking advantage of the extra pixels that we have because we have a scale factor applied.

All right, let's move on and talk about something else, border radius. So I'm sure you all use the internet, and you've noticed probably that there are rectangles all over the internet. But sometimes you don't want just a regular rectangle. You want a rectangle that has rounded corners. And so if any of you have created web content that has rounded corners, you probably know that it's kind of a pain in the ass. You have to do all kinds of fancy things with images. It's really hard.

So border radius is a much easier way to achieve that same thing. It's a much easier way to get nice, rounded corners on any of your rectangular elements. So we ran into a use case for this ourselves. I'm sure you all recognize our error page. When we were going through and assessing all of the artwork that we have as a part of our application so that we could get high resolution versions of it for a resolution-independent world, we saw that we were doing our error page with all of these images.

And it seemed really ridiculous to get high resolution images of these little lines and tiny little corners. So we decided to do it with border radius instead. And so this is actually done with border radius. It looks exactly the same. I'd show you a before and after, but there's really no point, because it looks the same. So here's your before and after.

Basically, border radius expects you to specify two values. You pretend you have a rectangle with an ellipse in each corner, and you specify the horizontal radius of the ellipse and the vertical radius of the ellipse. This gives you a lot of flexibility with the kind of curves that you can get. You can also have each of your corners have different curves, but most of the time you probably aren't going to do that. So here's a really simple example of how to use this.

This is if you had a circle in each corner with a horizontal and vertical radius, both of 60 pixels. And here you have a nice, beautiful, rounded rectangle. Yay. OK, a few more properties, or maybe this is the last one. I forget. Border image. So border image gives you an easy way to use an image as the border of your element.

What you do is you take an image that you want to use as the border, and you specify four values that cut your image up into nine pieces. The first one is how far down the image you want the border on the top to be. And then you specify the right, the bottom, and the left. And this, as you can see, breaks your image up into nine pieces.

You have your edges, your corners, and your middle. And they'll all be either stretched or tiled in their respective parts of your element that you're specifying border image on. And here's a simple example of how to do that. I said that I want those lines to come in 25% of the image in each direction. And there it is. I've been framed.

OK, so we've talked about high definition web content in CSS3. We think that other browsers are going to-- well, we know that other browsers are going to start or continue implementing CSS3. So soon these properties will be available in a lot of other places as well. A lot of other browsers are working on them.

We think that they're really powerful for creating high definition web content in some cases, and in general, just making your existing web content totally hot. So we've covered all our main topics here-- JavaScript capabilities, graphics, and style. Hopefully you've learned a few things. There was a lot we talked about today. But you can't leave yet, because there is one more thing.

So-- Those of you who have been following our open source project know about this already, so it's not as exciting for you, but it's still pretty damn cool. We have some new tools under construction. Our open source project gives us the ability to sort of have these works in progress that we can put out there, so these are all available through our nightlies, nightly.webkit.org. I strongly encourage you all to check them out. And so the first thing I want to tell you about is our new Web Inspector.

This is really awesome. People have been wanting one of these in Safari for a while. It gives you a really great way to walk your DOM, see all of the style rules that are applied, different metrics. It's really great for debugging your content, and also just for seeing how people did cool things on other sites. It's really handy.

Also, we were able to get this really custom, beautiful look out of it because our Web Inspector itself is created mostly with HTML and CSS and JavaScript, and we think it looks pretty great. We think it's pretty awesome. We also would like to tell you about our new JavaScript debugger, Dracera. This is taking advantage of the same-- Yay! Finally! This is taking advantage of the same JavaScript debugging capabilities that we made available for Dashcode.

But we thought maybe you'd want to debug your other WebKit apps, too. So now you can debug through Safari, and you can attach Dracera to any of your WebKit apps and debug your web content there. You can set breakpoints, step through. It's pretty great. And now I would like to call upon my colleague, Alice Liu, who is going to give you a demo of how to use these tools.

Hi, thanks, Beth. Hi, I'm Alice Liu, and I'm also a Safari engineer. Beth just told you about a couple of debugging tools that we've released in our WebKit open source project. And they were developed by another Safari engineer, Tim Hatcher. I'm going to tell you a little bit about how to use them Demo machine, please. Oh, we're already here. OK. So the Web Inspector can provide you a wealth of information about your document all in one place.

To get to it, I'm going to go to a web page that I think is pretty cool. And all we do is we pick something on the page and we Control-click and we say Inspect Element. And this is going to bring up the Web Inspector. That's hot. So here's a web inspector, and in this window here-- can you see that well? Let me see.

Okay. So, sorry. Okay. All right. We'll stay here. So this is a web inspector, and in this window here is your document markup. And if I click on one of these nodes, it's going to highlight the corresponding node over here. So let's pick something like... This Div intro, and it's going to highlight the intro for us in a red outline.

So let's see that again for another Div. I'm going to pick the next one, which is this one. So I really like this feature because it gives me a great visual connection between my document markup and how it's laid out on the page. So if you have kind of messy code, it's going to really help you in finding out where your things are and stuff.

Also, it's great for finding out how other people's websites are laid out as well. Okay, so down here we have different tabs for different types of information. So in the node panel, we're given node information such as element attributes and links and namespaces. So I'm going to, this is a good debugging tool, so I'm going to debug something about this web page. I actually like... how these links look. They're kind of nice. So let's find out what's behind them. So they turn colors when I hover over them. Let's find out more about them. I'm going to inspect this element by control clicking on it and choosing inspect element.

And then it jumps right to it. So node information, the href is articles. Next we have style. I'll come back to that in a second. Over here in metrics, we are given the margin, border, and padding radius. Let me zoom in on that for you. So that's nice, right? And then, over in properties, we've got all the JavaScript properties and their values. So let's go back to style. Over here in style, we have a wealth of style information.

So if we have computed style highlighted, what we're told down here is all the style properties that are actually applied in the end. And in this window, we have all the other style rules, and they're listed in the order in which they're imported and applied. So we've got this asterisk rule, it sets some values, and as we go down, we see other properties listed. If your properties have a strike through through them, it means that they're overridden by another rule after it. So we can see that color and border-bottom have been overruled by something else. Here's border-color, something else color, yeah, there we go. So let me do this again.

And we actually have one more rule. So here's the hover rule. And this is why it looks so cool. So basically, when I hover over it, I find out that, oh, the color turns black. The background color is set also, and we add a border bottom. So that's just how those links are implemented. So that's the Web Inspector. And we know that it's going to help you debug your websites, how they look, and also help you investigate other people's websites that you admire.

OK, so the next tool I'm going to show you is our JavaScript debugger. So we know that many of you have been wanting a good JavaScript debugging solution for quite a while. And recently, there have been two additions to this area for you web content developers. One is Dashcode, which is available on your Leopard CD. And the other one is Rosera, which is our open source solution. They both take advantage of the same technology.

That we enhance JavaScript core to enable this debugging. Rosera actually has the advantage that it can attach to any WebKit application. So that means that it's not just for Safari, it's for your WebKit application as well. So I'm going to show you how to use Rosera with a very simple example.

So Drisera I have in the doc here. And when you launch Drisera, it will ask you to attach to a WebKit application. And right now, I only have one running. But in this window is where you would also see your WebKit application. So we'll attach to WebKit. Let me just rearrange my windows here.

And I have a canned demo here. So this is a really simple just arithmetic demo. So let's use 10 and 5. And 10 divided by 5, that works. 10 times 5 works. 10 minus 5 works. But 10 plus 5 doesn't work. So I'm going to debug this 10 plus 5.

Over here in the Drisera window, the Drisera window should actually look pretty familiar to you. It kind of looks like Xcode, and because of this, it should be intuitive for you to use. So here's a gutter, and we can set breakpoints. And over here is a drop-down window for files.

I'm going to go over here, and I'm going to set a breakpoint in the onClick handler. Let me show you this, just so you can see that. So here's onClick. So Drisera has the advantage of being able to set breakpoints in inline JavaScript and not just within script tags.

Okay, so I set the breakpoint. We're going to start. Okay, I have broke in the onClick handler, and we're going to step in. Also, just like Xcode, if you want to remove breakpoints, you just drag it out. So let's step into this function, calculate. And let's step over. Result is 0.

Operand 1 is set. Operand 2 is set. And operator is set. So we're going to fall into the case of the plus. And we see that the result ends up to be 105. So basically, my mistake is in my code here. Something cool about Josera, the JavaScript debugger, is we have a console here. And the console is able to execute any JavaScript expression. So I can check values. Sorry. Let me show you closer.

Oops. OK. Result is 105. So this is a mistake. So I need to fix this. And the console will let you try out fixes before you actually change your code. So let's try something. I think what I want to do is-- I guess I could do something like parsing.

Op1 plus parseInt Op2. And it's 15, which is what we wanted. So this is exactly what I should do instead of just plus. So this is just a little taste of how Drisera can improve your JavaScript debugging workflow. And that's about it, I guess. Let me close this up.

Can you get the slide machine, please? Okay. So, just a little reminder that these open source debugging tools are actually still under development. And what that means for you is that we actually want to invite you to come and try them out, to file bugs on them, file enhancements that you think could help the product.

And if you're daring enough, you can submit patches, too. So, this is just the nature of our open source project. And you can try both the Web Inspector and Drisera if you download the Nightly at nightly.webkit.org. And basically, more info about these tools are available at our website, webkit.org. And please file bugs under those components. Thank you.