 My talk is how to make friends and influence people with HTML5 and stuff. Nicholas Otto, I work for Fleet Ventures as well. I see Mike put us both up front so we could get out of the way and enjoy the conference. I think we both work together. Yeah, sure you do. So OK, so yeah, so Fleet Ventures, we do a lot of HTML5 stuff. And really, we're really diving into it. We've been spending the past couple of months evaluating it and seeing where we can use it. And we're fortunate on our medical software, which is where I primarily work. We can tell our clients, no, you have to use certain browsers. So we don't have to support such fun projects as Internet Explorer and all that. So if you're doing IE6 apps, well, you should probably leave because this is all worthless to you anyway. And you better spend using this time to convince your boss that you should let your users upgrade. So what is HTML5? In case you didn't know, it's HTML4++, next-generation kind of standard stuff. It's not XHTML. That's dead. There's no longer version 2. So HTML5 is the way to go. And it really is the only way. And a lot of people, when they say HTML5, they think of the cool examples online. Like I think it was Tuesday. Google had their Canvas demo where you could go and you could move the mouse through their logo and all the balls would move everywhere. That is Canvas. And a lot of the HTML5 stuff people think of, it's really HTML5 plus CSS3 plus a whole bunch of new JavaScript APIs that aren't part of that standard. So one thing to know, if it worked in HTML4, it probably will still work in HTML5. And even if it's not in the standard and it's something bad that you shouldn't use, like Blink or Marquis, that I know you're thinking, how can I not make a real website without those? Browsers will still support that for a while because we have to face it. There's crappy developers out there that write bad code. Of course, no one here would. So they still support it. So if you really wanted Blink and Marquis and you didn't want to do CSS because you're weird like that, you still theoretically can do it. Your mileage may vary. And one thing to note, remember, is that HTML5 isn't this massive standard that you have to wait for the entire thing to be implemented before you can start using it. You can start using key parts of it like Canvas or video right now on almost any browser. When you start getting to some of the more abstract stuff, like validations and forms or certain tags, then you have to check by browser. Some will only work in Opera. Some will only Chrome, WebKit, in general, or whatnot. So quick warning, it's in the working draft. Stuff might change, which really is stuff will change. So be prepared for that. As I said, a lot of it's pretty stable. So you can start using it today, and you won't have to really change anything. Most of the changes will be done browser side. So unless you're writing Chrome or Firefox, then you probably won't have to worry about it. It's theoretically, they're supposed to reach a recommendation by the end of this year. So hopefully Christmas present to web developers. But they missed their last deadline by about eight or nine months. So no one knows if that's going to carry over, if they're just going to eat that lost time or what. So we'll see. And candidate recommendation, which is kind of the last step or the second to last step in the W3C is the end of 2012. So who knows, maybe HTML5 will bring up on the end of the world. Ian Hixon, who I believe works for Google. He's really big in the community. He's part of the standards board. Is estimated that it won't actually be a candidate recommendation until 2022. So if you have a pointy hair boss out there who is like, oh, it must be standardized. Everyone must be using it. You're probably not doing Ruby. You're probably doing COBOL or something and looking at upgrading to Java. But just be aware of that. Really, it's not really an issue. And I'm going to give a quick overview of kind of the W3C procedure so that you can kind of counter with, well, OK, this is where it's going to go. Let's just use it anyway. So right now it's in the working draft. That's when anyone, the unwashed masses like us, can go and complain and talk and discuss it. Next it goes through a last call working draft, kind of just, hey, roll to bed, give your comments. And then it goes to candidate recommendation. This is where it goes. And the implementer, so people like Microsoft and Apple and Google and Mozilla, they're all going to get their opinions in. They're going to say, no, we can't make a browser without Blink or Marquis. You're crazy. And then they debate it for a while. And then once it passes candidate recommendation, it goes to a proposed recommendation. This is where it goes to the advisory council for W3C. And they talk about it and they discuss it and they spend the next 20 years arguing over it. And then once there's two 100% complete implementations, then it's a recommendation. And that's where that 2022 date is. Whereas the proposed recommendation or candidate recommendation could be this year or within the next couple of years. 2022 is where you're going to get this last step. And really by the time it gets to 2022, you're probably going to be doing HTML6 or 7 or 10 or doing custom extensions and all that. So it's not really an issue unless you have to have it 100% complete. No web talk would be complete without talking about browsers. And I'm sure everyone here knows kind of what the big players are in the market. Chrome's one of them. Safari, they're both WebKit. A lot of the stuff, if it works on one, it works on the other. You don't have to worry about it. There are some features that are Chrome or Safari specific that are kind of a pain in the butt. There's Opera, which they seem to implement standards before they're even thought up. But no one uses it. It's kind of a cool toy. There's Firefox. In my opinion, the new IE, they're getting slower. And people are having problems with it. But they're still fairly standards compliant. And they're still a good browser. You have IE9, which this is your morning heresy. So get your stones ready and someone go light a pile outside to burn me. But IE9 is actually a good browser. Microsoft's done a really good job in the past year, year and a half of how long they've been working on it of making a standards compliant browser that doesn't like ultimately suck. It's no IE6. And actually, if you look at speed tests, it's actually faster than Firefox in all areas, which isn't known for its speed, but it's nice not to be last place. And if you're working with IE earlier than IE9, I'm sorry for you. Yet again, this talk isn't probably gonna be helpful. Go argue with your boss about using real browsers and being big boys. There's a lot of plugins that you can use in IE6 to IE8 that will make it a semi-real browser. One of them is being Google Chrome Frame. But if you're gonna force your users to install a plugin, you might as well force your users to install a real browser. So good luck with that. And so really quickly, there's a couple of things. There's two levels of obsolescent in HTML5. There's some stuff that will still conform and it's mostly just syntactical. Well, you shouldn't declare the default values of stuff because that's just stupid. And then there's stuff that won't conform and it will blow up when you try to validate it and the website will make fun of you. So some conforming stuff is using HTTP quiv in the meta tag, setting the image border equal to zero and there's default, why are you doing that? So you really shouldn't be using that. And summary on a table. I'm not sure on why they chose that one, but they did. You can go check on their website. There's a couple more things but these are really the biggest things that I think will probably affect people here if they were to switch over to HTML5. So stuff that's been removed and this is the stuff, as I said, that will cause your code and your markup not to validate. Applet and no embed. You should use embed or object instead. Frame, frame set, those are completely gone. Can't use them anymore. You still have iframe, so if you need that type of framing stuff, there you go. And a whole bunch of CSS related stuff. I've kind of picked on Marquis and Blink but there's TT, there's Stripe, there's U, Big, Center font, and a whole bunch more. So go check the website. There's a bunch of stuff on there. Most of it's just, the general idea, and you're good if you stick to this, if you can do it in CSS, do it in CSS. There's no reason to have all these redundant tags that you're using instead. And kind of, the general consensus is there's kind of five main features that are the cool ones that everyone wants to use and then a bunch of boring stuff that people hear, you're probably like, oh, that's cool, it makes developing so much easier, but Joe Sixpack isn't really gonna care if you can embed data in your HTML better. But that's not fun. I wanna have cool demos that I can click on stuff. So Canvas is a big one, and I'm gonna go over these in more depth, so I'm just kind of covering them here. Video, web sockets are really sweet. Web workers and web storage. There's one more that I think is really cool. It's called Microdata, and I'll cover it at the end, but it's not really average consumer interesting. So getting started, traditionally, if you've had to write HTML, you're developing a website, you've had to write something like this, and I don't know about you guys, but I have to go look that up every time. It's a major pain in the ass. I have to be like, well, is it dog type XHTML? Because I'm doing XHTML, but no, it's HTML, and yeah, that's a mess. So this is probably the coolest feature. Why you should switch to HTML5? Drop everything, it's just that. Dog type HTML. And if you're doing Hamill, it's just exclamation three times, and then a five. Even simpler, so make life easier. Switch to HTML5, there you go. And as I said, browsers are backwards compatible, so if you do HTML5 stuff, and a good example is the forms, there's different form tags and attributes, and the browser doesn't understand it. Most of the time, it will just ignore and treat it as if it's plain text and some element that it doesn't understand, and it won't blow up. So there's no reason not to be using a lot of this HTML5 stuff, other than you're just lazy. And one thing to note is that you can't detect HTML5 support. You can kinda cheat, and if your user's running IE6, it's not gonna support anything. So, you know, fall back to Flash or whatever you're doing. But if you're on a real browser like Chrome or Safari or something, you can detect it. There's ModernizerJS that is a wrapper that makes it a lot easier. And as you can see by that code example, all you do is modernizer.canvas, and that checks to see if you have canvas support, or video, or web sockets, or whatever the feature is that you're gonna implement. You can also, if you don't wanna include an extra JavaScript library, you can call attributes on that, you know, on the canvas tag or whatnot, and it won't return anything, and then you know they don't support it. But it's a small file and it supports a whole lot of HTML5 and CSS3 stuff, and so you can just detect and see if you can support it. So one cool thing I like is HTML structure. So this is kind of how you would do it before. In HTML4, whatnot, you'd have all your divs, and of course you're not doing tables, so don't worry about that. But so you have all your divs, and you just put an IV on them, and then you go right up CSS to float stuff, certain directions and stuff like that. Well, so in HTML5, they kind of thought about it, and they're like, well everyone seems to have, this is 99% of the websites out there, of some sort of layout like that. You might put your sidebar on the right or on the left, but chances are if I go look at your website, it's gonna look like that. So HTML5, they kind of just reduce that, and they have new structure tags that, so you have a header, you have a nav, and you have articles, you have a footer, and a site. So they really make that a lot simpler and easier to use. So that's another cool feature of HTML5. So video, video, if you've gone to YouTube or Vimeo, a lot of these bigger sites are starting to upgrade, if they haven't upgraded all their content to HTML5. Now it requires some re-encoding from Flash and stuff like that, so it's gonna take awhile if you're a site the size of YouTube or something, but chances are you've already seen it, and really as a user, you don't see a difference other than you can actually use HTML5 video on devices like Android and iPhone and stuff like that. So it's one of the few features that is more or less implemented across the board. Now the tag is, but the problem that you're gonna run into is video codecs and audio codecs. Some work on some browsers, some work on others, some certain OSs and stuff like that. And then as developers, or as the company, some of them you have to pay money for, and some of them are free. So that kind of leads into the next bullet point, which is choices. Everyone loves choices, choices are good, vanilla or chocolate, but in this case, choices just means major pain in the ass because you have to support different browsers and there's no one standard codec that works across everything yet. So if Microsoft and Apple would support AUG video, then there would be, and there'd be a free alternative. Right now, kind of your best bet is H.264 and AVI. So containers and codecs, just to clear something up. When you go and you download a video from iTunes or your favorite non-itunes Swedish site that when you download that AVI or MKV or whatever format it's in, that's not the actual video file, that's just a container. And at the very basic, you have a video track that doesn't have audio, and then you have at least one audio track that doesn't have video, and they do, there's stuff in the containers that lets them sync it up and all that. I'm not gonna cover that, you can go research that. But that's one thing to be aware of. And so you have a bunch of, you have several kind of major containers out there and some codecs. Flash is the top one, everyone's seeing Flash, AVI, MP4, AVI's a little rare, it's open source. If you're a fan of Stalman, you'll love it. It saves your babies. You don't sell your sold in Microsoft or Apple or anything like that. It's not as performant as, Theore's not as performant as something like H.264, which you pay out the ass in licensing and stuff like that. But it's free and it makes ponies smile. And then there's Google's alternative, which is WebAM. There are patents on it, so that could potentially be an issue. Google's promised not to do evil and not to sue anyone. So we'll see how that works out. But it is an alternative, they use Forbis for the audio. So part of it's free, and really the only potential issue is VPA. And I've already mentioned H.264, it's got patents. There's, if you just create a website and you wanna put pictures of your cat and you encode it in H.264 and you just have that video. Theoretically, they can come after you and make you pay money based on the number. There's a tiered system based on how many views and stuff you have like that, but they can make you pay money to use that. The governing body for that has said, we're not gonna charge anyone or charge kind of just developers and sites and stuff, a fee until I believe 2013. So theoretically, you can get away with it, but it's one of those things, they're like drug dealers that get you addicted and then you're stuck with it. And let's say you make the next YouTube, you don't really wanna convert terabytes, if not petabytes of data to some new format because that's gonna take forever. So that's the one thing to keep in mind. Excuse me. So Canvas, Canvas is a cool thing. Very basic idea is it's a rectangle that is invisible. You can't tell the difference between a page with a canvas on it and a blank page that you can use JavaScript to draw on it and really you can do anything on it that you want. You get a multiple in one page because each one has its own state. So that's good to know. So you can put tons of different canvases on a page. Everything in it's 2D. If you wanna do 3D, I believe WebGL is the way to go and there's a guy speaking on it today so you're in luck, I'm not gonna cover that. So 3D is not part of the standard. They acknowledge that someone may wanna do 3D because it's one of those new up and coming technologies but it's not in the standard. And everything on Canvas, it's a 2D grid and you start in top left corner at zero, zero. Kind of basic stuff. You can do a lot of stuff on it. Like I said, you can just draw text on there. You can do gradients, images, video and even kind of a poor man's green screening type thing. There's a cool demo out there that Mozilla's done where they have a video tag on one side and it's just this guy talking at a conference or something and there's a greenish screen behind him and then they have two Canvas elements on. The first Canvas, they just draw the video on there and you're kind of like, well, that's boring. I have a video tag to play video. Why do I need Canvas? But on the second Canvas, what they're doing is on every frame they're figuring out where the green is and they're replacing it with the Mozilla logo. So essentially they're doing some sort of basic watermarking type stuff and so that's a cool feature. You can draw on your video and kind of layer stuff. One thing to remember is if you are doing watermarking or something, it is JavaScript. Users could disable it and then be like, oh, I never saw that. I didn't know I couldn't take that. Was it free? It's on the internet, of course. So it's one thing to keep in mind. So next cool feature is web storage and traditionally if you wanted to do something like this and you wanted to persist your saved data on the client between page loads, you have to do something like cookies. And cookies, everyone has probably used them and hates them. And cookies really suck if you think about it. The first biggest problem, it's only 4K. We all live in this post-spill gates world where he said 640K was the most anyone's ever gonna need. So where's my other 636K? And so your waste, since it goes back and forth every request, you're wasting all this bandwidth that probably isn't a big deal now that everyone has three megs or five megs or if you're in a real country like Japan, 50 or 1,000 or a gajillion, but you have these real connections. And so that's probably not an issue. But one thing that is encryption and unless you encrypt your entire site, chances are your cookies aren't encrypted. So one thing to think about, stop and think about it is client storage, why not use that? Then you don't have to send data back and forth every time you wanna request something. And it's on there. They can worry about storage and all that. So that's where web storage comes in. And there's two parts to it. There's local storage, which is per domain and it persists after browser closes. So it's kinda cookie-like cookies. A good example for this would be if you wanted to have a, or remember me, login type thing, you put it in the local storage, it saves it when they come back, they're automatically logged in. Session storage would be something like if you're writing bank software where you don't want your users logged in because there's kind of that assumption that if you go to your bank website and you close your browser that you're no longer gonna be logged in because you don't want the next person to come along and be like, oh, I can see he has $20 in his account. I'm gonna go take that. So that's where you would use something like session storage, which is per page window and for the lifetime of the window. It also lets you do, because it's that way, it lets you run multiple instances of the same application side by side. And this is actually one area where Internet Explorer has actually done something first. They have a feature called user data that was implemented starting version like five or six or something. So back in the day. And it's not the same thing. It's not part of the standard, but it's similar. So if you do need to do web storage type stuff back on an older IE, you can kind of hack this way and give it a shot. So web workers are another cool thing. It's easy to think of them just as background Java script or threads. You go and you create a script and you create a new web worker. That web worker will then spin up that script and then do stuff in the background. One caveat to know is that you don't have access to the DOM in that script. So you're kind of thinking, well, how do you do it? You do messaging. Everything's done the messaging. You send messages to it. If you want to send a new data, you send messages back if you want to do, if you want to write something to the page or something like that. And no access to the parent page. So yeah, be careful. So here's some code. Here's a code example of a worker. You're creating a new worker, as I said, and you just load up the Java scripts. That's simple. And then you create on the worker and since you create an on message handler. So when that script messages you back, you can then do something. So if you want to print it out or alert or whatever, you have that. And then if you want to tell, okay, here's some new data. Here's some new work. You can then post a message. And one cool thing is that you can just send whole objects over and it will handle the serialization of JSON all by itself and you'll have to worry about that. So next up is web sockets. Web sockets, the code looks pretty similar. But the basic idea is it's client, server, TCP sockets. So you fire up on your web app. You open up a socket connection to the server and then it's bidirectional so then you can just keep sending data from the server and you don't have to sit there and refresh. And there's other solutions out there like Comet and stuff like that. But one thing that web sockets tries to do is it tries to account for proxies and firewalls that solutions like Comet can do but they sometimes fail on longer data transfers and streaming and stuff like that. And web sockets are really like dirt simple. They're easy to do. And on this code example, this is all you have to do. The same idea as the web worker, you create a new web socket, you pass it a site and that's kind of where the data goes. You can do WS for regular HTTP and you can do WSS for encrypted stuff and then you just have your own message call back and all that. And here's some Ruby code. This is a really simple example. It's the only Ruby code in my presentation so enjoy. But all this is doing is you're handling different events. You're handling on open and on close. You're adding the socket, you're deleting that socket and then you're handling on message and all that does is a message comes in and it goes over each of the sockets and it sends it out. So one of my friends did a cool blog post on it and he has a website where you just go there and you start mashing keys and then you have a whole list of keys A through Z and they all start lighting up. And so then if someone else comes to that website at the same time it starts mashing keys then you'll see each other's key presses and it's kind of cool. And this is all you have to do. It's using Event Machine and Event Machine WebSocket. They're both gems, they're both downloadable so go get them. So offline web applications. So your web app is obviously so cool you wanna be able to use it offline. One problem with this is you're still gonna run it with issues with, you obviously can't pull data from the web wherever your server's located if you don't have an internet connection but this allows you to still be able to use that application in some sort of limited fashion and what we're using it for or what we're planning on using it for is on the metal software we're writing we have nurses and doctors and stuff have to be able to schedule patients, kind of standard stuff. And so if their, let's say their backup server goes down and our main server goes down and their internet's down and someone kicks a puppy out front they can still get online or they can still use the application in a very, it's very limited but it's still usable. So they can still schedule patients and they can still see any data they have and use it. And so when they come back online and that puppy's saved and everything's all good then all they have to, all it does is it sends the data back and tries to figure it out and if there's any like scheduling conflicts like let's say they're two patients scheduled for the same time someone hasn't manually deal with it but if there's no conflicts then you can just write a whole bunch of data to the database and be good. So there's some cool stuff on this there's a client-side SQL database not everyone supports it you stuck with real browsers for now and then you do some caching using, so what you do is you set up a cached manifest file it's just a plain text file and you set up a fallback page let's say they didn't cache something that they needed and then you set up the items, assets you want to cache and then in your HTML all you do is add manifest and you just have to, if you have multiple pages like let's say you're just doing plain HTML you'll have to put this on every page but obviously if you have some sort of application layout master page or whatever depending on your technology you just have to set it once and then it's cached, so it's easy client-side SQL, if anyone's done JDBC or ADO.NET type stuff it's really similar to that it's no active record but you just create you open a database first parameter is the name and then the version and then a description and then the last parameter there is kind of interesting it's an estimated size of the database by default you can get up to five megs without prompting the user if you want to get more than that you can request more space and then the user has to approve it if they don't approve it you're kind of screwed and you're stuck with five megs if they just click yes on everything and they hit yes then you can get almost as much data as you need and then underneath that is an example insert just regular SQL that we all know and love and we've written a hundred times and really wish that we could use active record or link or something like that but it gets the job done and then pulling data you just do a query from your table and then you iterate over the results and do whatever so that's client-side SQL next up is geolocation this is another thing that requires user approval and you don't have any access to user data without their permission and I think that's a really good thing keeps users safe from malicious users of course no one here is going to but there are people out there it's not technically part of HTML5 it's kind of its own thing and a lot of mobile devices kind of legacy platforms that don't support HTML5 like BlackBerry or Nokia or Windows Mobile they all have their own versions so that's one thing to be aware of that you can still do geolocation it's just not as pretty and there are some rappers for that it's often like I said and users have to approve it and it's non-blocking so if you write your application you have to set up a callback so when the user, if they say yes I want to allow you to get my information and raw me blind that you then have, so then you can do it if not, you can re-prompt the user but that's not very nice and if the user says no, no means no and it's Earth-centric so if you want to make a cool app that's on Mars or the moon or something you're out of luck go find something else and one thing to keep in mind is cells versus laptops laptops, when I was looking up examples and writing code and stuff like that it pretty much would get within on a good day it would get the actual street I live on whether in front of the house or back of the house it was kind of like whatever it's called enough but on cell phones a lot of cells have dedicated GPS equipment and that will give you that accurate couple meters or whatever of their location that's using more hardware it's not nice to just start using random parts of hardware on someone's phone because it's going to suck battery life so you can do cell triangulation and that can be anywhere between that couple meters accurate to kilometer or whatnot so that's something to be aware of and if anyone in here uses the iPhone that's actually how Apple or Google does it on Google Maps they start up with triangulation to kind of just be like well you're in Utah and then if you're like well I really want directions to the grocery store so then while it's trying to find a signal and working through that it's using triangulation once they have that signal then it gives you your location and then it's accurate and you can do turn by turn stuff if the weather permits and all that and as I said legacy platforms you can use GeoJS that's kind of a wrapper for all of those it makes life a lot easier instead of having to target individual platforms that two users are going to be using no key advice or something like that so Forms got a lot of love in HTML5 and really the biggest thing are the new types for inputs and so really you just do same thing input types equals whatever and so I have some examples here there's range, number, date you can't, I don't know if the people in the back can really see that but the second one is just has a spinner and so you can just keep going up and down on your numbers you can set the range between one and 10 and how much it goes up and down by but one thing to remember to keep in mind is that you may have different implementations and date is a good example of that the one on the left is Chrome Safari and that just is a date, a string and then you go up and down and it's kind of a pain in the butt and it defaults to something like 1583 some year that if someone says they're born and they're probably lying and they're just trying to get on porn or something so the one on the right is actually it isn't a jQuery plugin it's opera's implementation of that same date type and so that's something to keep in mind there's other types like email, URL, telephone, date time and even a color picker no one's implemented the color picker yet so there's no real demo for that but if you've ever wondered how is Apple so smart when they go on my iPhone and they know which keyboard to give me do I want to target a phone number do I want to target a URL, email address, kind of what they're really not that smart Steve Jobs is pretty cool but he's not that cool so all they're doing is they're using HTML5 stuff for the most part and they're just, if you have an email if your type is email then they're gonna give you an email prompt or if it's a tel number they'll give you numbers and another thing that they're working on and it's not really implemented outside of opera is validations so I bet if I asked for a show of hands of who's done an email validation almost everyone would raise their hand and then I would tell you that you've done it wrong and that you're an idiot and not to be a jerk but really there's a lot of email addresses out there that are valid that you know Gmail's a good example if let's say you have hunkylover at gmail.com and you want to do hunkylover plus your spam site that will tell you it lets you filter out your email addresses and you can tell if they then sell that email address who they sold it to and so it lets you track down who's not legitimate and who's not honoring their license agreement and all that but a lot of websites they see that plus sign and they're like but that's not a valid email address why is that there and so I've tried doing that with my emails and you know it's kind of a crapshoot you know 50-50 shot whether they're gonna allow it or whether they're not gonna allow it and it's a pain in the butt so it'd be nice if you can have your validations on this email or on the browser I'm sorry and then you just don't have to worry about it you're just like make sure it's a valid email address or a valid phone number and then I don't worry about it and just life is good and then you aren't an idiot anymore also another thing is like phone numbers you know we're used to a 10-digit phone number and that's kind of it but I have a friend who's Russian and her phone number is I think 11 digits and so that's a pain in the butt and then within Russia they have different lengths for cell numbers or you know landlines and stuff like that so really that's something that you don't wanna be handling cause chances are you'll do it wrong and chances are even if you do it right for one case like let's say you can get American numbers right but you wanna go open your application in another country you might be doing it wrong it's something that honestly most people don't know and most people don't care so just let the browser do it when it's implemented right now as I said Opera only is the only one that I've seen that does validations there's also placeholders which are pretty cool there's jQuery plugins that do stuff like this now and it's kind of just that great text that you see in the input box that when you click in there it disappears that's a placeholder that's part of HTML5 that's pretty well implemented across the board and there's also autofocus if you're doing any JavaScript code this is another part where I'm gonna call you an idiot if you're doing anything on load in terms of setting up autofocus or something like that you don't wanna be doing that you wanna be doing something like document ready and jQuery cause on load waits for everything to load so you're waiting for your images to download and it's kind of a pain in the butt and it makes your application look like a piece of junk because you go and then your cursor's moving around and you're kind of like well I don't want that too so yeah that's forms forms got a lot of love there's some more to it but those are kind of the cool features that or hit and miss in terms of implementation but if you know you can target a specific browser you can really go look see what's implemented right now in this version and go just start using that so the last thing we're gonna talk about is microdata and this kind of what I think is the coolest feature that no one really knows about and no one really cares about because it allows you to get better Google results and kind of like well okay and so that's why normal people don't really care you get item value pairs and it introduces five global attributes into your elements so you get item ID, item prop, item ref, item scope and item type this will make more sense when I show an example and as I said better search results so here's an example of using microdata and this sets up it's kind of like XML-ish in the sense that you have a schema and all that but you just set up and this is a real one you can go to datavocabulary.org Google runs it they've got some other predefined types like person and I think client and stuff like that and all you do is you set up all this data so you know you have an address you know you have a street address you have a locality, a region postal code in the country it's kind of the default ones and so you're kind of like well okay so that just makes more code why do I really care well so what Google will do is that when they're this is what Google will show you that it sees you know so it on some level it allows better transparency into the work things like Google what they scrape, what they see and if you ever get a result that you know you're like wow that gives me a lot more information and then you know just whatever is written down on the bottom that they just randomly grabbed and you're trying to figure out what's it about and you're like well I can get the address or something right on Google and this is because they've done something like this and that they can scrape it so if you're interested in this there's the rich snippets program which Google has there's a lot more information on that and right now no browser supports extracting data from it I mean you can still do just regular jQuery or something like that to grab data out of those spans but in terms of you know browser specific APIs or something like that there's no support for it so it's kind of this is really the bleeding edge of HTML5 you know when stuff like Canvas is kind of just you know old and boring at this point so yeah that's micro data that's cool I haven't used it I've kind of starting to consider it for some of our projects but I thought I'd mention it and kind of you know show you guys so that you can go play with it and hopefully if more people start using it pick up traction and browsers are implementing it so yeah that's the end of my talk here's some more info W3 is a good resource if you like dry and boring stuff you just go read the standard I think it was Mountain West someone said you know I read the standard it's only 5,000 pages or 5 billion pages or whatever you know everyone should do it I'm not going to recommend that but you know when I was preparing this talk it was really useful and it is really like a good resource if you need it if you want to go target one specific feature or something you know there's a lot of people out there like oh HTML5 it's so cool here's a Canvas demo where here's you know or Geolocation's a good example they just throw up a oh click you know click allow oh we're going to you know plot you on Google Maps and like okay I've seen that a couple thousand times but that's cool so yeah that's it thanks for listening does anyone have any questions yeah I don't I haven't used it yet it's one thing we're looking at using and really it seems to tie into the offline web application kind of fall back stuff or keeping users logged in or saving data between requests there's a couple examples out there where someone just has a a page and they're like oh look at you can type something into the form oh an auto fill is another thing that I didn't mention but you can set up an auto fill element and then you just type stuff in there and then you just set the JavaScript to automatically save that so then if you refresh the page you know whatever you wrote or in piece or whatever is right there and you don't lose it so yeah you do it in local news so if anyone didn't hear he said that he thinks there's a JavaScript library out there that will help you do the syncing from when they're offline to when they're online and that makes sense I haven't really dived into that much because we aren't starting to use it yet but that's good to know okay so he's asking is there any sort of way to know if your your app's offline or you know or and how do you determine if you should how heavily you should rely on the local data store and stuff like that so what the way I was kind of thinking that we were going to implement it is that we're going to just do everything through the local data store because we have a lot of long-running stuff we have to do patient registration we have to do integration with insurance companies and so we're hitting external stuff so we're all in a sense we're using it like a message queue type system like a rabbit or whatnot um and so I I'm not 100% sure if there is a way to check if you're offline I'm assuming there is um if not you could always just try to pull just have some sort of asset on the server that isn't cash that you just try pulling down if you can't get it then you're like oh crap I'm offline um so that's kind of my thoughts anyone else uh just yours so all right oh hunky lover that's uh that's obviously me that's my alter ego uh when I'm not writing ruby code I'm you know scoring with chicks it's hunky lover so yeah if anyone here is single it's a good thing to know you know just come up with some cool handle and like hey baby I write ruby um I know your last boyfriend wrote java or something I'm not that square so all right