The Outliers of HTML5
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Sharp, Remy
HTML5 isn't just video and canvas! There's a lot of clever related technology tucked away inside the mass of JavaScript specifications that aren't quite as sexy as a web socket making love to a canvas - but without a doubt, still useful and important to building web applications.This session will introduce you to some of those outliers, show you how they can be used and prepare you for making the most of what the browsers today can offer you.
 Can everyone hear me? Yeah you can. Cool. A couple people coming. Still. Chop chop grab a seat. Show's starting. Okay thanks for coming. I appreciate it is 20 to 6. I was almost falling asleep before my talk. So if I do see some people nodding off I don't blame you. I also don't blame you if you hear kind of the tinking of bit outside and you start sprinting for it. Just promise to leave me some. So thank you for coming. I've seen talks given later on before and it tends to be really thin out. So yeah like I said thank you for coming. So this talk is supposed to be not just the classic HTML5 talks. Not classic talks but I don't want to talk about Canvas, I don't want to talk about video which are kind of the headline things in HTML5. I wanted to talk about some of the other bits of technology that kind of fall in the umbrella of HTML5. So my plan for this talk is to try and show you some parts of this umbrella term of HTML5 that you can go and use today, add to your websites and give your users better experiences because we can make better use of the technology that's in browsers today. I want to show you some technologies which I think are kind of around the corner. They are in browsers today but maybe not as well supported across different browsers. And then towards the end of the talk I want to show you some of the new technology that I'm starting to see landing in the kind of the nightly build of browsers. Show you which, well, the direction I'm interested in seeing browsers going and kind of almost see the web as a platform being able to provide users full applications. So I'm really interested in using the web, a web technology to build applications and to give you some kind of context, I'm going to kind of reverse back a few years. So back, crikey, kind of the mid-90s I had a modem, a 9K modem, this isn't my modem at the time. And my dad had a scion, just a show of hands, who knows what a scion is or even remembers a scion, kind of five of you, palm pilots, like really old looking iPhones basically with just one color like black and not black. So he had the scion and I wanted to build a game for it. It was an original game but I knew the pieces I wanted to build and I was a kid so I had a spectrum and I kind of wrote games for that. I figured I could write some code for the scion and apparently you could download the SDK for the scion, which is great. So I fired up my modem and I went to the scion download place. I didn't even think that it wasn't a website, it was just bulletin boards. And I kicked off the download, waited two days because it was huge. And had this SDK. And I was a kid at the time, I must have been 13 sort of thing. I have no idea what to do with an SDK age 13. It's just this big, long, massive files with long strings and the documentation was equally as difficult for me to understand. And I'm a lazy developer generally and I think developers should be a little bit lazy, they should optimize their workflow. I wasn't going to read this big spec and I had other things to do at age 13. So I kind of gave up. In fact, I didn't give up completely. I ended up trying out Visual Basic years and years ago. I don't know if it's much different now. Does it still exist? Visual Basic? Yeah? Yeah? Okay, sorry. So I tried out Visual Basic and I make these little programs. Maybe not the game I was going for but it didn't work on the scion but it worked on my Windows machine and I ended up with this kind of 8 megabyte file that wouldn't fit onto my 720 floppy disk and I certainly couldn't give it to my friends. There were no distribution methods. So I really kind of gave up at that point. And for me, I wanted to build an application. I had the desire to make things because I'm inside, I'm a hacker. I see something and I want to break it down into its pieces and I want to break it apart and put it back together again and make something new and make something for me. It shouldn't be such a ballache on computers. Now come 97 time when I was a little bit thinner, not much. I went off to university and we didn't have internet in every room in the university. I had to buy machines. I bought a 286 from a PC fair and the 286 had Windows 3.1 I think on it. And I went out, bought a magazine, got internet explorer which that's the way that you get your software from a CD on the front of a magazine or a floppy disk probably at the time. And discovered that I could open up Notepad and write web pages or write a bit of HTML and something would appear on the page. The cost for me to do that was extremely low. Not the monetary cost but the cost of learning. There was a few characters on the page. I didn't catch the talk earlier but hopefully if anyone did, you can see HTML is pretty simple, right? When I discovered JavaScript or JScript which was the engine in IE3 I think I was looking at, I discovered JavaScript in the machine. And actually I then went on to discover this thing called Windows shell scripting host or Windows shell scripting host. Basically meant I could write a bit of JavaScript or what I knew was JavaScript that would tell the operating system to do something and I could write little applications. And I discovered also that I could change.html to.hta and I would have a little icon on my desktop. I could double click on it. I had an application. And I managed to write myself a little application that would every time the computer started up, it would fire up my.hta automatically. My.hta would read a directory of images and set my wallpaper. So in just HTML and JavaScript and probably a lot of font tags at the time, I made a little application that would just change my desktop wallpaper. I made my first application at that point. That was 15 years ago or so. 15 years later, we have all this amazing web technology but we're not quite there to building a little icon on our desktop, double click and create an app. That's where I want to get to personally. I like building apps. I want to make a little app that can give to someone that solves a problem and they can just run it. But it's web technology. So this is kind of my path to that amazing app that can change my desktop image in 2012. And I'm going to touch on some of the technology that we have available today and tomorrow and the days after that can work our way through ticking these items. So the first one is data storage. Applications need to be able to store some kind of data. Be it application state, maybe it's actually the content for your application. Gmail for instance, stores or you email locally to your phone. So we have data storage in web browsers today. Real-time notifications. Now that's not just web sockets which is a sexy part of HTML5 air quotes because it's not really HTML5. But also push notifications. So when that tab is blurred out of focus, you want it to notify you that something has happened. Maybe you're on your phone. If you have an iPhone or an Android, you'll know that it will probably all phones now. It'll give you a notification that's a new mention on Twitter about you or you have a new email or something like that. I want this technology should be available to us in the web. Access to hardware, this is a huge thing at the moment. Being able to get hold of all these device APIs. I saw a demo yesterday a couple of days ago. Paul Roget of Mozilla showing a demo of what Firefox can do. It's got access to the battery API and the vibrate API and the proximity API. So it knows when you're near to the phone or far away. To your face basically. We want access to hardware. I'm going to show you some of those as well. I want to be able to have a local install of an application. The application cache, the app cache, part of HTML5, that's kind of getting us towards being able to install applications offline. They're not really installed. What we have is a way of accessing it, accessing kind of cached files. Install also means giving rights to do certain things like file I.O. Or being able to store up to 500 megs worth of data. Or being able to capture photos or capture your location and so on. Finally, I want to go fully naked. I don't mean I'm going to strip or anything. I mean to shed away the actual Chrome of the browser. I think it's Windows 8, IE 10 kind of has this full screen, Chrome-less appearance where the web page is full screen. I don't quite mean that. I mean, you don't know if you're looking at a compiled application or a web application. It shouldn't matter to the user as well. It only matters to us as developers. In the technology that I'm going to touch on, this is a really good resource. Hopefully some of you go back on Monday and you hopefully might be able to apply some of this technology that I talk about. Maybe there's some other technology that you're interested in looking at. A nice quick way of getting an idea of the support in the browser is by going to can I use and just dropping in that particular technology. Like rounder corners or maybe Web of Sockets or maybe Web Storage or Web of School Databases and so on. This is a good resource to get an idea of what the state of support is. It's obviously not the perfect, it's not the final answer, but it gives you an idea of mobile and desktop. I want to begin with stuff that we can do today. I was at a loss for what image to use so I figured a unicorn shitting a rainbow would be good for this. Progressive enhancement is good. The important part of progressive enhancement means if you do have like 20% of your users are IE6 or 7, the application still works for them. We're talking about the people that have the newer browsers and can make use of this newer technology. This is not edge or clever. Hopefully you're doing this already. Doc type, HTML. Versionless HTML, doc type. This will give you HTML5 bonus points with your tech guys. Just change your doc type. You don't need XHTML. You're not using MathML. The only reason I used XHTML was because X and X's are cool. Jason parsing. Don't be parsing XML. XML. Don't be sending XML data from your server to the client in XML. This is overhead and creating and parsing a DOM. I've come across two recent projects with clients where they're sending XML back up the wire. Jason's native to JavaScript in the client side. Just start using Jason. It has IE8 support natively. You can do JSON.stringify and parse and so on. These are just make sure you're using this stuff because it's available now. Data storage. IE8 and above means every other browser and IE8 and IE9 have web storage, which is a very, very simple API that replaces the need to use cookies. The only one use case for cookies is if you want to share data between the client side and the server side. Otherwise, things like state data, application state, which panels they have open, stuff like that, you can store in web storage. The API is insanely simple. It looks like this. You just do session storage.state equals jason.stringify. If you want to get that back out again, you just do jason.pars session storage.state and you have that real object, that real JavaScript object again. These are setters, getters and deletors. They use the method set item, get item, remove item. Very, very simple to use. Treat it like a JavaScript object that has memory. There's been some recent blog posts about the performance of session storage and local storage in particular. The way that it's been implemented is it's a synchronous API. It means that when you try and get that data out of the local store, it's going to be blocking while it's taking that out, basically off disk, which is kind of a failure in the implementation in the first place. Chris Harmon posted on Mozilla's, hackstop Mozilla, I think, saying that we should stop advocating using local storage because it performs badly. If you are storing a two and a half meg string in local storage, yes, it's going to take quite a while to get out. Think of local storage as a cookie killer. Those little pieces of data that you store in cookies, if you don't need that to go back to the server, replace it with web storage and consider it as a cookie killer. It's much simpler to develop against. The thing I really like about web storage doesn't have much to do with web storage. It has to do with events. As I'm typing, I'm storing the string that I'm actually typing into the browser, and any document on the same document origin, so the same kind of HTTP.jsbin.com, it receives a storage event. That storage event includes the old key, sorry, the old value, the new value, and the key, and I think the origin that triggered the event in the first place. The window in the top left is triggering the storage event on the other three windows, which means that in this API for just storing data, I have a way of synchronizing tabs. This isn't something that most people need immediately, but it's a problem I've encountered over the years that I want to keep some windows in sync with each other. Using storage events is a way of doing that. Like I said, you've got IE support there from the start. Web forms. It's particularly an edgy part of HTML5, and unfortunately, even though it's one of the almost best parts of the specification, it's not very well implemented. It's not that it's badly implemented. It doesn't have very widespread implementation or very widespread support. However, I still recommend using it when you can. This is an email regex, right? I've probably written a few of these in my time, and they probably look like this, right? Which looks okay. Hands up here thinks it's fine. Hands up here spots all the massive errors. That actually looks like this, and this, and this, and this, and this, and that massive thing at the end. That's a valid regex that captures everything, because email addresses can look like this. I would never have written that last regex ever. The double quotes at example.org, I wouldn't have caught that. The zero at A, I wouldn't have caught that either. With client-side validation, you have to do it on the server side as well, right? You have to double up. You have to assume that a user or a hacker can get through your validation. You have to do it on the server side. That's the bottom line. You have to protect your server. Just to input type equals email, you get all that free validation in the browser for the iPhone and Android, and I'm not sure about Windows Phone, but they have assistive keyboards. They see the input type as email, and they modify the keyboard a little bit so that you've got the at symbol and it makes it a little bit easier. You've got input type equals email, input type equals URL, which comes built with the validator's, the validation regex inside of the input field. If you say it's required, when the user hits enter, the browser supports it will say no, that's not a valid email address. If the browser does, then it will send it off to your server, and your server will still do the validation. Make use of free validation. You don't need all that extra JavaScript just for validation, right? JavaScript's a really useful language. Building form validation is mind-numbing, so get rid of all that stuff. Just replace it with input type equals email. If the browser doesn't support it, it just turns into text, gets sent off to your server, and it's all good still. History APIs, it's kind of, it should be, I think it's one of the unsung heroes of HTML5. It's superb. Let me go back, actually, for a second. So 10 years ago or so, I discovered Ajax, and I was like, this is so fucking awesome. I can make these little requests. I didn't really understand it because it was voodoo to me, but it meant I could go and make little requests for little bits of data and plug them into the page, and tabs were great and I could just dump in subpages or I could do username validation, which is really useful. But as I started improving my apps by adding Ajax, I'd break the back button, and I'd start fucking with accessibility because really the content can be accessed, and certainly Google can get there. Even though most of the time I was kind of laughing at the Flash developers going, your applications, the back button doesn't work, does it? And Google can't spider it. I was replicating all of their mistakes. So the history API gives me the solution I've been looking for, to be able to actually update the URL properly to give it a permalink to that content, and GitHub do that beautifully. So as I'm navigating back and forth between this little project of mine, you can see the animation is kind of flying back and forth, which is pretty, but they're just loading a snippet of content into the page. Most importantly, the URL at the top is updating. So if I take that URL and send it to you, the request going off to the server is actually going to pull up that page. That page can be spidered properly. It's a full URL. They're making full use of the history API. To give you an idea of the code, it looks a little bit something, GitHub maybe not so, but this is based on a simple use of the history API. So I've just chucked in a bit of jQuery to do a select, to grab all the links that aren't external. Now this is obviously not perfect. I've just done it as a contrived example. So I'm saying if the link starts with a slash, as in not HTTP, I can assume it's an internal link. When I click on that link, one thing I need to make sure is that if the user has held down the shift key, it's likely they want to pop open a new window, right? But in Twitter as of a few weeks ago, I don't know if they've just changed their update. If you ever kind of expanded a tweet and then try to shift click to open that tweet in a separate window, it wouldn't do anything. It would just open and collapse and just do my knot in. It's because they're not checking to see if any keys are pressed down. So by checking if there's no keys pressed down, then continue and treat this as a JavaScripty request. If there are any keys down, then just ignore it. Don't let JavaScript take over. Let the browser do what it's good at. And then I read out the, well, the targets, the element that fired the event. And I read out the path name, which is the actual URL in the link. And I pass this off to the navigate function. And I pass in an object, says trigger equals true. So it's just a track that this was a, we're going to navigate using JavaScript rather than the user actually navigating themselves. And my navigate function does history.push state. And I give it the data, this object. You can give it any kind of data and when it pops, you'll get that data back. The blank string I'm putting in there is actually the title for the page. I haven't captured the title, so I'm not going to put it in there. And in fact, the implementations I've come across don't really do anything with the title at the moment. So that could change. And then finally I give it URL to navigate to. And the URL in the browser will update and the history will update as well. And that push, this doesn't really make sense, but the push triggers a pop. Right? And if you know anything about pushing and popping, that doesn't make sense. But anyway, if you listen for a pop state event, that means the user is navigated backwards or forwards and we've pushed something into the history stack that triggers a pop. We can read the event state and we can see it was triggered. So we're going to go and load that content via an Ajax request and go off to a server, pull in the little bit of content and drop it into the page. The really nice thing about the history API is its progressive enhancement at its kind of simplest. So we build our non-Jobskit version, we make sure the URL is actually working in the first place. You detect for support, so use a tool like Modernizer or just write your own piece of content. Progressively enhance that page using the history API and push onto the history stack. So winning all round. Okay, so I mentioned WebSockets. WebSockets is in, like I said, in that kind of sexy zone of HTML5 with video and canvas. Event source is kind of like WebSockets kind of ugly brother who turns out to be okay looking in the end. I really like event source because it tends to be something that people haven't really heard of. Event source is a persistent connection to the server. So if you're going to use WebSockets or event source, then you need some, well, I use no on my back end, so I'm using an event-driven server. Apache is not going to do so well when you create lots of persistent connections. I heard yesterday, I think, that IAS is getting a module to make it magic, something like that. I don't know much about IAS, so you'll have to do the research there. But it creates a persistent connection and what happens is events are fired on the server and they are piped up to the browser. So it says something like new price or new headline or, you know, not user join, but some piece of data which is really one way. So I've seen WebSockets being used for things like prices, real-time prices for stocks and shares, but WebSockets are two-way. Ideally that problem is suited better to event source because it's one way, but there are some limitations in event source which I'll touch on. It's a real-only stream which means that it's one way and you can't write back down the other way. The API is mega-simple and I'll show you that as well. In fact, actually, to be fair, on the client side, so is the WebSockets API. The nice thing about it is it's possible to polyfill it using JavaScript. So the polyfill is a piece of code, be it JavaScript or Flash or something that sits between you and your code and your browser which replicates the API if it's not there natively. So, for instance, WebSockets, you can get WebSockets to work in IE6 if you use the Flash polyfill and it replicates the WebSockets API. So your code doesn't change in years to come. You remove it because you dropped IE6 support and you're having a little dance. If you have to support mobile devices that don't have Flash on them, for instance, you can't use WebSockets. So I've used this in a solution where I'm actually trying to create persistent connection to a mobile device and I use JavaScript to polyfill event source and I'll show you a demo of that in a second. A few kind of built-in features of event source is that if the connection drops, it automatically tries to reconnect and you as the server can tell event source how frequently to reconnect. So you can say after 10 seconds or after 30 seconds or whatever, but it will automatically reconnect and the other nice thing is that it will send the last message ID that it saw. So say you're following the blow by blow account of your favorite football game, Norway versus England. I don't follow football so I'm happy to take a piss out of your country's football. So England's winning, right? And you want to follow it, blow by blow on your mobile phone and you lose your connection. And the last message you got was, David Beckham still plays for England? I don't know. Last message is such and such, almost scores a goal, message ID is 20. When you reconnect, it automatically reconnects for you and it says the last message ID that I saw was message 20. The server goes, ah, we're up to 45, so I'll send you messages from 21 up to 45 and you discover that actually Norway doing great. Okay, so you get all those backlog messages. I mean, a server needs to be set up to read that last message ID, but that comes as part of the API, which is nice. You can also trigger other types of messages. So it's kind of like multiplexing off of that one persistent connection. So on one event source, I can trigger a new price event, a new headline event, or a new football score event on that same one connection. It'll just trigger different events. So the limitation in event source right now is that it's bound by the same document origin, whereas WebSockets doesn't have that limitation. The spec has been updated to include core support, so that means your server sends a header that says, yep, I don't mind if you're not on the same domain as me, I'll allow you to connect. But it hasn't been implemented in any of the browsers I've seen so far. Maybe it might be in Canary or something like that, but I haven't seen it implemented. I should say I haven't seen this in IE10. I might be wrong, but in the big kind of sheet of support, I don't remember seeing it in IE10, which is fine because we can still polyfill it. So this is an example of me using event source on an Android phone. So I've got this JS console thing, which is a JavaScript console. I type this and I get a script tag. I'm pasting into my JS bin thing, which has an HTML page with that script tag in. I hit refresh on my mobile phone. It's now talking to my desktop. And all the console logs from my phone echo out on my desktop because I've got this event source persistent connection between my phone and my JS console server. And it also means I can remotely inject JavaScript into my phone as well. So I'm changing the content. I'm going to post and alert into the phone. And because I couldn't use WebSockets, I use a mix of event source and Ajax to make a post to the server and then push that back up the event source stream. So this is the code, like I said, very, very simple. We create a new event source object, which immediately tries to connect to the server. Then when a message comes down, it triggers the onMessage event. If there's no event type, it will trigger the onMessage. And I can also listen for specific types of messages. So I can say add event listener, reload. And I can tell the browser to reload or something or new price, new headline, and so on. So that technology aside, drag and drop for file upload, well, drag and drop with a file API for uploads. So to give you some kind of context, I'm going to show you a video of me using Twitter. And you know when you, well, I assume that you've heard of Twitter and you use it, maybe. You can include photos with tweets, right? So I went to Twitter and I wanted to upload this screenshot. So I click on it and drag it into the tweet. So I've lost the whole tweet at that point, right? The browser's just navigated off to the image that I just gave it, which you kind of look at it and you go, yeah. You know that's obvious, right? If you drop a file into the browser, I'll just show you the file. That shouldn't be the case. We should be able to read that file. So actually there's a little trick in, I think it's Chromand Firefox. If you drop the file on the browse button, you know the time it will browse button on the file upload. If you drop the file on the browse button, it will automatically include it as if you browse to that file. Now the way that Twitter works is that that image there, that's actually sitting on top of the input. So it has opacity and secretly that's the browse button. So if I'm really steady, I can just about drop it onto that time little target and it works the way that I want it to work. I should be able to drag a file into a browser and it should work. I was talking to this marketing guy a few months ago or so and I just asked him, if you have a file on your desktop and you need to send an email and outlook, how do you attach that file? He's like, well I just drag it from the desktop into my mail and hit send. So well, okay, let's say same scenario, you've got a file on your desktop and you want to send that attachment in Gmail. Well I just click file, browse, go to my desktop and find the file and click okay and it sends. But Gmail are the box supports dragging into the browser. It's because it's still newish technology and we don't, you don't see this in lots of websites. The more websites that support allowing you to drag and drop into browsers, the more used users are going to get to that, you know, doing that. They're going to get happy with dragging files into the browser. Now it should be said by PPK that the HM5 drag and drop API is a fucking disaster. It is horrid. Microsoft came up with it and they've come up with good stuff as well, like XHR is pretty cool, InterHM is pretty cool, drag and drop, nasty as hell. And the, you know, the good engineers and the smart people reverse engineered the API and then documented it and it's nasty. But ignoring drag and drop within a browser and actually dragging and dropping text inside of a browser, just dragging and dropping a file outside of a browser into a browser is actually pretty easy. So this is what the code looks like. It's not much. And I'm not doing, all I'm doing is accepting the file at this point. Okay, so I have to do, I have to jump through a couple of hoops here. All I'm saying is my, my, my, my drop target, which is the root element here, I'm using the entire document. But maybe you could just do the tweet or maybe you could just do, you know, an error on the page saying if you drag over or the drag end event fires, then we cancel the event. And that's to tell the browser we're taking control of this action. And then if the drop event fires, so the drop event fires, it calls the drop function which is down here, we cancel that too. And then we go ahead and read the files. And we have to detect support. So we have to, you know, feature detect the support for drag and drop and the file API in the next part that we're going to use. But we've got this event.data transfer.files. And that's all the files the user just dropped into our browser. So the next step here is to add in the file API. And again, you detect support for this. And if none of this works, you still have that file input button that every IE6 user loves, right? So the read file looks like this, okay? So it loops over each of the files and just calls this preview function. And the preview function creates a file reader. It attaches an onload event handler and it reads that file as a data URL. So I'm going to get a base64 data URL for this file. Now, I haven't checked the mind types here. You could be dropping a massive file in here. This code is not complete. This is contrived examples for you guys. I'm assuming that an image is being dropped into the browser. Now at this point, I create a brand new image. Once the onload event fires, brand new image, set the image source to the event.target.result, which is the base64 string. And I drop that image into my preview. So if it were the tweet, you'd see that little image thumbnail come up in the side. Okay? Christ, everything's falling over. So that's not a lot of code and works really well in browsers that support it. And the next last part is automatic uploads. If you use Flickr or Tor, they just recently updated their upload page. So when you do, I want to upload an image, you just drag the files off your desktop, drop them onto the page, and behind the scenes, while you're kind of thinking of nice titles for your picture of your cat in a box, it's quietly uploading the file ready. To be saved. So the traditional method is you select all the files, you hit go, and it takes ages to upload, and then eventually a page comes back and says add your title and description. This you drop your files into the browser, and whilst you're actually typing up the title and description, it's just uploading those files behind the scenes. So that idle, it's making use of the idle time basically. So when you hit post to my photo stream, it's just a really quick refresh because it's already got it up there. It hasn't published it yet, it's held in a queue, but as soon as you hit post to my photo stream, it publishes it, and the whole experience is really slick and very smooth. So this looks like this. So in XHR2, there is a form data object. We're going to create a new form data, and we're going to loop over all the files, and we're going to do form data dot pen, and we're going to pen our file from our drop operation. We've given it a name of file, so on the server side, when we're reading the posted data, it's going to be under the name of file, and you can call it whatever you want. I think create a new XHR object. I'm going to open up a post, so I'm going to post a specific URL, maybe upload image. I can also attach an event listener for the progress of the upload process. So the key here is listening on the XHR.upload property. So there's this upload property. If you're sending up the wire, you can listen to the on progress event. When that fires, it will tell you how far along it is, and actually you're uploading that image, which is really nice for little progress bars, right? And then I just do XHR.send that form data object. It just goes up the wire. I'm not having to tell it what headers to send, so it will automatically see that it's this form data object, which is nice and special, it will encode the file properly for the server to receive and mine types and all that jazz. And it means I can do this. I can select some pictures of my son, drop it into this thing. Now, there's no progress to show it actually rendering the image, but I can do that as well. And here you can see it going up the wire. Now this is slow because it's like 8 meg files. But that's nice to have that feedback, and that's all native in browsers today. And without that, the browser doesn't support that today, the process is exactly the same as what we're used to. Just file, browse, submit is exactly the same process. If you have an input type file, please replace it with that or upgrade it to that. So some of the things that are tomorrow and are available in browsers today, and we can use JavaScript to polyfill some of it, and maybe you're going to build an HTML5 game. This kind of stuff, you're going to be working in the edge browser, things like IE10 and Chrome 20 and Firefox 59 and whatever it is. So one, these two tiny bits of HTML5 I really like, they're kind of tucked away, dataset class list. So I've got a game, which is Space Invaders, and for whatever reason in this version of my game I get this baddie, the big boss baddie. And he's an image element. And there's some data associated with that DOM node in the document. So I've done data-health equals 13 and data-damage equals 5. So if he hits me, the idea is I lose 5 points off my health. So you can see if I got hit, me.health minus equals boss.dataset.damage. I'm not having to get attribute, I just have access to.dataset and everything that starts with the data property on my image is available as a property inside of that dataset. And equally if I set some value, so if I do, you can see boss.dataset.health minus equals 1, that will just automatically update the DOM node as well. It will set the health to 12 and so on and so forth. And I can create new properties by just doing dataset.foo equals bar and the attribute will be there on the DOM. Now if the boss doesn't have any health left, I'm going to do boss.classlist.add dead. Okay, how many jQuery here? Nice thing about this is I can add classes and if the class isn't there, if the class is there, it won't add it because it's already there, right? I can remove classes, I can toggle classes, and I can test if it has a class. So I'm going to date a classlist.has dead and not do anything. And I saw a video that Paul Irish published a week or some recently, recent amount of time, and he was looking at the performance of.classname, so element.classname. If you touch element.classname, if you get it or set it, it's doing a reflow on the document. But if you do element.classlist.add or.remove, it's not, the performance is much, much better. I think it caches it to the end of the operation and then does it all at once, maybe. But actually the performance of that doesn't trigger all these reflows, which is really good. Technically it should, but there's a video that goes with it. I might find the link and post it on Twitter or something, but yeah, it performs much better than just doing.classname. Then it makes me think, is classlist plus query select at all greater than jQuery? So could I use jQuery for really quick DOM manipulation and usually just toggling classes or maybe adding event listeners, which is pretty straightforward as well. Can I replace jQuery in my workflow with just some of these pieces? I've got my own, I call it lame query, which is 18 lines of code, which replace all the event listener model and query select. Oh, I'd like to just have this classlist. If I'm working on, if I know that this only has to work on a specific set of devices or a specific type of browser, I can rely on this technology be here. The classlist can be polyfilled as well, but you need to have access to the element.prototype, which I know is in IE9, but I'm not sure about IE8. It's fine that you can polyfill it, but it depends whether or not you can actually upgrade the element prototype in the first place. Browsers can go full screen now. When Google posted their YouTube slash HTML5 page with the native video element in it, people went crazy. They're like, ah, Flash is dead. People near me went crazy. The thing that was missing was full screen. I use the BBC iPlayer. I put it full screen. I sit at my desktop and just eat my lunch and watch the TV on my laptop. Browsers need to be able to go full screen or video needs to be able to go full screen. If it's really going to replace Flash video. There is now a full screen API, which allows not only video to go full screen, but any DOM node to go full screen. Maybe you're building a game like the Cut the Rope from this morning. It'd be great if you could just go, yep, go full screen. On my Mac, it goes full screen. I get to see the full game and no distraction around the side. The API for this is a little bit fiddly at the moment. It's not that fiddly, but there's the W3C implementation, which is full screen with a lower case S. Then you've got the web prefix version, which has a capital S. You've got the Mozilla prefix version that has a capital S as well. I haven't bothered putting code up because it'd be really long just to be able to do this kind of thing. This is a speaker deck. They've got this little full screen button here, which makes the whole div, or that div, go full screen, now I can go through the slides. Great for video, really good for games, and maybe good for reading. If it's a newspaper website, it'd be great to go distraction mode. Just take that article that I'm reading and go to full screen. I want to include examples for all of these, but I realize I'd probably be rattling on for quite a while. A request animation frame, was it mentioned this morning? It might be mentioned this morning. It's a really good alternative. This is a replacement for using set interval for animations, because it synchronized with the refresh rate. Ideally, it synchronized with the refresh rate of the browser. So it goes at 60 hertz, so 16.6 milliseconds, I think it fires at roughly. It means that your animation is in sync with the screen, which means that it's not constantly competing with processing time in the browser. If you look at the performance metrics of set interval versus request animation frame, you'll see that it's not using as much resource as set interval. Again, Paul Irish has got a polyfill for this, which says if request animation frame isn't there, go look for it under the vendor prefixes. If it's not under the vendor prefixes, go use set interval, which you would use anyway in the first place. WebGL is getting really stable in browsers. I'd love to see WebGL in IE 10. Maybe if there's any Microsoft people here, we can all hassle them to answer whether or not it's going to be in there. They probably won't. But anyway, WebGL is going to give games developers the browser as a platform. Full hardware accelerates, WebGL is hardware accelerated as part of the specification. So it's really, really fast. I think the Angry Birds example that Google posted a year ago, something like that, even though it's all 2D, WebGL is a 2D API. WebGL is being used for the rendering for that. It's faster than if it had been done in Canvas a year ago inside of Chrome. Another thing that's really interesting that's kind of around the corner is Blobs. You can get binary data and having URLs to those Blobs. So when you drop a file into a browser, you can get a Blob URL for that, or you can create things like web workers. You can dynamically create a web worker, which is you just make some JavaScript or put some JavaScript into a Blob. You get a URL for that and you point your web worker to that URL. You dynamically create a piece of JavaScript on the fly inside of the browser. DataList is one of those bits of HTML5 on the side. If you're familiar with Visual Basic, the one thing I do remember are combo boxes. So like a select box and like an input box, like they input box and select made love and made a combo box. So you can type your own value or you can select something from the drop down. HTML5 has this as part of its specification, but not every browser supports it. But Chrome supports it and the browser is starting to support it. So there's these little extra pieces of technology that you should have a look at. Have a skim through the 900 page HTML5 spec if you have loads of time on your hands. So the things that are, I think, quite exciting as well. Things like real time communication, access to the microphone, access to the webcam. It's not that sexy, but it's been something that the open web community have been wanting for ages and Flash have had it in their little pit of flashiness. Being able to point my browser to the webcam, so there's no plug-ins on this page. My browser's opened a stream up to my webcam. That stream is being fed into a video element and that my canvas, a canvas is polling that video element for the frames. I think it's set into one instead of request animation frame, but it's polling the video and as I move the slider back and forth, I'm choosing a hue so I can change the hue in that video in real time. Okay. I was here with Bruce Lawson last year and he showed me Opera Mobile Labs where they were accessing the webcam in the labs version of Opera. I opened up Opera Mobile 12 a few months ago and it was just in there, not the labs version, in the full production version of Opera 12. It has access to the webcam. It doesn't just open up a stream, I can't just go and hijack your webcam and start watching you and doing weird stuff. It asks you, it has a little button in the corner and it asked me if I want to share the webcam with this webpage and similarly it would do with the microphone and other pieces of technology. But it's starting to land in browsers and I mentioned the Firefox demo. They have access to the webcam and the audio streams. The audio stream is, so the audio part of the web real time communications isn't as well supported in the edge browsers as video is. So if you have a play on Monday or whatever the weekend, if you feel up to it, I haven't found the audio to work so well. There are technologies that make the audio work. So there's another technology called the peer connection API which means that we can connect peer to peer. We have to authenticate through an external server. Once we've done that, we've got a connection one to one without the server. So we could be chatting or doing video. And there's an example up on, the Google code has an example of peer to peer audio and video, so just video chat using just HTML5, quote, technologies, basically JavaScript in the browser without any plugins. It kind of leads me to this app that I wanted to build for ages. On my Mac, I have this screen saver that when it kicks in, it listens for ambient sound. So it has these particles flying around. And as it hears noise, it kind of makes them explode in a little kind of like noisy happiness explosion thing. But I can see all the parts that are required to make this using open web technology. This is the web real time communication API accessing the microphone on my laptop. So I open up a stream to my microphone on a laptop and I take that feed of audio. I then pass that audio feed into the web audio or the audio data API, which allows me to actually go into the data and visualize that data. So I need to write this code. I mean, it doesn't come out of the box, but I can visualize that data. I'd use WebGL to do the particles and the 3D kind of effects and then use the audio data to make it kind of explode. And then I use a full screen API to make it all big. And then I just make that my, I could make that my home screen on my browser because I've always got my browser open. I open it up and it's there kind of listening to sound and doing funky stuff. So if anyone wants to build that over the weekend, semi-tweet, I'd love to have it. I did ask a bunch of other developers and they didn't do it either. So I'm not, I'm not that hopeful. This is the last part that I'm, I'm quite interested in. I'm not quite sure how realistic it is. But there's APIs that are coming or there's technology that's coming now that gives us Chrome. So a Chrome, I mean, we've got this full screen API, right? We can go to full screen now. That's great. I want to get rid of the whole browser. I want to get rid of the whole thing. The user doesn't, with applications, the user doesn't really care if it's, if it's a web browser or if it's some application they're used to opening. So they have this mental model with, or this mental preconceived idea that a browser is, or a website is limited by the edge of the browser. It doesn't go beyond the edge of the browser, which is why that marketing guy wouldn't drag into the browser. He was scared that he would lose his email. I want to get away from this model. I mean, when you look at the app, was it the app store? The app store on the iPhone, you don't look at it and go, oh yeah, there's Safari and those native components because it's a mix, it's a hybrid application. Because it just, it's the, it's the, whether it's design and user experience and all the kind of finesse around the application that makes you not care, that makes you just use it. So I'm not talking about headless, headless application. So there's things like phantom.js, which is a web browser without actually a head at all. I'm not talking about full screen. I'm talking about getting rid of the edge of the browser and maybe also installable. And there was a post on the W3C mailing list. I can't remember which one, but Tim Berners-Lee talking about users wanting installable applications, being able to set permissions and say what, what permissions they're going to give to this application, this web application to be able to store data or to be able to do file I.O. Or to be able to print or we can print already. But you know, those kind of things that have first class access on the desktop or on a mobile phone. Now I mentioned HTAs back in 1997. IE Windows 8 has HTAs, which is awesome. But it's running in IE 7, which is bananas. So that's obviously not a solution. So we can't just change the.html to.hda. Chrome, if you hit the wrench or the spanner, you can go down to tools and do create shortcut. But it's disabled on the Mac. So if you have a PC, a Windows or a Linux, you can actually create a little application for that URL. But it's really well hidden. My mum or my sister aren't going to do this. I might go looking to do this, but they're not going to go through the spanner tools thing. Opera had widgets, and actually they were part of the W3C. And they seemed to me like a pretty good idea. It's a zip file that has an.html file in it, JavaScript file, CSS images, and so on. It has a little XML manifest file. So it kind of has all the attributes of a web app, an installable web app. And when you actually ran them, you could have transparency in your application. It didn't have to be a square box. It could be an odd shape if that's what you're into. But no one really picks it up. And oddly, I think it's partly to do with this word as well, widgets. People don't like widgets. They don't mean anything. And eventually, Opera has dropped its support for Opera widgets. And now they've become Opera extensions. So a lot of the widgets still work, but they're under the extensions inside of Opera, like a Firefox extension. Windows 8, I mean, I'm excited about the fact that the stack is fully accessible from normal web stacks. So I can use JavaScript to access the operating system, which is great. I love the idea that I can just drop a website into Visual Studio and create an application I could put in the store. Obviously, you don't want to do that, but you can. This is getting closer, but it's still bound inside Windows 8 for me. I think this is great. This is a really good step forward, but it is still locked inside of Windows 8. I want to see it working on every platform. Mozilla have a draft for a specification called WebRT. So Windows RT is Windows runtime. WebRT is web runtime. And the idea is, well, this is in Firefox now. If you go to navigator.mosagent.install, you can install a web app into Firefox. And the manifest looks something like this. There's also permissions property that says what access this application is going to get. My only issue with this, or my first issue with this, and the blocker is you can only install from inside of Firefox. Does anyone want to get that? Okay. Yeah, you can only install from inside of Firefox, which means that that idea and that technology is locked inside of Firefox. I want to see this. I want to see.webapp, which will just be a little JSON manifest. The points to the application says what your roles are internal to my application, what permissions I want, whether I want to get, I need 500 megs worth of disk space because this is a photo application. And as the user is installing it and double clicking on it, first time it will say, yeah, I want to allow you to have this much disk space. Have the same security model, same cut all from the security guys that the browser gives you. But I want to be able to pass this.webapp to anyone of you. And if I use Chrome and use IE 10, it doesn't matter. You double click on it and it opens up a web app using either IE 10's render engine or Chrome's render engine or Opera's render engine. This doesn't exist at the moment. This is just me kind of wanting something. But this is kind of where I think we might end up heading. This does not mean you should go and take your websites and wrap them either in Windows 8 applications or the Mozilla web runtime. Just as when Adobe shouldn't be taking their forums and making them the entire website flash, we shouldn't be taking entire websites and just making it an application. Website is a website. It's good for webvenus. If you're going to build an application and wants to feel like an application that suits that platform in the first place. So I've got a thing about native versus web. It's not really native versus web because most of the time nobody really cares or can tell the difference. You can tell the difference when the design is bad and the UX is bad. You don't care, like I said, that the app store is actually Safari. It doesn't bother you. It works. It feels right. It has to look right on each platform. So don't go dropping your entire websites in. So hopefully some of you will take some of these points away and actually add them to your website. The drag and drop one is really easy. So go ahead and do that. For me, the constant comes up when will HTML5 be ready? When can I start using it? It's not about the spec being in recommendation phase or being finished. It's about what technology is implementing, what browser and what you can rely on. CSS 2.1 only went to recommendation end of 2010. It was in draft or long before. It was pre-recommendation long before that. Anyone doing CSS was using 2.1 quite happily and just avoiding the parts that weren't supported. So use the parts of HTML5 that are supported for your application that you know that you can use or progressively enhance and make use of. We as a web community need to demand more of the vendors to get more access to APIs and learn you some JavaScript. Buy some books. I don't think I've finished a whole JavaScript book. So that kind of applies to me. But do actually have a look at what the language can do. He's going for beer. So that's the end of my talk. Thank you for listening. If I think there's like two minutes left, if you want to ask me a question, maybe ask me after everyone's gone. So thank you. Thank you.
 Can everyone hear me?  Yeah you can.  Cool.  A couple people coming.  Still.  Chop chop grab a seat.  Show's starting.  Okay thanks for coming.  I appreciate it is 20 to 6.  I was almost falling asleep before my talk.  So if I do see some people nodding off I don't blame you.  I also don't blame you if you hear kind of the tinking of bit outside and you start sprinting  for it.  Just promise to leave me some.  So thank you for coming.  I've seen talks given later on before and it tends to be really thin out.  So yeah like I said thank you for coming.  So this talk is supposed to be not just the classic HTML5 talks.  Not classic talks but I don't want to talk about Canvas, I don't want to talk about video  which are kind of the headline things in HTML5.  I wanted to talk about some of the other bits of technology that kind of fall in the umbrella  of HTML5.  So my plan for this talk is to try and show you some parts of this umbrella term of HTML5  that you can go and use today, add to your websites and give your users better experiences  because we can make better use of the technology that's in browsers today.  I want to show you some technologies which I think are kind of around the corner.  They are in browsers today but maybe not as well supported across different browsers.  And then towards the end of the talk I want to show you some of the new technology that  I'm starting to see landing in the kind of the nightly build of browsers.  Show you which, well, the direction I'm interested in seeing browsers going and kind of almost  see the web as a platform being able to provide users full applications.  So I'm really interested in using the web, a web technology to build applications and  to give you some kind of context, I'm going to kind of reverse back a few years.  So back, crikey, kind of the mid-90s I had a modem, a 9K modem, this isn't my modem at  the time.  And my dad had a scion, just a show of hands, who knows what a scion is or even remembers  a scion, kind of five of you, palm pilots, like really old looking iPhones basically  with just one color like black and not black.  So he had the scion and I wanted to build a game for it.  It was an original game but I knew the pieces I wanted to build and I was a kid so I had  a spectrum and I kind of wrote games for that.  I figured I could write some code for the scion and apparently you could download the SDK  for the scion, which is great.  So I fired up my modem and I went to the scion download place.  I didn't even think that it wasn't a website, it was just bulletin boards.  And I kicked off the download, waited two days because it was huge.  And had this SDK.  And I was a kid at the time, I must have been 13 sort of thing.  I have no idea what to do with an SDK age 13.  It's just this big, long, massive files with long strings and the documentation was equally  as difficult for me to understand.  And I'm a lazy developer generally and I think developers should be a little bit lazy, they  should optimize their workflow.  I wasn't going to read this big spec and I had other things to do at age 13.  So I kind of gave up.  In fact, I didn't give up completely.  I ended up trying out Visual Basic years and years ago.  I don't know if it's much different now.  Does it still exist?  Visual Basic?  Yeah?  Yeah?  Okay, sorry.  So I tried out Visual Basic and I make these little programs.  Maybe not the game I was going for but it didn't work on the scion but it worked on my Windows  machine and I ended up with this kind of 8 megabyte file that wouldn't fit onto my 720  floppy disk and I certainly couldn't give it to my friends.  There were no distribution methods.  So I really kind of gave up at that point.  And for me, I wanted to build an application.  I had the desire to make things because I'm inside, I'm a hacker.  I see something and I want to break it down into its pieces and I want to break it apart  and put it back together again and make something new and make something for me.  It shouldn't be such a ballache on computers.  Now come 97 time when I was a little bit thinner, not much.  I went off to university and we didn't have internet in every room in the university.  I had to buy machines.  I bought a 286 from a PC fair and the 286 had Windows 3.1 I think on it.  And I went out, bought a magazine, got internet explorer which that's the way that you get  your software from a CD on the front of a magazine or a floppy disk probably at the  time.  And discovered that I could open up Notepad and write web pages or write a bit of HTML  and something would appear on the page.  The cost for me to do that was extremely low.  Not the monetary cost but the cost of learning.  There was a few characters on the page.  I didn't catch the talk earlier but hopefully if anyone did, you can see HTML is pretty  simple, right?  When I discovered JavaScript or JScript which was the engine in IE3 I think I was looking  at, I discovered JavaScript in the machine.  And actually I then went on to discover this thing called Windows shell scripting host  or Windows shell scripting host.  Basically meant I could write a bit of JavaScript or what I knew was JavaScript that would tell  the operating system to do something and I could write little applications.  And I discovered also that I could change.html to.hta and I would have a little icon on  my desktop.  I could double click on it.  I had an application.  And I managed to write myself a little application that would every time the computer started  up, it would fire up my.hta automatically.  My.hta would read a directory of images and set my wallpaper.  So in just HTML and JavaScript and probably a lot of font tags at the time, I made a little  application that would just change my desktop wallpaper.  I made my first application at that point.  That was 15 years ago or so.  15 years later, we have all this amazing web technology but we're not quite there to building  a little icon on our desktop, double click and create an app.  That's where I want to get to personally.  I like building apps.  I want to make a little app that can give to someone that solves a problem and they can  just run it.  But it's web technology.  So this is kind of my path to that amazing app that can change my desktop image in 2012.  And I'm going to touch on some of the technology that we have available today and tomorrow and  the days after that can work our way through ticking these items.  So the first one is data storage.  Applications need to be able to store some kind of data.  Be it application state, maybe it's actually the content for your application.  Gmail for instance, stores or you email locally to your phone.  So we have data storage in web browsers today.  Real-time notifications.  Now that's not just web sockets which is a sexy part of HTML5 air quotes because it's  not really HTML5.  But also push notifications.  So when that tab is blurred out of focus, you want it to notify you that something has  happened.  Maybe you're on your phone.  If you have an iPhone or an Android, you'll know that it will probably all phones now.  It'll give you a notification that's a new mention on Twitter about you or you have a  new email or something like that.  I want this technology should be available to us in the web.  Access to hardware, this is a huge thing at the moment.  Being able to get hold of all these device APIs.  I saw a demo yesterday a couple of days ago.  Paul Roget of Mozilla showing a demo of what Firefox can do.  It's got access to the battery API and the vibrate API and the proximity API.  So it knows when you're near to the phone or far away.  To your face basically.  We want access to hardware.  I'm going to show you some of those as well.  I want to be able to have a local install of an application.  The application cache, the app cache, part of HTML5, that's kind of getting us towards  being able to install applications offline.  They're not really installed.  What we have is a way of accessing it, accessing kind of cached files.  Install also means giving rights to do certain things like file I.O.  Or being able to store up to 500 megs worth of data.  Or being able to capture photos or capture your location and so on.  Finally, I want to go fully naked.  I don't mean I'm going to strip or anything.  I mean to shed away the actual Chrome of the browser.  I think it's Windows 8, IE 10 kind of has this full screen, Chrome-less appearance where  the web page is full screen.  I don't quite mean that.  I mean, you don't know if you're looking at a compiled application or a web application.  It shouldn't matter to the user as well.  It only matters to us as developers.  In the technology that I'm going to touch on, this is a really good resource.  Hopefully some of you go back on Monday and you hopefully might be able to apply some  of this technology that I talk about.  Maybe there's some other technology that you're interested in looking at.  A nice quick way of getting an idea of the support in the browser is by going to can  I use and just dropping in that particular technology.  Like rounder corners or maybe Web of Sockets or maybe Web Storage or Web of School Databases  and so on.  This is a good resource to get an idea of what the state of support is.  It's obviously not the perfect, it's not the final answer, but it gives you an idea of mobile  and desktop.  I want to begin with stuff that we can do today.  I was at a loss for what image to use so I figured a unicorn shitting a rainbow would  be good for this.  Progressive enhancement is good.  The important part of progressive enhancement means if you do have like 20% of your users  are IE6 or 7, the application still works for them.  We're talking about the people that have the newer browsers and can make use of this  newer technology.  This is not edge or clever.  Hopefully you're doing this already.  Doc type, HTML.  Versionless HTML, doc type.  This will give you HTML5 bonus points with your tech guys.  Just change your doc type.  You don't need XHTML.  You're not using MathML.  The only reason I used XHTML was because X and X's are cool.  Jason parsing.  Don't be parsing XML.  XML.  Don't be sending XML data from your server to the client in XML.  This is overhead and creating and parsing a DOM.  I've come across two recent projects with clients where they're sending XML back up  the wire.  Jason's native to JavaScript in the client side.  Just start using Jason.  It has IE8 support natively.  You can do JSON.stringify and parse and so on.  These are just make sure you're using this stuff because it's available now.  Data storage.  IE8 and above means every other browser and IE8 and IE9 have web storage, which is a very,  very simple API that replaces the need to use cookies.  The only one use case for cookies is if you want to share data between the client side  and the server side.  Otherwise, things like state data, application state, which panels they have open, stuff  like that, you can store in web storage.  The API is insanely simple.  It looks like this.  You just do session storage.state equals jason.stringify.  If you want to get that back out again, you just do jason.pars session storage.state and  you have that real object, that real JavaScript object again.  These are setters, getters and deletors.  They use the method set item, get item, remove item.  Very, very simple to use.  Treat it like a JavaScript object that has memory.  There's been some recent blog posts about the performance of session storage and local  storage in particular.  The way that it's been implemented is it's a synchronous API.  It means that when you try and get that data out of the local store, it's going to be blocking  while it's taking that out, basically off disk, which is kind of a failure in the implementation  in the first place.  Chris Harmon posted on Mozilla's, hackstop Mozilla, I think, saying that we should stop  advocating using local storage because it performs badly.  If you are storing a two and a half meg string in local storage, yes, it's going to take  quite a while to get out.  Think of local storage as a cookie killer.  Those little pieces of data that you store in cookies, if you don't need that to go  back to the server, replace it with web storage and consider it as a cookie killer.  It's much simpler to develop against.  The thing I really like about web storage doesn't have much to do with web storage.  It has to do with events.  As I'm typing, I'm storing the string that I'm actually typing into the browser, and  any document on the same document origin, so the same kind of HTTP.jsbin.com, it receives  a storage event.  That storage event includes the old key, sorry, the old value, the new value, and the key,  and I think the origin that triggered the event in the first place.  The window in the top left is triggering the storage event on the other three windows,  which means that in this API for just storing data, I have a way of synchronizing tabs.  This isn't something that most people need immediately, but it's a problem I've encountered  over the years that I want to keep some windows in sync with each other.  Using storage events is a way of doing that.  Like I said, you've got IE support there from the start.  Web forms.  It's particularly an edgy part of HTML5, and unfortunately, even though it's one of the  almost best parts of the specification, it's not very well implemented.  It's not that it's badly implemented.  It doesn't have very widespread implementation or very widespread support.  However, I still recommend using it when you can.  This is an email regex, right?  I've probably written a few of these in my time, and they probably look like this, right?  Which looks okay.  Hands up here thinks it's fine.  Hands up here spots all the massive errors.  That actually looks like this, and this, and this, and this, and this, and that massive  thing at the end.  That's a valid regex that captures everything, because email addresses can look like this.  I would never have written that last regex ever.  The double quotes at example.org, I wouldn't have caught that.  The zero at A, I wouldn't have caught that either.  With client-side validation, you have to do it on the server side as well, right?  You have to double up.  You have to assume that a user or a hacker can get through your validation.  You have to do it on the server side.  That's the bottom line.  You have to protect your server.  Just to input type equals email, you get all that free validation in the browser for the  iPhone and Android, and I'm not sure about Windows Phone, but they have assistive keyboards.  They see the input type as email, and they modify the keyboard a little bit so that you've  got the at symbol and it makes it a little bit easier.  You've got input type equals email, input type equals URL, which comes built with the  validator's, the validation regex inside of the input field.  If you say it's required, when the user hits enter, the browser supports it will say no,  that's not a valid email address.  If the browser does, then it will send it off to your server, and your server will still  do the validation.  Make use of free validation.  You don't need all that extra JavaScript just for validation, right?  JavaScript's a really useful language.  Building form validation is mind-numbing, so get rid of all that stuff.  Just replace it with input type equals email.  If the browser doesn't support it, it just turns into text, gets sent off to your server,  and it's all good still.  History APIs, it's kind of, it should be, I think it's one of the unsung heroes of HTML5.  It's superb.  Let me go back, actually, for a second.  So 10 years ago or so, I discovered Ajax, and I was like, this is so fucking awesome.  I can make these little requests.  I didn't really understand it because it was voodoo to me, but it meant I could go and  make little requests for little bits of data and plug them into the page, and tabs were  great and I could just dump in subpages or I could do username validation, which is really  useful.  But as I started improving my apps by adding Ajax, I'd break the back button, and I'd  start fucking with accessibility because really the content can be accessed, and certainly  Google can get there.  Even though most of the time I was kind of laughing at the Flash developers going, your  applications, the back button doesn't work, does it?  And Google can't spider it.  I was replicating all of their mistakes.  So the history API gives me the solution I've been looking for, to be able to actually update  the URL properly to give it a permalink to that content, and GitHub do that beautifully.  So as I'm navigating back and forth between this little project of mine, you can see the  animation is kind of flying back and forth, which is pretty, but they're just loading  a snippet of content into the page.  Most importantly, the URL at the top is updating.  So if I take that URL and send it to you, the request going off to the server is actually  going to pull up that page.  That page can be spidered properly.  It's a full URL.  They're making full use of the history API.  To give you an idea of the code, it looks a little bit something, GitHub maybe not so,  but this is based on a simple use of the history API.  So I've just chucked in a bit of jQuery to do a select, to grab all the links that aren't  external.  Now this is obviously not perfect.  I've just done it as a contrived example.  So I'm saying if the link starts with a slash, as in not HTTP, I can assume it's an internal  link.  When I click on that link, one thing I need to make sure is that if the user has held  down the shift key, it's likely they want to pop open a new window, right?  But in Twitter as of a few weeks ago, I don't know if they've just changed their update.  If you ever kind of expanded a tweet and then try to shift click to open that tweet in a  separate window, it wouldn't do anything.  It would just open and collapse and just do my knot in.  It's because they're not checking to see if any keys are pressed down.  So by checking if there's no keys pressed down, then continue and treat this as a JavaScripty  request.  If there are any keys down, then just ignore it.  Don't let JavaScript take over.  Let the browser do what it's good at.  And then I read out the, well, the targets, the element that fired the event.  And I read out the path name, which is the actual URL in the link.  And I pass this off to the navigate function.  And I pass in an object, says trigger equals true.  So it's just a track that this was a, we're going to navigate using JavaScript rather  than the user actually navigating themselves.  And my navigate function does history.push state.  And I give it the data, this object.  You can give it any kind of data and when it pops, you'll get that data back.  The blank string I'm putting in there is actually the title for the page.  I haven't captured the title, so I'm not going to put it in there.  And in fact, the implementations I've come across don't really do anything with the title  at the moment.  So that could change.  And then finally I give it URL to navigate to.  And the URL in the browser will update and the history will update as well.  And that push, this doesn't really make sense, but the push triggers a pop.  Right?  And if you know anything about pushing and popping, that doesn't make sense.  But anyway, if you listen for a pop state event, that means the user is navigated backwards  or forwards and we've pushed something into the history stack that triggers a pop.  We can read the event state and we can see it was triggered.  So we're going to go and load that content via an Ajax request and go off to a server,  pull in the little bit of content and drop it into the page.  The really nice thing about the history API is its progressive enhancement at its kind  of simplest.  So we build our non-Jobskit version, we make sure the URL is actually working in the first  place.  You detect for support, so use a tool like Modernizer or just write your own piece of  content.  Progressively enhance that page using the history API and push onto the history stack.  So winning all round.  Okay, so I mentioned WebSockets.  WebSockets is in, like I said, in that kind of sexy zone of HTML5 with video and canvas.  Event source is kind of like WebSockets kind of ugly brother who turns out to be okay looking  in the end.  I really like event source because it tends to be something that people haven't really  heard of.  Event source is a persistent connection to the server.  So if you're going to use WebSockets or event source, then you need some, well, I use no  on my back end, so I'm using an event-driven server.  Apache is not going to do so well when you create lots of persistent connections.  I heard yesterday, I think, that IAS is getting a module to make it magic, something like  that.  I don't know much about IAS, so you'll have to do the research there.  But it creates a persistent connection and what happens is events are fired on the server  and they are piped up to the browser.  So it says something like new price or new headline or, you know, not user join, but  some piece of data which is really one way.  So I've seen WebSockets being used for things like prices, real-time prices for stocks and  shares, but WebSockets are two-way.  Ideally that problem is suited better to event source because it's one way, but there are  some limitations in event source which I'll touch on.  It's a real-only stream which means that it's one way and you can't write back down  the other way.  The API is mega-simple and I'll show you that as well.  In fact, actually, to be fair, on the client side, so is the WebSockets API.  The nice thing about it is it's possible to polyfill it using JavaScript.  So the polyfill is a piece of code, be it JavaScript or Flash or something that sits  between you and your code and your browser which replicates the API if it's not there  natively.  So, for instance, WebSockets, you can get WebSockets to work in IE6 if you use the  Flash polyfill and it replicates the WebSockets API.  So your code doesn't change in years to come.  You remove it because you dropped IE6 support and you're having a little dance.  If you have to support mobile devices that don't have Flash on them, for instance, you  can't use WebSockets.  So I've used this in a solution where I'm actually trying to create persistent connection  to a mobile device and I use JavaScript to polyfill event source and I'll show you a  demo of that in a second.  A few kind of built-in features of event source is that if the connection drops, it automatically  tries to reconnect and you as the server can tell event source how frequently to reconnect.  So you can say after 10 seconds or after 30 seconds or whatever, but it will automatically  reconnect and the other nice thing is that it will send the last message ID that it saw.  So say you're following the blow by blow account of your favorite football game, Norway versus  England.  I don't follow football so I'm happy to take a piss out of your country's football.  So England's winning, right?  And you want to follow it, blow by blow on your mobile phone and you lose your connection.  And the last message you got was, David Beckham still plays for England?  I don't know.  Last message is such and such, almost scores a goal, message ID is 20.  When you reconnect, it automatically reconnects for you and it says the last message ID that  I saw was message 20.  The server goes, ah, we're up to 45, so I'll send you messages from 21 up to 45 and you  discover that actually Norway doing great.  Okay, so you get all those backlog messages.  I mean, a server needs to be set up to read that last message ID, but that comes as part  of the API, which is nice.  You can also trigger other types of messages.  So it's kind of like multiplexing off of that one persistent connection.  So on one event source, I can trigger a new price event, a new headline event, or a new  football score event on that same one connection.  It'll just trigger different events.  So the limitation in event source right now is that it's bound by the same document origin,  whereas WebSockets doesn't have that limitation.  The spec has been updated to include core support, so that means your server sends a header that  says, yep, I don't mind if you're not on the same domain as me, I'll allow you to connect.  But it hasn't been implemented in any of the browsers I've seen so far.  Maybe it might be in Canary or something like that, but I haven't seen it implemented.  I should say I haven't seen this in IE10.  I might be wrong, but in the big kind of sheet of support, I don't remember seeing it in  IE10, which is fine because we can still polyfill it.  So this is an example of me using event source on an Android phone.  So I've got this JS console thing, which is a JavaScript console.  I type this and I get a script tag.  I'm pasting into my JS bin thing, which has an HTML page with that script tag in.  I hit refresh on my mobile phone.  It's now talking to my desktop.  And all the console logs from my phone echo out on my desktop because I've got this event  source persistent connection between my phone and my JS console server.  And it also means I can remotely inject JavaScript into my phone as well.  So I'm changing the content.  I'm going to post and alert into the phone.  And because I couldn't use WebSockets, I use a mix of event source and Ajax to make a post  to the server and then push that back up the event source stream.  So this is the code, like I said, very, very simple.  We create a new event source object, which immediately tries to connect to the server.  Then when a message comes down, it triggers the onMessage event.  If there's no event type, it will trigger the onMessage.  And I can also listen for specific types of messages.  So I can say add event listener, reload.  And I can tell the browser to reload or something or new price, new headline, and so on.  So that technology aside, drag and drop for file upload, well, drag and drop with a file  API for uploads.  So to give you some kind of context, I'm going to show you a video of me using Twitter.  And you know when you, well, I assume that you've heard of Twitter and you use it, maybe.  You can include photos with tweets, right?  So I went to Twitter and I wanted to upload this screenshot.  So I click on it and drag it into the tweet.  So I've lost the whole tweet at that point, right?  The browser's just navigated off to the image that I just gave it, which you kind of look  at it and you go, yeah.  You know that's obvious, right?  If you drop a file into the browser, I'll just show you the file.  That shouldn't be the case.  We should be able to read that file.  So actually there's a little trick in, I think it's Chromand Firefox.  If you drop the file on the browse button, you know the time it will browse button on  the file upload.  If you drop the file on the browse button, it will automatically include it as if you  browse to that file.  Now the way that Twitter works is that that image there, that's actually sitting on top  of the input.  So it has opacity and secretly that's the browse button.  So if I'm really steady, I can just about drop it onto that time little target and it  works the way that I want it to work.  I should be able to drag a file into a browser and it should work.  I was talking to this marketing guy a few months ago or so and I just asked him, if you have  a file on your desktop and you need to send an email and outlook, how do you attach that  file?  He's like, well I just drag it from the desktop into my mail and hit send.  So well, okay, let's say same scenario, you've got a file on your desktop and you want to  send that attachment in Gmail.  Well I just click file, browse, go to my desktop and find the file and click okay and it sends.  But Gmail are the box supports dragging into the browser.  It's because it's still newish technology and we don't, you don't see this in lots of websites.  The more websites that support allowing you to drag and drop into browsers, the more  used users are going to get to that, you know, doing that.  They're going to get happy with dragging files into the browser.  Now it should be said by PPK that the HM5 drag and drop API is a fucking disaster.  It is horrid.  Microsoft came up with it and they've come up with good stuff as well, like XHR is pretty  cool, InterHM is pretty cool, drag and drop, nasty as hell.  And the, you know, the good engineers and the smart people reverse engineered the API and  then documented it and it's nasty.  But ignoring drag and drop within a browser and actually dragging and dropping text inside  of a browser, just dragging and dropping a file outside of a browser into a browser is  actually pretty easy.  So this is what the code looks like.  It's not much.  And I'm not doing, all I'm doing is accepting the file at this point.  Okay, so I have to do, I have to jump through a couple of hoops here.  All I'm saying is my, my, my, my drop target, which is the root element here, I'm using  the entire document.  But maybe you could just do the tweet or maybe you could just do, you know, an error on the  page saying if you drag over or the drag end event fires, then we cancel the event.  And that's to tell the browser we're taking control of this action.  And then if the drop event fires, so the drop event fires, it calls the drop function  which is down here, we cancel that too.  And then we go ahead and read the files.  And we have to detect support.  So we have to, you know, feature detect the support for drag and drop and the file API  in the next part that we're going to use.  But we've got this event.data transfer.files.  And that's all the files the user just dropped into our browser.  So the next step here is to add in the file API.  And again, you detect support for this.  And if none of this works, you still have that file input button that every IE6 user  loves, right?  So the read file looks like this, okay?  So it loops over each of the files and just calls this preview function.  And the preview function creates a file reader.  It attaches an onload event handler and it reads that file as a data URL.  So I'm going to get a base64 data URL for this file.  Now, I haven't checked the mind types here.  You could be dropping a massive file in here.  This code is not complete.  This is contrived examples for you guys.  I'm assuming that an image is being dropped into the browser.  Now at this point, I create a brand new image.  Once the onload event fires, brand new image, set the image source to the event.target.result,  which is the base64 string.  And I drop that image into my preview.  So if it were the tweet, you'd see that little image thumbnail come up in the side.  Okay?  Christ, everything's falling over.  So that's not a lot of code and works really well in browsers that support it.  And the next last part is automatic uploads.  If you use Flickr or Tor, they just recently updated their upload page.  So when you do, I want to upload an image, you just drag the files off your desktop,  drop them onto the page, and behind the scenes, while you're kind of thinking of nice titles  for your picture of your cat in a box, it's quietly uploading the file ready.  To be saved.  So the traditional method is you select all the files, you hit go, and it takes ages to  upload, and then eventually a page comes back and says add your title and description.  This you drop your files into the browser, and whilst you're actually typing up the title  and description, it's just uploading those files behind the scenes.  So that idle, it's making use of the idle time basically.  So when you hit post to my photo stream, it's just a really quick refresh because it's  already got it up there.  It hasn't published it yet, it's held in a queue, but as soon as you hit post to my  photo stream, it publishes it, and the whole experience is really slick and very smooth.  So this looks like this.  So in XHR2, there is a form data object.  We're going to create a new form data, and we're going to loop over all the files, and  we're going to do form data dot pen, and we're going to pen our file from our drop operation.  We've given it a name of file, so on the server side, when we're reading the posted data,  it's going to be under the name of file, and you can call it whatever you want.  I think create a new XHR object.  I'm going to open up a post, so I'm going to post a specific URL, maybe upload image.  I can also attach an event listener for the progress of the upload process.  So the key here is listening on the XHR.upload property.  So there's this upload property.  If you're sending up the wire, you can listen to the on progress event.  When that fires, it will tell you how far along it is, and actually you're uploading  that image, which is really nice for little progress bars, right?  And then I just do XHR.send that form data object.  It just goes up the wire.  I'm not having to tell it what headers to send, so it will automatically see that it's  this form data object, which is nice and special, it will encode the file properly for the server  to receive and mine types and all that jazz.  And it means I can do this.  I can select some pictures of my son, drop it into this thing.  Now, there's no progress to show it actually rendering the image, but I can do that as  well.  And here you can see it going up the wire.  Now this is slow because it's like 8 meg files.  But that's nice to have that feedback, and that's all native in browsers today.  And without that, the browser doesn't support that today, the process is exactly the same  as what we're used to.  Just file, browse, submit is exactly the same process.  If you have an input type file, please replace it with that or upgrade it to that.  So some of the things that are tomorrow and are available in browsers today, and we can  use JavaScript to polyfill some of it, and maybe you're going to build an HTML5 game.  This kind of stuff, you're going to be working in the edge browser, things like IE10 and  Chrome 20 and Firefox 59 and whatever it is.  So one, these two tiny bits of HTML5 I really like, they're kind of tucked away, dataset  class list.  So I've got a game, which is Space Invaders, and for whatever reason in this version of  my game I get this baddie, the big boss baddie.  And he's an image element.  And there's some data associated with that DOM node in the document.  So I've done data-health equals 13 and data-damage equals 5.  So if he hits me, the idea is I lose 5 points off my health.  So you can see if I got hit, me.health minus equals boss.dataset.damage.  I'm not having to get attribute, I just have access to.dataset and everything that starts  with the data property on my image is available as a property inside of that dataset.  And equally if I set some value, so if I do, you can see boss.dataset.health minus equals  1, that will just automatically update the DOM node as well.  It will set the health to 12 and so on and so forth.  And I can create new properties by just doing dataset.foo equals bar and the attribute will  be there on the DOM.  Now if the boss doesn't have any health left, I'm going to do boss.classlist.add dead.  Okay, how many jQuery here?  Nice thing about this is I can add classes and if the class isn't there, if the class  is there, it won't add it because it's already there, right?  I can remove classes, I can toggle classes, and I can test if it has a class.  So I'm going to date a classlist.has dead and not do anything.  And I saw a video that Paul Irish published a week or some recently, recent amount of  time, and he was looking at the performance of.classname, so element.classname.  If you touch element.classname, if you get it or set it, it's doing a reflow on the document.  But if you do element.classlist.add or.remove, it's not, the performance is much, much better.  I think it caches it to the end of the operation and then does it all at once, maybe.  But actually the performance of that doesn't trigger all these reflows, which is really  good.  Technically it should, but there's a video that goes with it.  I might find the link and post it on Twitter or something, but yeah, it performs much better  than just doing.classname.  Then it makes me think, is classlist plus query select at all greater than jQuery?  So could I use jQuery for really quick DOM manipulation and usually just toggling classes  or maybe adding event listeners, which is pretty straightforward as well.  Can I replace jQuery in my workflow with just some of these pieces?  I've got my own, I call it lame query, which is 18 lines of code, which replace all the  event listener model and query select.  Oh, I'd like to just have this classlist.  If I'm working on, if I know that this only has to work on a specific set of devices or  a specific type of browser, I can rely on this technology be here.  The classlist can be polyfilled as well, but you need to have access to the element.prototype,  which I know is in IE9, but I'm not sure about IE8.  It's fine that you can polyfill it, but it depends whether or not you can actually upgrade  the element prototype in the first place.  Browsers can go full screen now.  When Google posted their YouTube slash HTML5 page with the native video element in it,  people went crazy.  They're like, ah, Flash is dead.  People near me went crazy.  The thing that was missing was full screen.  I use the BBC iPlayer.  I put it full screen.  I sit at my desktop and just eat my lunch and watch the TV on my laptop.  Browsers need to be able to go full screen or video needs to be able to go full screen.  If it's really going to replace Flash video.  There is now a full screen API, which allows not only video to go full screen, but any  DOM node to go full screen.  Maybe you're building a game like the Cut the Rope from this morning.  It'd be great if you could just go, yep, go full screen.  On my Mac, it goes full screen.  I get to see the full game and no distraction around the side.  The API for this is a little bit fiddly at the moment.  It's not that fiddly, but there's the W3C implementation, which is full screen with  a lower case S. Then you've got the web prefix version, which has a capital S. You've got  the Mozilla prefix version that has a capital S as well.  I haven't bothered putting code up because it'd be really long just to be able to do  this kind of thing.  This is a speaker deck.  They've got this little full screen button here, which makes the whole div, or that div,  go full screen, now I can go through the slides.  Great for video, really good for games, and maybe good for reading.  If it's a newspaper website, it'd be great to go distraction mode.  Just take that article that I'm reading and go to full screen.  I want to include examples for all of these, but I realize I'd probably be rattling on  for quite a while.  A request animation frame, was it mentioned this morning?  It might be mentioned this morning.  It's a really good alternative.  This is a replacement for using set interval for animations, because it synchronized with  the refresh rate.  Ideally, it synchronized with the refresh rate of the browser.  So it goes at 60 hertz, so 16.6 milliseconds, I think it fires at roughly.  It means that your animation is in sync with the screen, which means that it's not constantly  competing with processing time in the browser.  If you look at the performance metrics of set interval versus request animation frame,  you'll see that it's not using as much resource as set interval.  Again, Paul Irish has got a polyfill for this, which says if request animation frame isn't  there, go look for it under the vendor prefixes.  If it's not under the vendor prefixes, go use set interval, which you would use anyway  in the first place.  WebGL is getting really stable in browsers.  I'd love to see WebGL in IE 10.  Maybe if there's any Microsoft people here, we can all hassle them to answer whether or  not it's going to be in there.  They probably won't.  But anyway, WebGL is going to give games developers the browser as a platform.  Full hardware accelerates, WebGL is hardware accelerated as part of the specification.  So it's really, really fast.  I think the Angry Birds example that Google posted a year ago, something like that, even  though it's all 2D, WebGL is a 2D API.  WebGL is being used for the rendering for that.  It's faster than if it had been done in Canvas a year ago inside of Chrome.  Another thing that's really interesting that's kind of around the corner is Blobs.  You can get binary data and having URLs to those Blobs.  So when you drop a file into a browser, you can get a Blob URL for that, or you can create  things like web workers.  You can dynamically create a web worker, which is you just make some JavaScript or put some  JavaScript into a Blob.  You get a URL for that and you point your web worker to that URL.  You dynamically create a piece of JavaScript on the fly inside of the browser.  DataList is one of those bits of HTML5 on the side.  If you're familiar with Visual Basic, the one thing I do remember are combo boxes.  So like a select box and like an input box, like they input box and select made love and  made a combo box.  So you can type your own value or you can select something from the drop down.  HTML5 has this as part of its specification, but not every browser supports it.  But Chrome supports it and the browser is starting to support it.  So there's these little extra pieces of technology that you should have a look at.  Have a skim through the 900 page HTML5 spec if you have loads of time on your hands.  So the things that are, I think, quite exciting as well.  Things like real time communication, access to the microphone, access to the webcam.  It's not that sexy, but it's been something that the open web community have been wanting  for ages and Flash have had it in their little pit of flashiness.  Being able to point my browser to the webcam, so there's no plug-ins on this page.  My browser's opened a stream up to my webcam.  That stream is being fed into a video element and that my canvas, a canvas is polling that  video element for the frames.  I think it's set into one instead of request animation frame, but it's polling the video  and as I move the slider back and forth, I'm choosing a hue so I can change the hue in  that video in real time.  Okay.  I was here with Bruce Lawson last year and he showed me Opera Mobile Labs where they  were accessing the webcam in the labs version of Opera.  I opened up Opera Mobile 12 a few months ago and it was just in there, not the labs version,  in the full production version of Opera 12.  It has access to the webcam.  It doesn't just open up a stream, I can't just go and hijack your webcam and start watching  you and doing weird stuff.  It asks you, it has a little button in the corner and it asked me if I want to share  the webcam with this webpage and similarly it would do with the microphone and other  pieces of technology.  But it's starting to land in browsers and I mentioned the Firefox demo.  They have access to the webcam and the audio streams.  The audio stream is, so the audio part of the web real time communications isn't as  well supported in the edge browsers as video is.  So if you have a play on Monday or whatever the weekend, if you feel up to it, I haven't  found the audio to work so well.  There are technologies that make the audio work.  So there's another technology called the peer connection API which means that we can connect  peer to peer.  We have to authenticate through an external server.  Once we've done that, we've got a connection one to one without the server.  So we could be chatting or doing video.  And there's an example up on, the Google code has an example of peer to peer audio and video,  so just video chat using just HTML5, quote, technologies, basically JavaScript in the browser  without any plugins.  It kind of leads me to this app that I wanted to build for ages.  On my Mac, I have this screen saver that when it kicks in, it listens for ambient sound.  So it has these particles flying around.  And as it hears noise, it kind of makes them explode in a little kind of like noisy happiness  explosion thing.  But I can see all the parts that are required to make this using open web technology.  This is the web real time communication API accessing the microphone on my laptop.  So I open up a stream to my microphone on a laptop and I take that feed of audio.  I then pass that audio feed into the web audio or the audio data API, which allows me to  actually go into the data and visualize that data.  So I need to write this code.  I mean, it doesn't come out of the box, but I can visualize that data.  I'd use WebGL to do the particles and the 3D kind of effects and then use the audio data  to make it kind of explode.  And then I use a full screen API to make it all big.  And then I just make that my, I could make that my home screen on my browser because  I've always got my browser open.  I open it up and it's there kind of listening to sound and doing funky stuff.  So if anyone wants to build that over the weekend, semi-tweet, I'd love to have it.  I did ask a bunch of other developers and they didn't do it either.  So I'm not, I'm not that hopeful.  This is the last part that I'm, I'm quite interested in.  I'm not quite sure how realistic it is.  But there's APIs that are coming or there's technology that's coming now that gives us  Chrome.  So a Chrome, I mean, we've got this full screen API, right?  We can go to full screen now.  That's great.  I want to get rid of the whole browser.  I want to get rid of the whole thing.  The user doesn't, with applications, the user doesn't really care if it's, if it's a web  browser or if it's some application they're used to opening.  So they have this mental model with, or this mental preconceived idea that a browser is,  or a website is limited by the edge of the browser.  It doesn't go beyond the edge of the browser, which is why that marketing guy wouldn't drag  into the browser.  He was scared that he would lose his email.  I want to get away from this model.  I mean, when you look at the app, was it the app store?  The app store on the iPhone, you don't look at it and go, oh yeah, there's Safari and  those native components because it's a mix, it's a hybrid application.  Because it just, it's the, it's the, whether it's design and user experience and all the  kind of finesse around the application that makes you not care, that makes you just use  it.  So I'm not talking about headless, headless application.  So there's things like phantom.js, which is a web browser without actually a head at  all.  I'm not talking about full screen.  I'm talking about getting rid of the edge of the browser and maybe also installable.  And there was a post on the W3C mailing list.  I can't remember which one, but Tim Berners-Lee talking about users wanting installable applications,  being able to set permissions and say what, what permissions they're going to give to  this application, this web application to be able to store data or to be able to do  file I.O.  Or to be able to print or we can print already.  But you know, those kind of things that have first class access on the desktop or on a  mobile phone.  Now I mentioned HTAs back in 1997.  IE Windows 8 has HTAs, which is awesome.  But it's running in IE 7, which is bananas.  So that's obviously not a solution.  So we can't just change the.html to.hda.  Chrome, if you hit the wrench or the spanner, you can go down to tools and do create shortcut.  But it's disabled on the Mac.  So if you have a PC, a Windows or a Linux, you can actually create a little application  for that URL.  But it's really well hidden.  My mum or my sister aren't going to do this.  I might go looking to do this, but they're not going to go through the spanner tools thing.  Opera had widgets, and actually they were part of the W3C.  And they seemed to me like a pretty good idea.  It's a zip file that has an.html file in it, JavaScript file, CSS images, and so on.  It has a little XML manifest file.  So it kind of has all the attributes of a web app, an installable web app.  And when you actually ran them, you could have transparency in your application.  It didn't have to be a square box.  It could be an odd shape if that's what you're into.  But no one really picks it up.  And oddly, I think it's partly to do with this word as well, widgets.  People don't like widgets.  They don't mean anything.  And eventually, Opera has dropped its support for Opera widgets.  And now they've become Opera extensions.  So a lot of the widgets still work, but they're under the extensions inside of Opera, like  a Firefox extension.  Windows 8, I mean, I'm excited about the fact that the stack is fully accessible from  normal web stacks.  So I can use JavaScript to access the operating system, which is great.  I love the idea that I can just drop a website into Visual Studio and create an application  I could put in the store.  Obviously, you don't want to do that, but you can.  This is getting closer, but it's still bound inside Windows 8 for me.  I think this is great.  This is a really good step forward, but it is still locked inside of Windows 8.  I want to see it working on every platform.  Mozilla have a draft for a specification called WebRT.  So Windows RT is Windows runtime.  WebRT is web runtime.  And the idea is, well, this is in Firefox now.  If you go to navigator.mosagent.install, you can install a web app into Firefox.  And the manifest looks something like this.  There's also permissions property that says what access this application is going to get.  My only issue with this, or my first issue with this, and the blocker is you can only  install from inside of Firefox.  Does anyone want to get that?  Okay.  Yeah, you can only install from inside of Firefox, which means that that idea and that  technology is locked inside of Firefox.  I want to see this.  I want to see.webapp, which will just be a little JSON manifest.  The points to the application says what your roles are internal to my application, what  permissions I want, whether I want to get, I need 500 megs worth of disk space because  this is a photo application.  And as the user is installing it and double clicking on it, first time it will say, yeah,  I want to allow you to have this much disk space.  Have the same security model, same cut all from the security guys that the browser gives  you.  But I want to be able to pass this.webapp to anyone of you.  And if I use Chrome and use IE 10, it doesn't matter.  You double click on it and it opens up a web app using either IE 10's render engine or  Chrome's render engine or Opera's render engine.  This doesn't exist at the moment.  This is just me kind of wanting something.  But this is kind of where I think we might end up heading.  This does not mean you should go and take your websites and wrap them either in Windows  8 applications or the Mozilla web runtime.  Just as when Adobe shouldn't be taking their forums and making them the entire website  flash, we shouldn't be taking entire websites and just making it an application.  Website is a website.  It's good for webvenus.  If you're going to build an application and wants to feel like an application that suits  that platform in the first place.  So I've got a thing about native versus web.  It's not really native versus web because most of the time nobody really cares or can  tell the difference.  You can tell the difference when the design is bad and the UX is bad.  You don't care, like I said, that the app store is actually Safari.  It doesn't bother you.  It works.  It feels right.  It has to look right on each platform.  So don't go dropping your entire websites in.  So hopefully some of you will take some of these points away and actually add them to  your website.  The drag and drop one is really easy.  So go ahead and do that.  For me, the constant comes up when will HTML5 be ready?  When can I start using it?  It's not about the spec being in recommendation phase or being finished.  It's about what technology is implementing, what browser and what you can rely on.  CSS 2.1 only went to recommendation end of 2010.  It was in draft or long before.  It was pre-recommendation long before that.  Anyone doing CSS was using 2.1 quite happily and just avoiding the parts that weren't  supported.  So use the parts of HTML5 that are supported for your application that you know that you  can use or progressively enhance and make use of.  We as a web community need to demand more of the vendors to get more access to APIs and  learn you some JavaScript.  Buy some books.  I don't think I've finished a whole JavaScript book.  So that kind of applies to me.  But do actually have a look at what the language can do.  He's going for beer.  So that's the end of my talk.  Thank you for listening.  If I think there's like two minutes left, if you want to ask me a question, maybe ask  me after everyone's gone.  So thank you.  Thank you.
Remy_Sharp_-_The_Outliers_of_HTML5_0_15359.png Remy_Sharp_-_The_Outliers_of_HTML5_15360_16415.png Remy_Sharp_-_The_Outliers_of_HTML5_16416_19847.png Remy_Sharp_-_The_Outliers_of_HTML5_19848_21371.png Remy_Sharp_-_The_Outliers_of_HTML5_21372_23807.png Remy_Sharp_-_The_Outliers_of_HTML5_23808_23975.png Remy_Sharp_-_The_Outliers_of_HTML5_23976_25775.png Remy_Sharp_-_The_Outliers_of_HTML5_25776_26399.png Remy_Sharp_-_The_Outliers_of_HTML5_26400_28343.png Remy_Sharp_-_The_Outliers_of_HTML5_28344_28991.png Remy_Sharp_-_The_Outliers_of_HTML5_28992_32843.png Remy_Sharp_-_The_Outliers_of_HTML5_32844_40811.png Remy_Sharp_-_The_Outliers_of_HTML5_40812_41855.png Remy_Sharp_-_The_Outliers_of_HTML5_41856_42155.png Remy_Sharp_-_The_Outliers_of_HTML5_42156_46847.png Remy_Sharp_-_The_Outliers_of_HTML5_46848_48215.png Remy_Sharp_-_The_Outliers_of_HTML5_48216_53459.png Remy_Sharp_-_The_Outliers_of_HTML5_53460_54395.png Remy_Sharp_-_The_Outliers_of_HTML5_54396_54947.png Remy_Sharp_-_The_Outliers_of_HTML5_54948_55235.png Remy_Sharp_-_The_Outliers_of_HTML5_55236_58631.png Remy_Sharp_-_The_Outliers_of_HTML5_58632_60131.png Remy_Sharp_-_The_Outliers_of_HTML5_60132_62147.png Remy_Sharp_-_The_Outliers_of_HTML5_62148_62771.png Remy_Sharp_-_The_Outliers_of_HTML5_62772_67763.png Remy_Sharp_-_The_Outliers_of_HTML5_67764_67907.png Remy_Sharp_-_The_Outliers_of_HTML5_67908_68375.png Remy_Sharp_-_The_Outliers_of_HTML5_68376_69119.png Remy_Sharp_-_The_Outliers_of_HTML5_69120_69407.png Remy_Sharp_-_The_Outliers_of_HTML5_69408_71999.png Remy_Sharp_-_The_Outliers_of_HTML5_72000_72047.png Remy_Sharp_-_The_Outliers_of_HTML5_72048_72095.png Remy_Sharp_-_The_Outliers_of_HTML5_72096_72167.png Remy_Sharp_-_The_Outliers_of_HTML5_72168_72215.png Remy_Sharp_-_The_Outliers_of_HTML5_72216_72263.png Remy_Sharp_-_The_Outliers_of_HTML5_72264_72323.png Remy_Sharp_-_The_Outliers_of_HTML5_72324_72371.png Remy_Sharp_-_The_Outliers_of_HTML5_72372_72419.png Remy_Sharp_-_The_Outliers_of_HTML5_72420_72479.png Remy_Sharp_-_The_Outliers_of_HTML5_72480_72527.png Remy_Sharp_-_The_Outliers_of_HTML5_72528_72575.png Remy_Sharp_-_The_Outliers_of_HTML5_72576_72671.png Remy_Sharp_-_The_Outliers_of_HTML5_72672_72755.png Remy_Sharp_-_The_Outliers_of_HTML5_72756_72803.png Remy_Sharp_-_The_Outliers_of_HTML5_72804_72863.png Remy_Sharp_-_The_Outliers_of_HTML5_72864_72935.png Remy_Sharp_-_The_Outliers_of_HTML5_72936_72995.png Remy_Sharp_-_The_Outliers_of_HTML5_72996_73043.png Remy_Sharp_-_The_Outliers_of_HTML5_73044_73091.png Remy_Sharp_-_The_Outliers_of_HTML5_73092_73175.png Remy_Sharp_-_The_Outliers_of_HTML5_73176_73223.png Remy_Sharp_-_The_Outliers_of_HTML5_73224_73307.png Remy_Sharp_-_The_Outliers_of_HTML5_73308_73379.png Remy_Sharp_-_The_Outliers_of_HTML5_73380_73463.png Remy_Sharp_-_The_Outliers_of_HTML5_73464_73523.png Remy_Sharp_-_The_Outliers_of_HTML5_73524_73583.png Remy_Sharp_-_The_Outliers_of_HTML5_73584_73703.png Remy_Sharp_-_The_Outliers_of_HTML5_73704_73751.png Remy_Sharp_-_The_Outliers_of_HTML5_73752_73823.png Remy_Sharp_-_The_Outliers_of_HTML5_73824_73871.png Remy_Sharp_-_The_Outliers_of_HTML5_73872_73991.png Remy_Sharp_-_The_Outliers_of_HTML5_73992_74099.png Remy_Sharp_-_The_Outliers_of_HTML5_74100_74483.png Remy_Sharp_-_The_Outliers_of_HTML5_74484_78143.png Remy_Sharp_-_The_Outliers_of_HTML5_78144_79475.png Remy_Sharp_-_The_Outliers_of_HTML5_79476_80495.png Remy_Sharp_-_The_Outliers_of_HTML5_80496_81035.png Remy_Sharp_-_The_Outliers_of_HTML5_81036_83147.png Remy_Sharp_-_The_Outliers_of_HTML5_83148_84539.png Remy_Sharp_-_The_Outliers_of_HTML5_84540_86557.png