 Alright, so, hi everyone, my name is Raj, I work as a Minister and I'm just doing Microsoft. Welcome to the session, thanks for coming. So, in this, in the next 30 minutes, I'm going to be talking about, talking about, it's not audio. So, in this session, I'm going to be talking about something that we have as a very good person. You know, for building, building back up in the world. So, I'm going to try to ask you a few questions. What is the single most, you know, single biggest pain point, while, you know, there's been a lot of pain in the side as well. I6, I7, whatever it is. Yeah, so that's basically the biggest pain point. If I just talk really loud. So yeah, that becomes the biggest pain point, right? Like, you want to use the new capabilities that makes you go 5, use the table, CSS 3, ECOS 5. And then, you know, at the time that not client, this has to work on I6, this has to work on I7 and it has to have some perfect, perfect identity for all the browsers, all the clients, all the versions. So this talk is about what some of the best practices are, some of the, some of the things that we do, to make sure that our app works, acceptably, well across, you know, different browsers. So that briefly is the agenda. So just to kind of see what are the challenges today for working with different HTML files and some modern technologies, right? What are the challenges working with that? And then we take a look at a JavaScript library called the Modernizer that helps us deal with this problem to some extent. There's a small little message that I want to deliver with regard to CSS3 vendor free fixes. We'll talk about political solutions. You haven't heard of that, you know, that probably sounds like a very complicated thing, but it's not, it's a very simple concept. So as we go along, we'll do some best practices around HTML5. So with that, let's quickly get started. So that, you know, really is the problem, right? The fact that for so many browsers, as an end user, probably this is a great thing. We are just spoiled for choices, right? We want to use the web and we have all these new browsers, all of them do a great job of rendering the web for us. It's a great experience as an end user, that's great. But as web devs, probably not so great. The fact that all of these browsers don't do everything exactly the same way, right? There's just a little bit that's a little bit different. And part of that, the plan for part of that needs to go to WPC, turns out before the HTML5 and a suite of specifications before that was formulated. There was these, these specifications were not as precise as they might have been. Some of the implementation aspects were left to browser vendors, you know? Browser vendors, some of them were not legal. So browser vendors could make their own interpretations of what a particular spec may, and they would just go ahead and do it, and, you know, but the result of them was each browser did it, you know, in a particular thing in a different way, and then we had to work around those issues. With HTML5, you know, that's something that's been fixed, or an intent has been made to fix that. HTML5's, you know, the typical desktop market spec is over 1,000 pages, you know? They have tried to go into excruciating detail about each individual aspect of the spec. You know, all these browsers are there. Not only do we have to worry about different brands of browsers, we have to worry about different versions of browsers, right? Not just supporting IE, Firefox, Chrome, Safari, Opera, and so on. It's also our specific versions of those browsers, right? So, and, you know, IE6 just doesn't go away, right? I mean, we've been there for such a long time, and can we just completely ignore it? You know, maybe there are scenarios that we can, maybe there are scenarios that we can't. The fact is, it's not completely gone away. So if you have to, you know, kind of deal with this issue, one of the things that you have to do is you could write your apps to, in fact, this is what traditionally we've been doing, right? We write our apps to each part of the browser. So, you know, of course, we write, here's the browser, and you look at navigator, user agent, and then we try to, you know, do some sniffing to figure out what browser it is, and then we try to write it appropriately, right? So, if you have to do that, what you're essentially doing is, you're taking upon yourself the responsibility of keeping track of what browsers have, what features, and how they're going to implement it. And given that we have at least three browsers that you probably want to target, like Chrome and Firefox, and given that all of these have so many different versions, and all of those versions have different limitations, that's a task for a superhero. That's not something that you probably, this is a little pie chart that shows the browser market share as of March 12th from netmarketshare.com. You know, regardless of who has what percentage, as web desks, that's actually one take away, right? But can we look at this picture and say that, okay, so if I support browser law, I'm done. Do you think you can say that to look at this picture? You can't, right? I mean, so IE 8 has about 25%, IE 9 has about 15, and Chrome and Firefox. So, it looks like at least these guys you probably want to handle. So, different browsers, different versions of each browser, and another thing that has been happening recently is that the cadence of browser releases has increased as well, right? How frequently do new versions ship? That's something that Google has kind of set up as a business for. Google Chrome started shipping like a tremendous space, and you know, it happens transparent to the end user, and just doesn't even know, like I don't even know what room I'm running right now, probably 17 or 18, and Firefox has started shipping and the greatest cadence as well. Microsoft has started increasing the speed, right? So, IE 9 ship March of 2011, and then a year later we have platform, maybe 5 or 910, in the, you know, it's out there. So, new versions are getting released. So, again, you know, just more stuff that we had to think about in hand. So, this is something that we've been doing, like we've been doing browser detection. So, we've been trying to write code which says, is the browser this particular brand, and is it this particular version, then I write a particular kind of code. That means that you have to essentially, you know, try to feature support. This is the sort of thing that can make grown men cry. So, what is the alternative, right? This is, what will work is basically if you can do feature detection as opposed to browser sniffing, right? Don't try to find code that looks something like that. So, for example, here's a level of code that's trying to attach an event handler to the Windows load event. So, here, let us learn a bit of code. How many of you have written code like this? Navigated our user's index of some substraint and then you write some code. How many of you have done that? Don't be shy. I've done that. You know, this works, right? And then we used it because it worked. Now, the problem with something like this is, here we are making assumptions about features based on the browser brand, right? So, we are taking Microsoft's job of keeping track of which browser has what features and so on. And I can tell you it's not an easy job at all. It's not something that we should be doing either. The problem with this is adding an listener is the W3C way of adding an event handler for a particular event, right? Attach event is Microsoft IE proprietary. So, if you don't want to do proprietary things, you can help it. And this is deprecated. So, newer versions of IE will not have, it is there right now, but it's a deprecated API. It might go away at any time. So, you want to do add event listener when you are in camps. So, this particular code checks if you are IE. If you are not IE, then it doesn't say it's adding an listener, otherwise it calls attach event. The problem with this is, with IE9, add event listener is now available, right? So, IE9 and IE10 support add event listener. So, this is probably a better alternative. So, here we say, window.addent listener is available. So, here they basically syncing for the existence of a particular property on a particular object. So, we are saying if the window object has a method called add event listener, then I go ahead and use that. Otherwise, I check if attach event is there and I do that, right? So, the benefit here is I really don't care what the browser is, right? All I'm looking for is whether the feature that I'm looking for is available in that browser or not, and if it is there, I use it. So, this might not seem like a major deal, but this is called as feature detection and here, when browsers get better and better, your code just automatically goes in the correct path of the preferred path. So, briefly make decisions based on features, not browser versions. You can check for a specific object and the third property of behavior. And another thing that this allows you to do is, if you detect a particular feature that your web app requires is not available, then you get to go ahead and you might want to load up upon this build. Basically, another library that supplements that particular browser that you have. Let's say you have a site which needs canvas support, right? And you can do this feature detection to find out if the current environment supports canvas, if not, maybe you will load a, you know, a call it, maybe something like a canvas, a flash-based or a civilized-based implementation of the application and the supply of the application. So, you get to do some intelligent things with your code when you do feature detection. But, you know, the KVI is, in fact, the word is probably, basically essentially the same code. So, it's essentially the same thing. So, I say, in order to add even listener, then I say, add even listener and I attach a handler for that and I, you know, basically show a different message. If it's attached even, then I say, you're not using standards-confined API, otherwise, what? So, you know, I go ahead and click this little link. It says you're using a standards-compliant browser because basically here it's checking for that add even listener, right? It's available then it works. I use IE's F12 debugging tools to change my document mode to IE7 mode. So, this is a pretend IE where you can hit F12 to launch the debugging tool and you can go, you know, over there and you can change the browser rendering mode. So, by default, it will be IE10 rendering mode, this is IE10, and you can change it to IE7, IE5. So, all of these modes are available. So, as soon as you switch it, then the browser will pretend like this is IE7, right? So, if I go ahead and click this thing now, you can see that it went into the other case where it goes to the else case and doesn't actually get this from adding listener and that's not available. So, if your site just works, right? Whichever is the most acceptable code path, it follows that. And that's great. But what if, right? In the earlier case, I was just checking for add listener and I could simply say window.add listener and what's that. But what if it looks something like that, right? That's where modernizer comes to the rest. So, modernizer is this JavaScript library that allows you to deal with this whole problem of feature detection in a very elegant fashion. That gigantic piece of code that you saw was code to detect whether the browser supports CXSB font page, right? CXSB has this feature called font page that allows you to use custom type pages. So, that code was to detect whether the browser supports that or not. Modernizer is a library, it's open source, I'll post it on GitHub. Which allows you to do feature detection in a very simple kind of code. So, again, we're not going to show that code what that looks like. So, that's what, that big piece of code that you saw there, that's what it looks like when you're using modernizer. You just include a script, it's actually in the top of your HTML and then you get to write code like that. So, there is a global object called modernizer that is ready to be your script and then you're able to do, you know, Boolean checks like this for various kinds of properties. For example, I want to check if Canvas is supported. I say it's modernizer. Canvas, then I go to that. Otherwise, I do the, you know, alternate thing. And, you know, this, this makes you, you know, here again, you'll notice that I'm not doing browser switching at all, right? I don't care what the browser is. All I'm checking for is whether the parent client has the support for the feature that I'm looking for. So, modernizer detects all major HTML files, the S3 features, so, and it goes like, you know, it doesn't really, for example, if you, if you want to check if the browser supports the video type, HTML5 video. So, you can say it's modernizer.video. Now, you can go one step more, right? You can find out what code is the client support, right? If it is IE, then it supports HTML64, it's Chrome, it supports maybe WebM, and so on, right? So, you can even detect that. So, it tries to, for example, with input types, with form types, right? Does this browser support the HTML5 form types, like email, URL, and, you know, and so on? So, you can check that. So, you can check whether this particular client supports input type, email, right? And then you can write code to do that. Or you can put fallback, which will do the script validation. So, that's what modernizer brings to the table. It's gaining quite traction. For example, Microsoft, modernizer is being shipped to the studio. So, when you're creating ASP.Opponent MEC projects, modernizer gets included automatically. Another thing that modernizer does is it adds support for, you know, for older browsers for IE67 and 8, which don't support the HTML5 semantic tags. So, let's say you want to, you know, for various reasons, you want to use semantic tags in your manual, right? So, you don't want to just, your HTML being just super tips, right? So, that's not something that you want to do. You want to use header, you want to use section, you want to use aside, figure, footer, article, and so on. So, the problem with using these new tags is that IE67 and 8, they don't know what to do with that. Right? So, basically just ignore the tag as it's just under the text inside of the tag. What that means is, you would have specified CSS, right? To style your background. So, if you have a header and a section, article that has a style with the CSS, IE67 and 8 just doesn't know it, right? So, basically your page looks sad. So, what modernizer would do is there's a little hack that you can put in the script that you can put to make IE67 and 8 recognize these tags. Basically, you just say document or create element of header and you don't even have to do that. As soon as you write a statement that tag can magically recognize the IE67 and 8. The hack, it doesn't matter. When you include modernizer, it gives you support for the similarity tags in IE67 and 8. So, that's a little extra points that you get. Let me show you what that looks like. So, I have a page here. So, that's the page, not much. I don't know how clear this is. Basically, here you have a few fields here, not this, I have header section and so on. You can see that there's a little border radius, there's a little drop shadow to show you the source for this. So, any standard page that you might use when you're using semantic tags. I have a header, I have section header and inside this you have a header in the H1. Here I have P and so on, right? So, again, I use F2L to change the mode. So, right now I'm centering in standards mode, which is IE10 mode. I'll change this to, let's say, internet for a cell. Or, in fact, for that, if you go and change that code a little bit. So, you can see right at the top, I included a script here. Script SRC equals modernizer 1.7, this is, I had put together this thing from time back. So, I think now the modernizer version is, I think, 2.2 or something. So, feel free to get the latest version. So, I've included this JS right at the top and then the markup works as usual. So, what I'll do is I'll go ahead and come in this thing out and then we go and refresh this. So, this is in IE10 mode, so it looks fine. So, I go ahead and take this to IE7 and then that's what that page looks like. Clearly, that doesn't look very nice at all. So, essentially what has happened is IE10 mode, it just includes all the data section, all the things and so on. It just renders the P inside it, renders the H1 and so on, but the rest of the stuff, it just ignores. And when I say ignore, it means that CSS rules are not getting applied. And all the CSS styling is getting applied. So, let's see what happens when I just go and include modernizer. And then I go ahead and fit it in. You can see that this looks more or less similar to what we had in the IE10 case, right? There are some differences. I don't get border radius, I don't get shadow, but that's fine. In fact, that's another thing that you can probably pass along is that web designers don't have this compulsion to provide pixel perfect fidelity across all browsers, right? So, I have a border radius, I have a shadow for all these elements. It has to be exactly the same way in IE6 and L8, right? Now, I'm here to tell you that it doesn't happen. So, people are on IE6 and L8, they don't get to see the box, that's fine. You know what, I mean, they'll never see it. They don't even know that it's there. So, they don't want to see it, they don't want to complain. Whereas, you've been putting so much effort to get that thing to come up, right? I mean, it's possible to make it work here, but it's not worth, it's not enough worth it. Or if your client comes and tells you that, you know, I absolutely have to make this work in IE6 and L8, add one more line and I'm gonna double your time. Because you will be working much on to make it work in older browsers, right? So, it's okay to not be pixel perfect across all browsers. Newer browsers, automatically the experience is richer, older browsers, not so rich. But, you know, stuff like Modernizer keeps you an acceptable experience, UX. So, this is not too terrible. So, that's Modernizer. So, this is another small appeal that I wanted to kind of make to the local community with regard to the CSS3 vendor preferences. How many of you know about, or don't know about CSS3 vendor preferences? Okay, we have a few folks, you know, briefly. So, CSS3 brings a whole new set of local presentation given within, right? So, for example, the box arrow and the border areas, CSS3 transitions, 2D transforms, 3D transforms. So, all of these are capabilities that CSS3 brings to the table. And all modern browsers have started implementing and, you know, the support is available. However, these specs are not final yet, right? So, these are still a working graph, right? It's not a forth recommendation yet. W3C has this whole, you know, sequence of states that specifications have to traverse, right? It becomes first, I think it's a first public working graph and it becomes a working graph and then it becomes candidate recommendation. Fourth recommendation, candidate recommendation. So, basically this whole, you know, process flow is there and it typically takes on the order of years for it to transition to this. So, why is this happening, you know? The W3C committee wants feedback, like real-world implementation feedback. So, how they get that is browser vendors implement these things in their browsers production, retail, and browsers. And then, you know, since they are not final yet, which means they can still change, how do you put that in the browser, right? So, as soon as I implement something in the browser or in any product for that matter, I have to support that forever, right? So, if I go and support feature aid and, you know, that's the thing about pushing something through the door, right? As soon as it goes out through the door, that's it. If there's a bug there, it's screwed because you have to support that all through the lifetime of that product, right? So, that's the same thing here. So, if I go and implement a feature which is not a final standard yet, and the standard changes, how do we deal with this whole problem? So, with CSS3, what happens is you can write and prefix your CSS rules with some code like that. For example, if I wanna do, if I wanna apply an animation to a particular CSS3 element, so I can say dash ms dash animation colon and I can provide the rule, right? So, webkit is basically for Chrome and somebody. So, I can say dash, webkit dash, a particular rule, colon value and Firefox is that in the most z dash, right? So, this is pretty popular, right? Everybody does it. And then the W3C version of that particular rule will be without a prefix, obviously. So, if it's a border radius, it will be just border radius and it won't be without a prefix. Now, the problem that I see in the industry is that folks are, you know, supporting webkit, right? So, everybody wants to put webkit and it works perfectly fine in Chrome and Safari. Firefox, IE, Opera, even if they support that particular, you know, vendor prefix version of that particular spec, they still do not see it because the developer has used only dash webkit dash in their CSS. In fact, you know, there are plenty of sites where I find that they could put dash webkit and they don't even put the W3C version of it. You know, like dash webkit dash border radius and there is no border radius specification. So, this practice is, if you're using vendor prefixes, always put the W3C version of that particular rule last, right? Because that's how browsers work, right? If you have a particular rule appearing multiple times, London specification vertical rule, the last one wins, right? Whichever is specified last, that kind of overrides your previous spec. So, always make sure that you put the W3C maybe last, right? So, the appeal is, you know, make sure you put all browser vendor prefixes, right? So, if you're using CSS3 transitions, put dash MS dash webkit dash MOS dash O dash O dash is for operator dash, that's it, webkit versus query in Chrome. So, make sure you put for all browsers. Otherwise, what happens is, you know, the browser that you do to support becomes a standard, right? Becomes a pseudo-standard. In fact, Microsoft and Firefox, Mozilla had basically, you know, probably a couple of months back, made a proposal in W3C that they're gonna start recognizing dash webkit in IE and Firefox. You know, you don't want that to happen, right? We've been there. We've been, you know, we've lived through those days where a particular browser became a pseudo-standard and everybody, you know, started implementing their browser so that it works like that. You guys know what I'm talking about? IE6, right? IE6 became a pseudo-standard because Firefox, if it has to remain competitive, they have to do what IE6 does. Even if it is counter to the W3C spec, right? Because everybody built it to IE6. Now, we don't want Chrome to become the new IE6, right? So, that's just gonna appeal to that community. We don't just adopt, and that gives you a good experience as well, right? So, for example, other browsers get to see the, it is get the same rich experience as well. So, you don't lose. So, with that, little yarn, thought I quickly talked about polyfills and shins. So, you know, this sounds like a fancy term. This is what the problem that it tries to solve, right? So, there is this swanky feature in your browser, right? And we are really happy, you know, we want to implement it. But then along comes old browsers and things go nuclear. So, what do polyfills do? Polyfills are basically simple libraries, right? They could be just libraries that provide support for a particular W3C spec. And give you a, you know, basically provide support for that in old browsers. The fidelity of the user experience may not be exactly the same. The best is if the browser supports that spec literally, right? But in case the browser is non-supported, polyfills, you know, backfill does it. It's called polymorphic backfilling, which sounds even more scary. So, the idea is you get to leverage new specs, like canvas in your app, and you still get to not lose your user base if you are on a world of browsers. Streams are similar to polyfills. Only thing is stream is the other library. Typically, the polyfilm typically will implement a W3C spec, right? So, if there is a specification for WebSockets, there might be a polyfill which implements that API completely in your library, right? So, you get to write old to that spec and not worry about whether the browser supports that particular feature or not. So, I can write WebSockets code and not worry about whether the browser supports WebSockets. So, in older clients, polyfill would probably use flash or probably use zero light to provide that, to supplement that functionality. But you get to write the same code, right? You don't have to write different code. Streams are typically libraries which tend to be a somewhat higher level abstraction on top of some feature. For example, there is this stream called this AmplifyStore, which is a JavaScript, AmplifyJ is a JavaScript library. There is a piece called StoreInit, which provides client-side storage capabilities, right? There are multiple client-side storage options. In fact, my next talk is gonna cover that. Like DomStoreIn, indexdb. So, basically, AmplifyStore is an API which is built on top of that, right? So, it will use whatever is available. So, if DomStore is available, it will use that. Indexdb is available to use that. But it has its own API, it's not a WPC API, right? So, that's what we mean when we say shims. So, you can go to that particular URL. This is a GitHub page maintained by the folks who wrote Modernizer. They're really used to polyfills and shims that are available for major WPC specifications. So, bid.lead slash polyfills. So, like any open source, most of these tend to be open source, like any open source project that you use, remember to vet the code. So, you can go there and do the key way yourself. You may have to support it in the future. So, the standard KVX apply, right? So, in a way, you use a polyfill and shim. So, I just wanted to show a quick demo of what that might look like, right? So, this is basically a simple page that we put together which allows you to doodle on the page, right? So, this particular area here is a canvas. It's an HTML5 canvas tag. So, I can just go ahead and do that. We can draw. You can see that there's no plugins, they're just a canvas. Now, let's see what happens if I use an older version of the canvas. Let's say I go to Internet Explorer seven. So, IE seven definitely does not support canvas. So, you know, I can, so, it turns out I can still draw on this. And this is running in IE seven mode, right? So, how does this work? If I right-click, you can see that now I'm using Silo-like, right? In the earlier case, I was using native support for canvas. So, how is this thing put together? So, if you look at the markup here, I have a canvas tag and I have a Silo-like object tag here for instantiating the Silo-like plugin. And then I use a little bit of script at the top to figure out which implementation to use. So, in fact, I use modernizer here to detect whether the browser supports canvas. And if it does support canvas, then I use the canvas tag. Otherwise, I use the Silo-like motion. And this plugin I got from that, you know, in that location, the bit.nx-lacrimonitals. Let me show you what the code for this looks like, right? So, there's a fairly, but I just want to show you the code drawing routine. So, it's not much, right? I'm just drawing lines. So, this code here is completely, you know, that the canvas API, right? I get the 2D context. I set the stroke style, begin path, go to line 2, and then draw the line, right? Now, this is completely independent of what is being used, right? If it's the canvas tag, this will work, obviously. If it is a Silo-like component, this still works. Now, the reason is because that's a polyfill, right? They've implemented the canvas API on top of the, on top of the Silo-like plugin. So, that's what you get. And the browser-specific code is essentially, you know, just, for example, this is the only method that I have kind of abstracted that way. So, I have a get-canvas method where I check that. So, if canvas is available, then I return a reference to the canvas object. If canvas is not available, then I basically return a reference to the, you know, the Silo-like canvas instance. The rest of my code in that folder.js, nothing changes. It's exactly the same. So, that's the benefit of using polyfills, right? So, you get to use, use effects and not worry about older browsers, or at least not worry about too much. Yes. So, the polyfill is going to be program-wide. It doesn't shift out of the box. It doesn't shift out of the box, yes. I mean, in this case, the polyfill I picked from that site, right? So, it's running through? No, it's not. Okay. If some individual out of the large numbers of their art have invented it, then we're just using it. Um, so, if we have time, I can talk about, talk about video and, you know, what is the story about compatibility for HTML5 video, or if we have questions, we can take another 12 minutes to go. Do we have questions? The question is, are there polyfills available for CXSE? We can get it out. So, do we have polyfills available for every single CSS3 option? Definitely. And if, yes, what was the second part of the question? Why don't we use CSS3? Why don't we use CSS3? See, for CSS3, the story is slightly different, right? Like I was saying earlier, it really depends on how critical a particular CSS3 feature that you're using in a web app is for your app. Now, see, for example, let's take, let's take your website for somebody, right? And you have a logo, right at the top right corner. Would you say that the logo is a critical piece of, you know, piece of that site? It absolutely is, right? If the client doesn't see the logo on the IE8, they're not going to be happy. Now, let's say you use Canvas there for that. First of all, that's probably a bad design choice. Just probably have used an image or something. But in that case, you absolutely have to go the extra mile to make sure that the thing shows up, right? On the other hand, if you have border radius and box shadow, it's completely fine if folks don't see it. So it really depends on the criticality, right? If a particular CSS3 is completely critical to your site, there are, your mileage may vary depending on what you're trying to use. Let's say you're using CSS3 3D transforms, you know, you probably will not find a polygon for that. Right, on the other hand, for border radius, probably you will, or for opacity, you will, right? So it really is a case-by-case basis. But in general, I would suggest that, you know, don't worry about it. Go ahead and use all these CSS3 underplay fixes for your site and, you know, provide their experience. Make sure that it gracefully degrades for older guys, right? So that it's not completely unusable, right? As if it's a lesser richer experience, that's totally okay. What about, sorry. So the question is what about, so if you talk about CSS3, what about HTML5 specs, like geolocation or WebSockets or IndexDV? So again, so for those we do, you know, you'll probably have better luck finding polyfills. So that's what we'll be doing. That thing too has a huge list of polyfills that you can, you know, pretty much for everything that you can imagine. So yes, there are good polyfills available for you. A vast chunk of the HTML5 specs. Yes. So in the admin page, it's also particularly for us. Yes. When you go back on to IE7, okay, talking about HTML5, I can't just talk about those things because I don't even know what they're doing. So is it safe to assume that you've been written using CSS and a tag that you like by your selectors tag, please? Why is your selectors tag based on HTML5? Will you do something like section to tag them to come up with? So the question is, I think this has come out completely in the area. So if you're using a tag based on HTML5, then would it help you use class based selectors? Okay, so the question is, in the example where I had used semantic tags and then my target CSS, we found that in IE7, without the modernizer included, it looked pathetic. Now, would it, so basically in that case, I think I'd use IE based selectors, it wouldn't have made a difference. The question was, would it have made a difference if I had specified a class and then applied the class to the tag? Would IE6 and IE8 have a better number than it would not? How about the page question? That means that what's the performance of the modernizer was very large, like 18 and half years. See, modernizer itself doesn't do a whole lot. In the sense that all it does is, when you load the page, all it'll do is it'll try to do feature detection for a vast chunk of features. In fact, the latest version of modernizer, you can get just what you want. So for example, I am not interested in finding out whether the modernizer supports the CSS 3.0. I don't even use the CSS 3.0. So I should modernize it, try to find out and support it. So that particular page where you can customize and modernize the download based on the checkboxes, which say which features you want to sniff, and then you get a customized JS file which says only those features. So that's all it does, it just sniffs and initializes a bunch of properties for instance, if it's true, if it's supported or false, if it's not. The semantic stuff, you don't need to worry about it. All it will do is document or create an image for all the bunch of semantic tags, probably 20, 30 tags. That's nothing. Yes, modernize. Question is does modernize or support mobile browsers? Yes, it does. The question is, is it a good idea to support, to use polypads to support older browsers because people then get the features of older browsers that never want to upgrade? Yeah, maybe it's a good reason to not say what polypads are. It really depends, it's really critical to your app. But then it's generally not a good thing to put a website that says this looks best on high-level, low-level, low-level. So polypads gets you around that problem. So you older guys, they get some experience, they won't get the same experience for example if you have canvas with silver light, there are problems. The user might not have silver light installed, or they might not have the correct version of silver light installed, right? And then they have to go, there's a different experience, it takes you out of the site, you have to go and download the plugin, and it's not the same thing. So, but still they're not dead in the water, right? That's... So you don't see the problems when you monitor that wide range? Yes, so the observation was polyfills can be really big, depending on what the feature and question is. For example, canvas API is pretty big. Usually they're just forward to the silver light or the flash, but still that overhead is there. Maybe then you can use something like resource loaders, which allow you to conditionally load script and CSS. Yes, yes, yes, yes, yes, yes, yes, yes, yes, yes. So you can use that so that folks who have water on a modern browser don't pay for the polyfills, probably one minute. Do you guys want to talk about video? So, you know, with Michigan, we'll find another interesting thing but probably the most visible part of the solution is that support for video and audio. Like everybody says, just in 5-0, now you can do videos without silver and flash. So that's great, right? So this is how we used to do video before. And that's what we do. That's what it looks like in the HTML5. Much less code. I can put it on a slide. Now that sounds too good to be true and turns out it is too good to be true. The sad story is the Codex story. It turns out there are different codex. So video is always compressed, right? You won't be uncompressed video in probably a five minute video, probably in 500 banks. So everything gets compressed. Now the question is, how do you compress it? There are different standards for it. So Internet Explorer and Safari, you know, both on Mac and on iOS devices, they support H.264. H.264 is a very popular video codec. It's a very high quality video codec but it's a codec which has, you know, paid-in issues or there are royals. So if you're using H.264 in a product, you need to pay somebody some money. So Firefox on principle, since so far have supported Theorab as the video codec. So if you have a video with H.264, it will not play in Firefox. And recently, just last week, probably a couple of weeks back, they made an announcement that Firefox won't start supporting H.264 event. So this is actually probably, you know, very similar to the pseudo standard case, right? Firefox has started adopting something simply because it's really popular, right? Which is unfortunate because there is no consensus around codec. Chrome, you know, they want to go ahead and use WebN as the, you know, video codec of choice. They have threatened to stop supporting H.264 but they haven't done that till this point. But the official question of Chrome is, use WebN for your use of H.264. And fortunately, WebN is supported only on, I think, Firefox and Chrome. So, you know, so this is great, all these browser vendors are having a fight. What do we do, right? What do we do so that our videos work across different devices? You support everybody. We've been there, right? That's what we do anyway. Day in, day out, we support everybody. So, this is what, but fortunately, the W3C spec, you know, I think they had, they had the vision to provide this capability. So if you have video tag, you can specify the source multiple times. So you can provide a source child tag and here the same video is specified as MP4, org and WebN, which are basically H.264, org and WebN codecs. And the browser will simply pick whatever it, you know, it can, whatever it understands. But what about old browsers, right? Now, we are talking about HTML5 here. We're not talking about, you know, we're talking about the video tag, right? So, you fall back to Silverlight and that. So, this is kind of funny, you know, like the levels of fallback that we do, right? You know, sometimes I look at code like this and it's like the exception movie. There's a dream and inside that dream, there's a dream. So here, if you think about this, you have the video tag and here this is the video source and you have to give that multiple times for different browser brands and then there could be folks who don't know about video. So we give object tag, which could be Silverlight or Flash and then they might not have similar to Flash. So object tag can have more stuff in the middle here. To provide fallback, the folks don't have that, right? So what fallback would you give for folks who don't have that, you put a div here that says get a nice browser. So, two minutes, so maybe I'll quickly show what demo it is. So this is basically a page where I have a HTML5 video. If I do a view source, you know, there's nothing fancy going on, I just have a video SRC is that. What I'm gonna do is launch Firefox here. And I don't, you know, open that page and you know, that's probably not what we expect. This is a video tag and Firefox has supported the video tag for a very long time, right? So what's the problem? The problem is, this is H264 video. This is Firefox likes Fox. So I have another page here and of course, now Firefox is able to work with that. And all I have done here is basically I have the OGD as well. Now that's great, but what about older browsers? So let's say I open this here. So as we know, it works fine. So I use my devogging tools and go to IE7 and that's what that looks like, right? So for that, you know, this works in IE7 mode and the reason why that works is because I have my source tags for IE and Firefox, IE for the Safari and Firefox, and then I have the object tag for the single line plugin. So that video that you saw here was basically single line. So that's the story with regard to video, right? And same thing applies to audio as well. So here are some resources that I'm probably leaving you with. So these are some interesting books. Introducing HTML5 kind of gives you a well-rounded view of HTML5, basically HTML5 is not all the hype, right? So this is from a publishing firm called Book Apart. So they are, generally they put really good high-quality books about web development. CS3 for web designers is also from Book Apart. In fact, much of the content that I looked for in the session was from these two books. The nice thing about HTML5 is that it's a really small book. You can read it quickly. So they tend to be very brief and focused, right? So that's my blog, email, and so on. So that's what it is. Thank you for the session. If you have more questions, I'll hang around and get back to you in a minute.