 So, I am Raj, Raj Shaker. I work as a developer at RanchoGasic for Microsoft. So, this particular session is about, you know, about, so there is this, how many of you here have not heard of HTML5? So, you know, that's what I expected. Pretty much everybody has heard of HTML5, right? This is all this buzz around this new, you know, the new where, you know, how it's going to change, you know, how we're going to develop web applications in the future. It's all about applications and it's not just about serving content and what not. So, this particular session is about, you know, is that really all high? Or is there something to it? Or is that, you know, when we talk about HTML5, CSS3, HTML5, are these things that we can use in our web applications today? Right? Or can we not? Or if we can, you know, how can we use them? So, this is basically about, you know, how we can build compatible web applications. Give good user experiences given the state of the web as it is today, right? So, very briefly, you know, that's kind of the agenda. So, we kind of got a review, I guess, you know, I don't know how visible this is at the end of the hall. But basically we're going to review, you know, what are some of the challenges with building web applications that work across browsers and give a good user experience. And then we'll basically review some best practices around that, you know, around building compatible web applications. So, that's, you know, so, you know, I'm not sure how many people here do web development for a living. So, that's probably about 60% of the room. It's actually surprising to have an experience with more. And, you know, if I were to ask all you web developers, what is the single biggest pain point in your web development? Yeah, you know what, I agree. I guess that's a pretty big pain point. But I would probably generalize it as having to support so many browsers, right? You have to support IE, you have to support Firefox, Chrome, to a lesser extent probably Opera and Safari. But at least these big three, you definitely have to support. And not only do you have to support all these different brands, but you end up having to support different versions within a brand, right? And of course, you know, IE6, you know, that's where all that pain is coming from. You know, still an exceptionally large percentage of users who are on IE6, which is more than a decade old browser. So, traditionally, you know, what web, some of the things that we are doing to, you know, what I forgot about this little, you know, if you have to keep track of, you know, feature metrics, I mean, that's what traditionally, you know, that traditional approach to supporting different browsers. You know, what browser do we have, what features do we support? If I want to provide feature A in my web application, how do I make sure that this works across all these browsers? You have to pretty much figure out, like, IE version 6 with a list back in had support for this particular feature. And therefore, I have a little code there which checks for that particular scenario. And then I enable that feature or disable that feature to provide, you know, a backfill or whatever the case is. If you want to do that, you probably need to be a superhero, right? That's what I was shooting for. So, this kind of is the browser market share that I kind of put together yesterday from Net Market Share. And, you know, you can see that IE8 has about 27% Chrome, about 15% and so on and so forth. But you can see that, you know, there is no clear winner here, right? I can't say that. I'll just support this one guy and I'm done. You can't say that. You pretty much have to, you know, it's a very fragmented market. You know what, for end users, this is great news, right? If I'm an end user, I won't use the web. I'm just spoiled for choices, right? There are so many high-quality browsers out there. But as web developers, not so much. Not so much great news, right? So, you have to worry about, you know, different browsers, different versions of each browser. And today the cadence at which new versions of browser being released is also increased tremendously. Probably precedence that's been set by Google with their, you know, no pig really cares about the Chrome version. Who knows what is the current Chrome version? Yeah, I get like many different answers. So nobody knows and nobody cares. So, you know, new versions of browsers are getting released continuously. It just makes our job worse and worse, right? If you have a key track of versions and features, it's just impossible. You can't do it. So that's what's something that we have been doing in the past. We detect browser versions. We detect browser ground, browser version, and we try to enable disabled features based on that. This is simply not going to happen. It can make grown people cry. So that's where feature detection comes into the picture, right? So going forward, you know, from a JavaScript point of view, right? How do you get or how do you build in support for some of these newer HTML5 technologies, right? As we just saw, looking at versions and trying to map that to support for features is just not going to get it. Because there are just too many versions, too many browser brands. So Modernizer is basically a library that helps you deal with this. The basic idea is don't make decisions based on browser versions, right? Check for, basically try to sense, try to detect programmatically whether a particular feature is available in whatever the current browser is, right? Maybe you can check for the existence of a particular raw check or a method or a property or a particular behavior. You know, basically some kind of fingerprinting, you know, you have to do to figure out what is the current browser. And then dynamically, you know, you might, if it is a critical aspect of your site, you might want to dynamically load browsers or supplementary libraries which provide support for that particular feature which is there or which is not there. So, you know, typically you write code like this, right? So for example, here what I'm doing is I'm saying navigator.useragen.index. or a particular substring. I'm basically looking at the user-agent string of the current browser and seeing if it has a particular substring. If it does, then I do something and if it doesn't, then I do something else. Basically, here I'm making an assumption that a certain feature is going to be available based on a particular user agent. Basically, here the code says that if it is IE, then do attachment. If it is not IE, then use add event listener, HTML5, W3C standard way of attaching event handlers to events. So this is not a good idea. Do something like this instead. So here, basically you can see that what we're doing is we're checking whether the window object actually has a method called animate listener. If it does, use it. If it doesn't, then I see if it has attachment and if I have that, then I use it. If you have neither, then it's probably not a browser. So I just wanted to quickly show you what that means. It's not exactly a very complicated demo or whatever. So let me just show you the... I guess that's not very visible. So I'll just open it here. So basically what's happening here is exactly what I showed you in the slide. I checked if the add event listener is available. If it is, then I basically showed this particular message and if it is not, I showed this message. It's not standard compliant. So I go ahead and click that link. It says you're using a standard compliant browser because it went into that. I'll use IE's debugging tools to switch to a... IE has this feature called as document mode where you can switch the rendering mode. You can make it pretty much like it is IE5 or IE7 or something like that. So I'll go into IE5 mode and click on it. So now it says it's not standard compliant and so on and so forth. Essentially what happened was it went into the else case here and called attach event here. So a very simple example of how you might want to do feature detection. Now that was a very simple case. It said window dot, attach, add event listener. If it existed, then great, we use it. But what if feature detection looks like this? Now I know if you can't read the code, that's kind of the idea. You know what? That's probably the reaction. Now that's where modernizer comes first because what I showed you was a very simplistic case. You know, grade, I mean, everything is very fine. But you know, if you want to detect something that's slightly non-trivial, for example that piece of code that you saw there was trying to detect whether the current browser has support for CSS3 on-face room. That's not quite as straightforward. So there is this nice library called modernizer which basically it's a very simple JavaScript API that you can use to detect support for all major HTML5 and CSS3 and even ECMAScript5 features, whether they're available in the current execution environment, in the current browser or not. So it detects all the major features. It includes HTML5 shims for semantic type loader browsers. What I mean by that is, so with HTML5 one of the new things as far as markup is concerned is something called a semantic tags, right? Where basically your markup can be purely markup, right? There's no presentation information absolutely whatsoever in your markup. All presentation stuff goes into your slide sheets in your CSS and your markup is just defining the structure of it. You want to say that this is an article, this is a section, this is a header, this is a footer, this is an aside, and so on and so forth. You're able to express or associate some semantic meaning to your markup. It turns out that up until IE 8, you couldn't use these tags, like these are new tags, like article section aside, right? You couldn't just use that. I mean you can use that, but you will not be able to style it. This was a problem up until IE 8. IE 9 of course has support for all the new semantic tags and so on. But there is a certain workaround that you can use to make it, make older versions of IE support these semantic tags. Basically, the actual hack doesn't matter. We have just said open a great element of new tag name and then the tag name magically becomes styleable. So Modernizer has that little piece of pixie dust to make IE recognize all the new semantic tags, right? So if you use head section, I mean section header footer and all, it will start working in automatically older versions of browser. As long as you include it, Modernizer. Modernizer is simply a JS file that you include in your page and then you automatically get support for these tags and you get support for feature detection. So for example, right? That gigantic piece of code that you saw, that's what it looks like when you use Modernizer. Very simple, right? You simply say if Modernizer.FoundPace, then you do what you have to do. So pretty much all the features can be detected this way as a boolean property. Say Modernizer.Canvas, Modernizer.Jailocation, Modernizer.Depsockets and so on and so forth. So let me quickly show you what that looks like. So here I have a little document. So I'll say allow blocked content. So first let me show you what that HTML has. So you can say it's a very simple HTML. I've used some of these semantic tags I was talking about. It has header, section, blah, blah, blah. Write some tags. You will notice that right at the top I've included the Modernizer script. I've used 1.7 when I put this demo together sometime back. Right now I think it's Modernizer version 2 has been released. So you can very well use each one in this one. And so we have this markup. You can see that there's no presentation information here. So that I've basically put it inside my style sheet. So all the styling stuff is there. So this looks decent, right? It looks tired and whatnot. So what I'll do is I'll go here and take off this particular line. Maybe I'll just comment it out. And I'll just use my debugging tools here to switch the document mode to, let's say, IE5 rendering mode. And you can see that that's what it looks like in IE5. It looks horrible. Why does that happen? So basically what the browser does in legacy IE6 and IE8 is when it encounters a tag which it does not recognize it's basically going to just treat it like just the text. It's just going to take the text and render it. It's not going to basically style it. So on the other hand if I just bring this script back and I just refresh the page, it's still in IE5 rendering mode. It's not exactly pixel for pixel the same as what we saw earlier but you can live with this. So basically what has happened here is all those tags, header section and so forth have become styleable. So Modernizer gives you this for free. What else can you do? For example, you can detect whether support particular features. For example, here I'm checking whether Canvas is supported in this particular browser. I check for that by saying modernizer.canvas. So that's the exact same syntax part for pretty much all features that we want to do. So that's great. So now we can do feature detection to see whether there's support for a particular HTML5 API in the current browser or not. Now what do you do in case you encounter a situation where the browser does not support? You typically want to do more than alert, right? My example I'm just doing alert. So you want to provide that functionality, that feature. So how do you do that? So that's where polyfills and shims come into the picture. I know these sound like, you know, fancy terms but essentially what these are is basically light release that provides support for a particular HTML5 spec on a browser which does not natively provide that support. So let's quickly see what these are. So, you know, this is typically the scenario, right? So there is this nice new feature maybe with the HTML5 API that has been released. The latest versions of the browser support that, it's really nice. You know, the geek in you wants to start using it and you start using it, but then along comes old browsers, right? Basically your users, end users. I mean, I don't know why people never upgrade their browsers now. I mean, but they don't. I guess, you know, it's just not something that end users will just go and do, right? Okay, today I'm going to go and upgrade my browser. Nobody does that. In fact, that's why it makes sense for the, you know, Firefox and Chrome, they update themselves. I'm going to start doing it very soon. I mean, it's been already announced. So browsers will start updating themselves. So these problems should eventually, you know, over time, hopefully go away. But right now, the reality is these forms are there. So when old browser comes along and your app goes thermonuclear, not good. So polyfills, what do they do? So they support new standards and make them work in older browsers, right? So polyfills stands for polymorphic backfilling, which is even more scary sounding, but no, it's a very simple concept. It's just a library, right? It's just typically a JavaScript library that provides support for HTML5, for example, Canvas. Maybe, you know, I'm running on an old version of IE or Firefox or, I don't know, 3D version of Chrome did not ask for Canvas. And in that case, you want to provide support for that API in your app, right? So you can use a polyfill library for that. Some of the things you need to remember are, you know, equivalent fidelity is not guaranteed. So if the native implementation might work in a certain way, polyfill might not give you the exact same experience. For example, typically, all these polyfills provide support for all these features using plugins, right? They might use Flash or they might use Silverlight to provide that equivalent functionality. And that means that the user has to implement, I mean, install that plugin. Or maybe they don't have the correct version of the plugin. And it's a whole can of worms. That's why the world is actually kind of moving away from plugins, right? The plugin is on their platforms, at least on their iOS platforms, right? You can't have Flash on Windows 8. You'll find that, you know, on the Metro side of things, the Metro version of Internet Explorer does not support Flash, does not support Silverlight, just, you know, HTML, that's it. So the reason is, you know, it's just not a good user experience. It does not have the plugin information, but it's not the correct version of the plugin. You know, that's the main point, right? So that's something you have to remember about polyfills. You get to use and leverage new specs without losing, you know, an entire chunk of user base who are not on the correct version of the browser. An equivalent kind of concept is a shim. A shim is basically just a regular library. It's different from a polyfill in that a polyfill typically will implement a W3C standard. For example, it will implement the Canvas API. It will implement the geolocation API. That's called a polyfill. A shim is basically a library, just a regular library. I think fancy. Typically what these libraries will do is they will be an abstraction on top of some functionality that is provided by the HTML5 specification. For example, there is this library called as AtlifyStore, which is basically an API that has been built on top of all the available client-side storage technologies. Starting with cookies, right? Cookies, down storage, index DB, maybe storage through local storage through flash or simple light. AtlifyStore is a high-level library which you can use to get the ability to store data on the client-side. Its implementation takes care of using the most appropriate technology. Whatever is available. On modern browser, it might use index DB. On older browser, it might use cookies. I know. That's called as a shim. Just some terminologies. The folks who build Modernizer, the library, they maintain a gigantic list of polyfills in the exact location. You can just go to bit.ly slash polyfills. I don't know if the network works here. So, this is basically the page. They have classified it based on the technology area. SVG, Canvas, Edge Storage, and so on and so forth. There's a big list of polyfills that are available. Very useful list. But just like, any open source library that you might use in your applications, remember that you'll probably have to vet the code. Some days it's written it. They don't owe you anything. You'll have to vet the code and make sure that it works for you. And you may have to support it in the future as well. But otherwise, that's a good... That's one way that you can deal with this whole browser fragmentation problem. So, one thing I'm going to show you with this is I put together a little lab here. So, basically this is a HTML5 doodler. So, this little gray area that you see is basically a canvas where I can go and draw stuff. So, I can just do that. And this is not any plugin or anything. So, I'm not using flares or anything. So, that's great. So, this is working well. But then I'm going to IE 10 here. So, what happens if I go and go into Internet Explorer 5 works mode? So, basically now I'm simulating IE 5. Definitely, it does not support Canvas. But, you can see that I'm still able to draw. So, how does this work? The only thing is, if I click this is actually using Silverlight. But to the end user, there is no difference. Whether I'm using IE 9, IE 10, Firefox, Chrome, IE 5, IE 6, I can get the same experience. So, how is this enabled? So, in this particular app I used a Canvas polyfilm that I got from WeDoc that I downloaded a polyfilm for Canvas. And I implemented it. So, very briefly if you want to see the code, how it figures out stuff. So, I actually used modernizer for this. So, this is slightly non-trivial here. So, for example, you know code like this. So, here what I do is, if modernizer.cambus is true, which means it's available, then I do something. And otherwise, I basically enable the markup if you see and have both. So, right down here, I have the Canvas tag here which is where the rendering happens. And right below that, I have an object tag here to instantiate my Silverlight plugin. And then a little bit of script up here figures out which will be displayed. It checks whether Canvas is available. Canvas is available is great. If it's not available, then it use that. Now, the nice thing about using a polyfilm is that the code that actually does the drawing. So, for example, this is the script which is slightly a bit of stuff here. But let me just show you the core code that draws lines. So, this is the function that actually is drawing those students. So, here you can see that all we are doing is there is this. This is basically the Canvas API. I set the line color. I do a begin path and then I do move to line 2 and then I do a stroke. So, this is the API. This is the basic Canvas API. Now, the nice thing is, regardless of what I am using, whether I am using the Silverlight plugin or whether I am using the regular native Canvas limitation, this code doesn't change for me. So, this is a very simple implementation but take a case where I am doing lots of complex stuff. If I had to use different APIs and different bold paths, that just exponentially increases your test area, test surface and it just gets more complicated. Whereas here I just write this code once and it just works everywhere. So, that is what polyfills give you. So, obviously there will be a little bit of hookup code elsewhere. So, for example, when I So, basically here in draw line I use this.dc. So, that this.dc will get conditionally initialized depending on whether support for Canvas is there or not. That should be happening somewhere here. So, you can see that written little wrapper around all that. So, there is get Canvas here. So, if modernizer or Canvas exists, then I simply get the Canvas object and return that object. If Canvas is not supported, then I basically go and I am doing a return check here that is not required. If Canvas is not supported, I simply get a reference to the Silverlight instance and return that. The nice thing is that is all. So, this is the only piece of code where I am doing some feature detection and doing some you know, some alternate code paths that exist. The rest of my logic completely does not change. So, that is the idea behind using polygons. So, you know, you automatically get Silverlight. But obviously here this is a good path. This is a happy path. If you use that did not have Silverlight obviously you will have computations. All right. So, with that I am kind of kind of done. How much time do we have? We have about 10 minutes I suppose. We have about 10 minutes. I am sorry, I said 8 minutes in this. All right. So, another example that I want to talk about was about HTML5 video. We can either do that or if you have questions we can talk about that. Yes. Use polyfill. Use polyfill. Do you need to use a modernizer as well? Do you need to what? Sorry. Modernizer as well? Modernizer. No, modernizer is... I guess the polyfill needs to take care of modernizer code as well. In the code it is written... Just push it up. Okay. What I think is if you use polyfill polyfill I will be intent to take the modernizer code as well, I guess. Because that or we need to express this because we import modernizer and look at the code stuff. Do you see that? Well, see, the polyfill libraries are just open source, voluntary, different people are putting it together. Somebody says if I want to support, we can't do this. But also they just put it together. So, modernizer is a completely separate initiative. I think somebody from Google is the person who is on GitHub. We can look at the modernizer source and everything. So, that's a completely different initiative. So, we can use modernizer to feature it as well. So, you know, we might... We might have a preference for one particular implementation of Canvas. Here I use a flash-based one. And so on and so forth. So, those are... The thing I'm guessing is that if you support the Canvas, what will you take care of in both Canvas? What will you take care of in both Canvas? Depends on the API. So, for example, let's say you are using geolocation. Whereas, something with Canvas, it's slightly different. So, in my case, I have to put a Canvas tag and a silverlight tag there. Depends on the polyfill in question. There might be a polyfill which provides a better interface where I can kind of abstract away whether I'm using a polyfill or not. There might be other polyfills which don't. Questions. So, we'll probably talk about video. The only reason I didn't kind of want to talk about video is it's not very... It's not here with JavaScript. So far, what we saw... Look at JavaScript APIs, which are JavaScript HTML5 APIs for which we have polyfills that you can use and modernize your life with a feature detection and whatnot. HTML5 video is another HTML5 feature, right? So, now you don't need plugins to play video in your applications. Do you have a question? Yes. Can you use the mic please? There should be one there. Can you talk a little bit on the JavaScript platform that Windows is going to provide on Windows 8? Uh... On IE 10, you mean? Yeah. Because what kind of platform is going to be? As in, there are things specific they want to know, it's going to be a completely ES5 compliant... JavaScript engine. JavaScript engine, yes. Uh, Lambda. Sorry? Do you have a DAW or something? IE 9 has... IE 9's... In fact, IE 9's ES5 implementation is one of the most standard compliant implementations ever. You? Sorry? No. No. Never. So what you can do is you can go to ES5, HTML5, there is a test suite for it. Go ahead and run it on all the browsers. IE 9 already has support for ES5. I don't know what new things are coming in the IE 10. Probably performance improvements. I don't know. On the same thread, Windows 8 and I started using the DOM object structure seems to be very different. For example, when it tried to use in and out machine, the styles weren't applying. Sorry? The styles weren't applying to the document object model. So, Windows 8 document object model is different from that of IE 9. No, I mean, it seems to me when I tried to use it to me that as it's compliant, it's not interpreted JavaScript which happens in a regular IE 9. IE 9 is not interpreted either. So, from IE 9 onwards, the JavaScript engine is a different architecture. Up until IE 8, it's purely interpreter-based JavaScript front-line. With IE 9 onwards, it has a dual code path. So, basically, there is this little instrumentation that happens as your application is running where it tries to identify odd paths in your JavaScript code. Hotpots are basically sequences of script which are getting executed often frequently and so on. And those pieces of script get compiled into native and then once they get compiled, they run as native code. So, it's like hybrid of what Chrome does and what Firefox does. As far as DOM interrupts, the goal is for it to be as compliant with the W3CHTML5 standards as it can be. So, if you're seeing a certain behavior, it sounded more like a tight-ended kind of compilation into an object you see rather than a native JavaScript which modified DOM. What makes you say that? Because I wasn't able to get the same behavior which I would have done while trying to use an IL-9 which modified the document of the object and it happened that we started using Windows. I don't know, the particular use case we're talking about, we can probably discuss that offline. But the basic interface and everything remains exactly the same. If anything, IE10 is going to be supporting even more of the HTML5 standards, support for web sockets and index team. More of what was not there in IE10 Do we have time to talk about video? Let's see. It's 12.30. Yeah, we have time, about 10 minutes. Alright, so with W3CHTML5 video was probably one of the most visible in W3CHTML5 with the new spec. So that's typically how you did video before. You use plugins, that was pretty much the only option you use. So this is the new way of doing it with HTML5. It's much cleaner and it's natively supported. So all that goodness comes basically it's a video tag. It's set up a source and then it starts playing. Unfortunately it's not as ideal as it could have been. There is the codec stop story. This was a great opportunity for creating a standard which everybody implemented. So what is the reality? The reality is there are different codecs. The codecs are basically the piece of code that decode and encode video or any kind of media. So obviously when we're talking about browsers, we're talking about decoding. Different people have different ideas about which are the correct codecs to support. That's the issue. There is no standard. Or there are too many standards. There was this funny XKCD cartoon that I saw some time back. So somebody says for this particular piece of technology we have all these technologies. There is no uniformity. There is no standard. So I'm going to create a new one which is going to make up this one. And that becomes the next item. So that's essentially what happened here also. So you have IE5, Fox and so on. So this is basically a matrix that talks about what is the codec support. So there are three main codecs. So we have Theora in the all container. You have H264 video codecs in MP4 and you have WVM. So basically the situation is at least for the IE, Firefox and Chrome. Chrome supports Theora and WVM. Safari supports H264. IE supports H264 and kind of supports WVM. Firefox supports Theora and WVM. Just like our browser fragmentation story no clear winner. The story between IE and Chrome is a little funny. So see here in this diagram it says H264 is a dot. I mean it's not supported but just not quite true. What happened was basically Microsoft and Apple they think H264 is the way to go. Chrome believes WVM is the way to go. They are worried about royalty issues with H264. Safari obviously you know Theora is completely free and so is royalty. No incumbrance with royalties. So the funny thing is IE supports WVM. So IE is not going to ship with support for WVM. But Google has put together a codec for IE. So if that codec is installed on the machine then IE will play HTML5 video which uses WVM encoded video. And the funny thing was they threatened not to support H264. So far they have not actually done it. They have not removed support for H264 yet. So for that Microsoft has put together a hidden for Google Chrome. So if that is installed H264 will work there. But you know what that's not an ideal situation right. The whole idea of HTML5 is to move away from plugins move away from having to install stuff on the client side. But the video that's unfortunately not the case. So what does that mean for us right. If you want to put video content on even. And yeah I didn't even talk about the mobile side of things. Mobile side of things is slightly better. In general. But here also you can see that there are differences. So IE9 the same matrix you will see on the Windows phone side as well. Android and iOS both have support for H264 so maybe it's slightly better there. So that's what we have to do. We have to support everybody right. So fortunately the HTML5 tags is kind of you know I think they had that people far view to support this. So you can do this. You can have a video tag and have multiple source tags each one a different encoding and the browser will just pick whatever is the one that it supports. Right. But what about old browsers right. What about IE6 and 8. They don't support video tag. So you can fall back to Silverlight or Flash. So this is kind of funny like how many levels of fallback we have here right. We have video tag but then the encoding might not be supported. So we have to fall back to that with multiple encoding but then video tag might not be supported. So we go to flash and you know what you can go even more. Maybe the flash is not supported. So you do Silverlight. Maybe Silverlight is not supported. Now you can put some text there. As the fallback you can go for object tag also. You can say you know go get a better browser. You can put that message there. So let me show you what that looks like. So you know here is a simple video over. So this little waterfall it plays the waterfall. Very pretty. Let's open that here and see what that looks like. So very simple right. So I have not used the source tag if you have just one video you can put it as an attribute to the video tag as well. So it just takes it and plays it. So let's see what happens if I take that and load it in Firefox. So this is Firefox. I don't know what version I have. See now I don't know what file. Okay 10. So 10 definitely supports video right. Firefox supports video tag for a very long time. But it's not able to play it. Why does not they have to play because it's an empty code. It's an H.264 encoded video. So let's try opening video 2.html here. And obviously it's able to play here. So what is video 2? Let's take a look at video 2. So it's essentially what I showed in the slide. So I have both now. So I have MP4 as well as OGB on video. And it's able to play both of them just fine. Now let's go back to IE here and go to quirks mode and you can see that that doesn't look like a video to me. So let's open this. So right now I'm still in quirks mode. It's in IE 5. And you can see that it's able to play. And if I switch to standards mode again that also plays. So what is the black magic here? So we have video. We have multiple sources for supporting Firefox and IE and then we have object tag for don't be worried about that. I just happened to use a very complicated video player. But there are simpler ones out there. So that's the situation with video as far as supporting all the different browsers are concerned. So there's some hope you have some idea about what it takes to support different browsers for all in modern HTML5 APIs. So that's my blog, email, Twitter can get in touch with me through those. Here are some books that I thought are really really nice. HTML5 web designers is in particular a really nice book. You know what's the nicest thing about that book? It's only 80 pages. Very small. So you can read it in one evening. But then it's a nice book because it really gives you a good picture of what is the hype around this technology. What can you do to start using these today? Even the same thing with the CSS3 web designer what I really like about that book is it talks about CSS3 and CSS3 can be used today and gives you some disadvantages around that. Because ultimately your client want you to support everybody. So you know what, I read a little blog post recently. So you go and ask your client do you want this app to support IE6 or IE7? What do you think the client will tell you? Yes, of course it has to support IE6. You know what you should do in response? You should add one more item to your bill support for IE6 IE7. Seriously, because that's what it takes, right? So putting a ten year old browser is going to take a lot of effort from your side. Right? Transmit that cost to that client. So that will be a little motivation for people to upgrade, to get their user base to upgrade. So actually I thought that was a pretty good idea. Yes. So that's going to happen. So from the subsequent Windows update all users of IE6 are going to depending on your operating system XP users are going to go to IE8 Windows system up are going to go to 9 Windows 7 whenever IE10 comes out then it's going to upgrade to 10 and so on and so forth. So maybe a couple of years around the line this will be less of an issue hopefully so we can all go into other things better things. So that's it and done my session I think we still have No time. No time.