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 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 these are, 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, 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 so In order to illustrate this point, we're going to give an old web technology kind of a makeover today. So I was browsing around for a technology that could really use some revamping, and the one that I came up with was Wiki. So basically, the way Wiki works is, for those of you who aren't familiar, there might be one or two of you out there, the way that it works is you click maybe an edit button or a link, and then a text area will open up. There's a bunch of plain text in there, and you've got to sort of muddle around for the area that you want to edit. Then you click a button that says maybe done or something like that, and the whole page reloads, and you can sort of see your changes that you just added. So that might sound pretty whizzy, but the fact of the matter is that really it's just like living in 1995. I mean, we may as well be back to gray backgrounds and courier text because it's really nothing new that has happened in the last 10 years or so. I even went around and looked for what I thought would be the best example of any wiki on the web, and the one that I came up with was Wikipedia. So I saw this wiki, and I had really high hopes. I thought, oh, it looks so great. It's got this styled text. It's got this beautiful image up in the left-hand corner. But really, under the hood, it's still the same thing. It's really just 1995. So this is definitely something that needs a makeover, and we're going to illustrate a lot of the ideas of how you can use web technologies to make an application that runs in the web browser that has a lot of the characteristics of common desktop applications. So here's the roadmap that we're going to follow today when we're making over our wiki site and sort of following this whole idea of applications for the new web.

The first thing that we're going to talk about is compatibility. I don't think you can have a talk for web designers without talking about compatibility. It's sort of, you know, the monkey on everybody's back. But we're going to talk about best practices, doc types, validators, things like that, that will help you if you're either coding up a new site or trying to get an existing site rendering the same in all browsers like Safari, Firefox, and Mac IE. After that, we're going to go, ooh. After that, we're going to go over a few extras, like extensions like XML HTTP request and some Safari-specific extensions like the slider and the search field that you see in the RSS view. And we're also going to talk about RSS and adding an RSS feed to your site, why that's a good idea. Lastly, we're going to talk about plugins. You may be thinking, I'm a web developer. I don't write plugins. But I'm going to show you today why it's really worth it to explore this technology and then it's really pretty simple. So you should look into it.

So 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 I were coding up a website, or let's say I had an existing wiki that I wanted to revamp a little bit, the first thing that I would do is I would do a little research. And the first place to look is really the W3C, the World Wide Web Consortium. So this is sort of the body of people that defines how web technologies like HTML, JavaScript, and CSS should work. and they have their specifications for all of these technologies up on the web.

So if you have some ideas for a site that you're going to write up or some revisions that you'd like to make to an existing site, this is a good place to start to sort of see what tools are available. Beyond the W3C docs, there's sort of this next step, and that's real-world compatibility. So there's sort of what the spec says and how things should work, and then there's how things actually work. Nobody's perfect, every web browser has bugs, and every different version of every web browser has bugs. So the next thing that you're going to want to consult are some compatibility tables to see maybe this CSS attribute is broken in this browser but works well in this one.

I looked all over the web and the best compatibility tables that I could find were on Peter Paul Koch's site, which is quirksmode.org. and he has some really great resources there for DOM, CSS, and JavaScript compatibility. It's a good idea to look at something like this when you're coding up a new site or revising an existing site because you really want to see, like, do I want to stay away from this attribute that only works well in one browser? Maybe there's a different way that I can do it. This will save you a lot of time in the long run, especially when you've, you know, hit that final step and you're ready to look at your new site in 10 different browsers. If you do a little bit of research up front, it won't look vastly different. You won't have 10 different versions, basically. So after you've done a little bit of research and checked out some compatibility tables, you're kind of ready to code up your site, the next thing that you want to think about is a doc type. And what a doc type really is is it's sort of a message to the web browser about your intentions, about the syntax that you've written this document in. So basically, what happens is, I'm a website author, I'm writing a webpage, I include this doc type at the top of my document, like let's say the one that I've listed here, HTML 4.01 strict.

So I put this at the top, and this is sort of a message to the web browser that says, "Hey, this document is HTML 4.01 strict. please render it accordingly, according to this spec. So that's what's happening on your side as the website author. You're adding this to the top of your document. On the web browser side, it receives that document and sort of looks at that doc type and sort of makes a decision at that point. It says, okay, should I go into strict mode or should I go into quirks mode? and those are more formally called standards mode and compatibility mode. Basically, those are two different rendering modes.

Strict mode renders things according to a standard, and compatibility mode, or quirks mode, renders a page in such a way so that it might emulate bugs in old browsers. And every browser sort of has their own implementation of quirks mode. When you're coding up a new document, you should always use standard mode and never use compatibility mode. Really, it's just there because the web has a long history and there are a lot of really old websites out there that are sort of relying on this buggy behavior in old web browsers.

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 XXLarge, and inside it says, "Hello, world." Now, with this snippet of HTML, I've left off the doctype. 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 doctype. I went ahead and added that HTML 4.01 strict doctype 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, you know, 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 doc type, incorrect nesting, uppercase tags, uncoded 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 as you go along so that you don't end up with like 2,000 errors once you've coded up your whole site. 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. Thank you. 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 requests to sort of eliminate that ugly flashing in the Wiki that sort of obviously says, this is running in a web browser. We're gonna 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 reload. Okay, so let's have a demo. I'm gonna grab a drink of water. And can we switch to demo machine one? Okay, great. Okay.

So, to sort of illustrate my point that Wiki really needs a makeover, we started our own Wiki 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 Wiki 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. We'll say that it's Susan Care who wants to interview with us, and she's gonna come in at 2:00 PM. Oops.

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:00.

Click done, and that's it. That's it. Thank you. 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 gonna do a post, you're gonna 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 WikiDiv. 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 onSearch 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, the Google search field is sort of a good illustration of this.

And autosave 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 like whenever the slider moves. Really simple stuff.

So beyond the sort of widget-y kind of extensions and extras, we're going to talk a little bit about RSS and why it's kind of 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 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 like all these articles on a string in a way that I wouldn't be able to do using like the find menu or even, you know, 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's gonna come on stage and sort of, oh, and there she is. Sort of the gist of it.

Sort of the kicker is that we're going to do it automatically using XML HTTP request. So 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 gonna 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.

So once we're done entering this information, we want to add it to the RSS feed. So 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 gonna 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 we'll go to the file. 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 Vicky was talking about earlier about using the RSS feed in this way, just that you can search and see, you know, who else used the word "great" to describe this candidate. And, you know, you can just say, "Oh, who's interviewed him so far?"

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.

So 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. So let's sort of scroll down here and look at where we have the content editable part. So in these paragraph elements we added an ID that is equal to the tag name for -- that 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. We're going to stick this in the ID so 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.

So 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, et cetera, et cetera. 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 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 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, so now I just wanna show you guys one more thing, one more benefit of doing it this way is that, is that you can have an aggregate feed in RSS. So here I've created a folder in my bookmarks bar called Feedback, and in it I have four different RSS feeds, and each of them has a little unread count next to it. So let's say I want to view all RSS articles, and here I have an RSS view that has all of the feedback from all of the candidates. So I can search it for everyone who talked about Joe Schmoe, and I have all of his feedback. And let's say I just want to know everyone who talked about giving a thumbs up. And then the RSS feed will do all that management for you. So that's one advantage of doing that. So the end user gets that benefit of RSS, and you get to use your cool new XML HTTP request technologies to not have to manually enter in all the XML. Everyone wins. That's it.

All right. Thank you. Thank you. Okay, can I have the slides again? So XML HTTP request. You've got to 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. 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. Amen. 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 plug-in to your site with our wonderful intern, Kevin Decker.

Thanks, Vicki. So can we get demo machine number two, please? That would be this one. Cool. So I've made a couple changes to Vicki'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 had this whole paralysis through analysis where if you wanted to, let's say, for example, download a resume, you have to download up the disk and copy it. It would go on your desktop, and you have to manage that. 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 a fake resume. So this is all in the HTML. So if you want to download this disk, you can, but if you just want a snapshot, 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, we have this on the web, but 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 Vicky said it was really easy to write a WebKit plugin, she wasn't kidding. So I'm going to open this up. And there's two things I want to show. I don't want to go into a whole bunch of detail about how these plugins work because, as Vicky 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 plugin 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 then these two lines of code right here, we add the contact. So we get the embed, which is the plugin that we have, and pass it this information. So the real meat of what's interesting is this plugin.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 plugin.

And 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 plugin view with arguments. This is basically where you instantiate the plugin. When Safari calls your plugin, 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 plugin 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 a 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, well, where did this come from? Well, the answer is 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 addContact, and we basically say, you know, if this method, use this method right here and call it addContact. That's how we're going to expose it to JavaScript. And so this is the only... Something else you want to do is this isSelector excluded from WebScript. 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. 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.

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 AB address book and AB person. You can go on the Apple website and look up AB person and figure out how to do this in no more than 10 minutes. So basically we just, and last but not least, we also, 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 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 clean and deallocate the arguments, anything that you've used. So that's basically, in a nutshell, just to recap, 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 three methods, then you too can make a plugin. And if I can do it, you guys can definitely do it. So there you have it. Thanks a lot, Vicki. Thank you. 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. and it's