And this is session 135, Safari for Web Designers, building content for the new web. So, a lot of the sessions here at the conference are really targeted towards developing one kind of application, and that's a desktop application. The kind of thing that you would either put up on your company's website or put up on version tracker or maybe even package up in a box, and then your users would download it or put in a disk to install it, and then everyone sort of has their own personal copy of your software running on their own personal machine. Well, in this session, we're going to talk about a very different kind of application, and that is the kind that runs in Safari.

The web browser. Now, when people talk about applications that run in the web browser, there are a lot of complaints about web technologies, and here's a few of them. I can't get the layout that I want with HTML and CSS. I can't get the functionality I want using JavaScript. JavaScript is too slow. Another complaint that's not listed is I can't deal with cross-browser compatibility. It's just a huge headache.

Well, I can't deal with cross-browser compatibility. Well, these are all really sort of myths, because if you look at a lot of new web applications out there and new applications that are using web technologies like the dashboard, you can see that it's really possible to develop an application that runs in the web browser or uses web technologies that really has a lot of the characteristics of some of the best and most common desktop applications.

This talk is obviously for web developers, but I just want to remind you that since we're just talking about web technologies, this is also for widget developers. All the concepts that we're going to talk about today apply to web pages, and they also apply to widgets. So, let's get started with the first part of our talk, which is best practices for web compatibility.

So if you think that you're sort of getting around this whole doc type thing by leaving it off, leaving the doc type off of your document altogether, you're really not. Because if you have no doc type or a malformed doc type, that will trigger compatibility mode in the web browser.

So I actually have a really great example of compatibility mode versus standards mode. I have this snippet of HTML right here. And it's just a div. The font size is set to XX large. And inside, it says, hello, world. Now, with this snippet of HTML, I've left off the doc type. So both of these browsers, Safari and Mac IE, are rendering the same snippet of HTML.

But in compatibility mode or quirks mode. So on the left, in Safari, you can see that Safari renders it in a 32-point font, whereas Mac IE is rendering this in 48-point font. Same HTML, same exact thing, two different browsers, two totally different renderings. So the way to fix this is really to add a doc type. I went ahead and added that HTML 4.01 strict doc type that I've... talked about earlier.

And now, this sort of makes...causes each browser to render the code in exactly the same way. Basically, adding a doc type that triggers standards mode in the browser really brings you closer to a standard and to a more uniform rendering of your pages in lots of different web browsers. And that's obviously what you want. So include a doc type.

After you include a doc type, code up your whole site, or maybe as you're starting to code up and as you're going along, you're going to want to validate your code. And basically, what validation does is it checks your code against the syntax that you've claimed for that page. I mentioned earlier, after I add my HTML 4.01 doc type to my document, that is sort of saying to the browser, "This whole document, it's HTML 4.01.

Render it as such." Validation checks your code against the syntax for that particular language that's claimed in your dot type. And really it makes it so that the browser doesn't sort of have to second guess what you're doing. If you leave off a unit identifier like pixels or something like that, validation will catch that.

So there are lots of validation errors, and they can often be a little cryptic when you're validating. So I just wanted to list a few of them here. Lowercase dot type, incorrect nesting, uppercase tags, unquoted value attributes, missing a closing slash on an empty element such as an image or a BR tag.

These are really common validation errors. It's best to sort of validate, you know, as you go along so that you don't have to do a lot of validation. And then you can also use the W3C markup validator to help you find those errors. Luckily, there are some great tools out there like the W3C markup validator and the W3C CSS validator to help you out and help you find those errors.

So we've sort of covered compatibility. And the next thing that we're going to talk about is extensions and RSS. So let's get into everyone's favorite extension is the second one listed there, XML HTTP request. It's sort of used everywhere all over right now. It's sort of the thing that is making Ajax what it is, in my opinion.

So we're going to be revising our wiki, and we're going to use content-editable and XML HTTP request to sort of eliminate that ugly flashing, you know, in the wiki that sort of obviously says, you know, this is running in a web browser. We're going to use these two attributes to revise our wiki to make it much more of just an inline text editor. So content-editable is an attribute that can be set on any block-level element.

And basically, this attribute just enables inline rich text HTML editing. You'll see a demo of it shortly, so I won't get into it much more. XML HTTP request, it was first implemented in WinIE, but it's so useful and so great, it's really now a de facto standard that every browser implements.

Basically, it just allows the client or the web browser to submit and retrieve data in the background. So that's what basically is eliminating page reloading. So let's have a demo. I'm going to grab a drink of water. And can we switch to demo machine one? Okay, great. Okay.

So, to sort of illustrate my point that Vicki really needs a makeover, we started our own Vicki to track our interview schedule for the Safari team. So, you can see there are some really illustrious people who want to work for us. So, let me just show you how an old Vicki would work.

I'd click "Edit." And this text area comes up, and there's sort of all these keys at the bottom, and I kind of want to add a link, but I'm not even sure how to do that. Let me just copy this one, and we'll say this is on maybe the 24th, and... We'll say that it's Susan Care who wants to interview with us, and she's going to come in at 2:00 PM.

So now I click Update, and this page reloads, and I guess my changes are right here. So that's basically how old wiki looks. Like, anyone who is very non-technical, I think that would be very difficult for them. Sort of this crazy text field with all these special symbols that you need to add to make things look the way you want is really, really confusing.

So now let's go to our brand new site, which is going to illustrate some of the ideas that I just referenced in my slide. So this isn't the flashiest demo, but that's part of why it's so awesome. Basically, I'm going to click Edit Calendar. And now, this whole div is editable. You can see my carrot sort of cycling through the days of the calendar there. And so I'm just going to pick one, and I'm going to say Susan Care, 3 o'clock.

Click Done, and that's it. That's it. So I can open this in a new window. and there's a bug. But basically, I mean, that's it. It's sort of just like a text editor as opposed to this ugly page reload, like I'm so obviously using a web application sort of demo.

So how did we do this? Let's take a look at the source. So this is my HTML file. And basically, I've got this edit calendar button, which calls this set content editable function. So it gets this element named wiki, which is down here. I've added two markers to indicate the editable area that I want to pay attention to.

And then basically, set content editable just toggles the content editable attribute on the wiki div and toggles the value of the button, either edit or done. And if we're done, we want to send the data using XML HTTP request. And this is incredibly simple. Basically, you just want to see if the XML HTTP request function is supported on the window, create a new XML HTTP request, call open on that object.

You're going to do a post. You're going to post to this URL, and true is the final argument. And then, basically, all that I'm doing in terms of the new data that I'm going to send is I'm getting the inner HTML. Of this wiki div. So basically, I'm sending.

This content here in my post, and then I have a CGI script that just really basically reads this file until you get to this point, and then writes the post, and then writes the few final tags here. So, it's really, really pretty simple. I mean, I did this in a few lines of JavaScript, and I'm no Perl expert, and I wrote the CGI script as well.

So, that's sort of an illustration of how you can use content-editable and XML HTTP request to create a wiki or a sort of editor that behaves more like a text editor, like TextEdit or something like that, as opposed to a web page. Okay, can we go back to the slides? So, the next thing on the agenda is Safari-specific extensions.

XML HTTP request is an extension that isn't part of any formal spec, but it's so useful, it's implemented in every browser. But these next few things are Safari-specific, and you'll see them in the RSS view. The first one is the search field, and it's really just an input type. Input type equals search.

It has a few attributes. Placeholder is the default text, which is grayed out, and then you click on the field and that disappears. This is analogous to, you know, the Google search field in the Safari Chrome that says Google inside of it and then disappears when you click on it.

Incremental is if you want your search to be incremental, basically. The on-search handler is executed on sort of the pause that follows typing. Results is the number of results that you want to show in the list. Again, like, the Google search field is sort of a good illustration of this.

and auto-save is whether or not you want those results that are in the results list to persist across sessions. The other Safari-specific extension to discuss is the slider. And all that really is is an input type that is a range. So the attributes on that are just a minimum and maximum value, and precision can be either float or integer. And the input event fires whenever the value of the slider changes. So you can tie a JavaScript event to that input event, and it'll fire basically whenever the slider moves. Really simple stuff.

Beyond the widget-y extensions and extras, we're going to talk a little bit about RSS and why it's a cool idea to add an RSS feed to your site. When you decide that you want to add an RSS feed, there's really just a few things that you have to do. You have to sort of think about the content that you want to include in your feed, sort of, you know, like maybe for my interview demo site, I want to include, you know, an RSS feed that would track feedback for each of these individual candidates.

Next, you would just code up the XML file that is going to serve for that feed, validate it, of course, just like HTML files. Since it's XML, you should be aware of that. You don't have any common XML syntax pitfalls like symbols like the left arrow and ampersand should be replaced with their HTML equivalents. And you can use online tools like Feed Validator to do this type of validation. And then the last step is to publish it.

So why add an RSS feed to your site? Well, the first reason is really just that it delivers content in a different format. And for people who are really interested in this sort of format, that's really important. There are a lot of people out there who just want the headlines and the summary and want to be able to quickly see, you know, the latest and greatest data without sort of, you know, all this other stuff jumbling things up, like graphics and whizzy menus and stuff like that.

So that's one reason. The second is that updates are easily recognized. If I were to add a page to my interview site that sort of tracked feedback for each individual candidate, if I had an RSS feed tracking that, I would be able to easily see whenever a person added new feedback or that sort of thing. And really, the updates are everywhere. They're in the bookmarks bar all over the place, and they're also in the RSS view sort of all over the place.

The next reason that you might want to add an RSS feed is that it's easily searchable. This is actually a little video right here that you might not be able to see unless you watch closely, but I can sort of search all these articles on a string in a way that I wouldn't be able to do using the find menu or even a search field that's on a site. It's very valuable.

So now, to show us how to add an RSS feed to your site, Adele Peterson is going to come on stage and sort of... Oh, and there she is. Sort of the gist of it. The kicker is that we're going to do it automatically using XML HTTP request. Adele? Thanks, Vicki. Thanks a lot. Okay. So let's go back and take another look at the demo that Vicki was showing you.

So Vicki talked a little bit about the advantages of adding an RSS feed. And we're going to add RSS feeds for each of our candidates so that we can keep track of their feedback as people want to add that data. And the advantage of that is, as you can see in the bookmarks bar, as data is added, someone can subscribe to the RSS feed and keep track of it by just seeing when the feed has been updated. So if we go and look at one of these feedback pages.

You'll see that a bunch of people have already added feedback for this particular candidate. One of the cool things is this is using some of the technologies that we've already talked about. So we're going to use content editable to make this form a little easier to deal with. So you click the edit button. And ta-da! You can edit right in line.

Once we're done entering this information, we want to add it to the RSS feed. As web designers, I'm sure you know that when you have a lot of data that you want to display in different ways, the best way is not always to enter it manually. In this case, you'd have to end up adding RSS feeds in -- you'd have to end up manually creating the XML files for the feeds for each candidate.

And it's a lot easier to build something into your site where the person who initially enters in the data in the form will then cause the data to automatically be updated in the XML file and display in the RSS feeds. So that's what we're going to do. And I'll show you a little bit of the code later. So click done. And... Everything executes. And we'll go to the RSS feed.

and there's my feedback. Yay! Thumbs up, he was great. So now... So now we can kind of see how some of the benefits that Vicki was talking about earlier about using the RSS feed in this way, just that you can search and see who else used the word great to describe this candidate.

And you can just say, oh, who's interviewed him so far? and I will be talking about the new features of Safari RSS. You can manage the data in this way and without having to go and create a whole other file to manage this data, you're automatically updating it when you enter in the data initially. Okay. So let's go back and look at the JavaScript and see how we did this.

First, let's take a look at the HTML so we can see some of the hooks we put in there to make everything a little bit easier for ourselves. Let's scroll down here and look at where we have the content-editable part. In these paragraph elements, we added an ID that is equal to the tag name that we're going to need to use when we create the XML file for RSS.

So the XML file needs to have -- when we add this entry for this particular bit of feedback, it needs to have a title tag and a description tag. So we're going to stick this in the ID so that in the JavaScript when we go to create the data that we have something to reference. Okay. So now let's go and look at the JavaScript.

When we first clicked that edit button, we had something very similar to the last demo where we went and set the content editable attribute, etc., etc. No big deal. We're old pros at that. So the next time when you go and click the done, we call this build post function, which is going to build up the data that we want to send to the server. And then when we have that data, we're going to send it to the server using XML HTTP requests so everything's behind the scenes and we don't interrupt the workflow.

Okay, so let's take a look at the build post function. So basically all we're doing with build post is we're looking at those paragraph elements and, you know, using the IDs to identify them, and we're building up this string with the inner HTML of those elements. So when we're ready to go and send the data, all we have to do is create our XML HTTP request and open the URL and send the data just like we did before. And the script on the server is very basic. You know, all it's doing is inserting that bit of XML into the XML file that already exists that we've been using for the feed. So now I just want to show you guys one more thing.

One more benefit of doing it this way is that, you know,

Okay, can I have the slides again? So XML HTTP request, you gotta love it. It's so useful for so many things. So now we've covered compatibility, we've covered extras like extensions and RSS, and the last thing that we're going to talk about is plug-ins. And really, plug-ins, you know, all I have to say about them is really they're for everyone.

So, plug-ins are a great way to get your users to use your plugins. And plug-ins are a great way to get your users to use your plugins. And plug-ins are a great way to get your users to use your plugins. And like I mentioned before, even if you think you're not some hardcore programmer that would never, ever write a plug-in, it's a technology that's worth learning because you can really add a lot of native functionality to your websites and to your widgets. Sort of the iTunes music player, the address book widget, those things are using plug-ins because they're running native code.

So I'm going to keep my discussion of plugins very short because there have been probably three or four talks that go into a lot of detail about plugins. Basically, I just want to mention that there are two kinds of plugins that you could write. You could write a Netscape-style plugin. The advantage there is that it's compatible with Safari, Firefox, and OmniWeb.

Or you could write a WebKit plugin. The benefit there that it's extremely easy to implement, and it's also compatible with any WebKit-based application. So I'm not going to get into a lot of detail. Let's just go into a demo for adding a plugin to your site with our wonderful intern, Kevin Decker.

Thanks, Vicky. So can we get demo machine number two, please? That would be this one. Cool. So I've made a couple changes to Vicky's awesome site. And what I want to do is, I guess I first want to preface this, is that this is a really exciting time to be developing on the web. Because before, you know, you had this whole paralysis through analysis where, you know, you know, if you wanted, let's say, for example, download a resume, you know, you have to download the disk and copy it and go on your desktop, you have to manage it.

So one of the first things I did was I thought, well, when I mouse over my name, for example, I get this little pop-up thing, kind of like a tool tip, fades away and out. And then I can click on this, I can click on this person's dorky picture, click on this, and I'll get this iframe here. And I can take this, I don't need that scroll bar there, I can move it around.

It's got, it's got a, you know, a fake resume. So, and you can, this is all in the HTML. So if you want to download this disk, you can. But if you just want to snap shot, if you want to see it, it's right there. So that's that.

And something else that we thought would be beneficial, too, is, you know, gosh, you know, we have this on the web, but what if I want to contact, what if I want to put this person's information, let's say, in my address book? Well, before, I'd have to go in my address book and type all it in. And that's just really not necessary. So with a plug-in, what we did was you click this button right here, and when I click that, I go in my address book.

There it is. So what I want to do is... It really works! So, when Vicki said it was really easy to write a WebKit plug-in, she wasn't kidding. So, I'm going to open this up. There's two things I want to show. I don't want to go into a whole bunch of detail about how these plug-ins work because, as Vicki said, there were sessions already, but I just want to give you the bird's eye view. But I think really that will give you enough to get started right away.

So, first let's look at what it's like to use it. There's two parts to this. There's a JavaScript part, and there's also the actual Objective-C plug-in part. And so, first let's look at the JavaScript, what that does. So, I'm going to open this up in Xcode. And basically, the idea is, when I moused over the address book icon, when I actually clicked it, this happens right here.

We get all this information, and these two lines of code right here, we add the contact. So, we're going to open this up. We get the embed, which is the plug-in that we have, and pass it this information. So, the real meat of what's interesting is this plug-in.addContact. How does that work? Well, that's what we're going to see right now. So, I think I can quit this now, but that's just so cool. I'll go to my plug-in.

There's a couple things you want to do to make this actually happen, and I'll explain these one by one. So you want to start off right here with returning an NSView. This is the plug-in view with arguments. This is basically where you instantiate the plug-in. When Safari calls your plug-in, this is what gets called, so you want to make sure you instantiate it.

This set arguments thing is kind of important. It may be especially important if you want to pass arguments to it. For example, the QuickTime plug-in passes arguments like the size, how big you want to make it. Anything that you want to put inside of a markup tag will go in here as arguments. So that's basically all this is. The web script for name selector, what this does, when I have my, let me go back to this part here.

Notice right here this method, add contact. Well, you say, where did this come from? Well, the answer is, it came from the web. It came from this. This is where we basically bind an Objective-C function, a method I should say, to this from JavaScript. So JavaScript thinks this method is called add contact, and we basically say, you know, if this method, use this method right here and call it add contact. That's how we're going to expose it to JavaScript.

And so this is the only, something else you want to do is, is selector excluded from web script? It's kind of important too, because, you know, your implementation has many details. Not all of these details do you want to expose from JavaScript. Only the ones that you want to expose, you should put in this method. In this case, we check if the selector is this add contact with first name, if it's, then go ahead and return no. If it's not that. I said that backwards.

If the selector is this, then don't exclude it. Otherwise, return yes. So, now, here's actually, this one function right here does the entire address book operation. This add contact with first name, last name, address, city, blah, blah, blah. So, when I scroll down, this is basically using the Mac OS X address book framework.

It's really, really simple. This is a few lines of code where we just create an, an, an, an AB address book and an, an, an AB person. You, you can go on the Apple website and look up, you know, AB person and figure out how to do this in, in no more than 10 minutes.

So, basically, we just, and, and last but not least, we also, the, the, the picture in the address book, this right here, in the address book, it lets you also store pictures. So, from JavaScript, we get a URL and we put that URL in, in, in the picture. And then, last but not least, we add the record to it and we tell it we want to save. And that's basically it. And, of course, you want to be a first cloud, you want to be a, you know, clean and de, de, deallocate the arguments.

Anything that you've, that you've used. So, that's basically, in a nutshell, just to recap, you want to, this method, you're going to want to pay attention to, this method and right here, this plugin view with arguments. If you can implement those, you're going to want to pay attention to this method and right here, this plugin view with arguments. those three methods, then you too can make a plug in. And if I can do it, you guys can definitely do it. So, there you have it. Thanks a lot, Vicki. - Thank you.

Hey, that was probably my favorite demo. Mine too. So now we've sort of covered these three main areas, compatibility, extras, and plug-ins. And so now you've got the tools you need to go out and develop some great web applications. I just wanted to recap the URLs that I cited in my slides because I don't think they're posted on the web. So if you want to take a quick look there. And who to contact is Mark Malone. He'll be on stage shortly. He's our Internet Partnership Manager. If you have any questions about compatibility or anything that we've talked about today, he'll pass those questions on to me.