 A quick introduction. I am a Sovik. I run a small web design studio in Delhi. It's called Mirage. It's a two person company. We take client projects and I skip all the next things. I have a few things first. I want to just clarify the objectives of this session right at the beginning. One is I want us to revisit the design of web. How was web conceived? How is it meant to work? And go a little bit into that. From there we want to move on to progressive enhancement. Why is it important? Why is it good? From there we want to write code in a manner in a progressive enhancement manner. And finally we want to do peer review and learn from each other's experience. So that is the overall objective. And if your expectations are different as I set out some of the more expectations here. If your expectations are a little different, please speak up. Maybe I will be able to change the course. We have some time we might be able to change the course include a few things that you want to know discuss a few things that you want to know. Okay. Learning syntax and making pretty interfaces is not the objective of the session. Okay. I want to clarify this. When we move on to CSS and things like that. It's okay. You can take time to make things good looking, but over here we want to quickly move on. Right. And the objective is also not to tell you how HTML is written or how JavaScript is written. So I'm expecting that you have a little bit of a syntax knowledge right at the beginning. If you don't like the show of hands so that everyone almost had it. And just in case you didn't show up your hand, please slowly move to a seat next to the person who showed up his hand. Okay. So that you can just start programming with him and learn about the syntax. Next agenda. So first 25 minutes I put in for zoning in before we code it. Start coding, right? A few things that we want to do, few activities you want to do. We want to start understanding the project in the 15 minutes. After that, we'll start developing the project. We take a break after we have done with our HTML. All right. And then we move on to the CSS JavaScript. And at the very end, we zone out a bit and talk about a larger picture, a few closing points and things like that. And I have, I want this, the conduct to be very, very, I will embrace by everyone. Really. I want you to be asking questions. I might not know the answer. There are other intelligent people in the crowd. If you know answers, please contribute. All right. Code or at the very least assess people who are coding feedback, keep things constructive and mutual respect is very important, which basically means when you're giving feedback, when you're taking feedback, please be respectful. Right. I want to start up with this question and this question only I added yesterday, because when I took the name of one dangerous browser, I got to answer who cares. No one cares about it. So I want to ask this question. Why do we not care about some web browsers? Quick answers. We won't not be doing it. Because it's outdated. It's beyond the support timeline. So you don't want to code. Very few people are using that. Okay. We don't get a proper output. All right. So the thing is buggy. Probably. The ROI is not worth it. Sir, are you a manager? Yes. Yes, I, I, I, maybe, maybe the ROI is not worth it. Okay. Just hold on to this thought. We'll come back to the question right at the very end. Okay. So I want to move on to another question. What's the web? Maybe they take it too much time for us to define it. I'll just jump ahead. So Tim Berners-Lee, he was a scientist. He started this a little bit of history. 1989. That's pretty old, right? In the world of technology. Things change so fast. And it was built upon some amazing design principles. How many of you have actually gone inside the W3C documentation of the design principles of the web? Has anyone gone into it, looked into it ever? One, one hand. I just want to highlight a few of the design principles here because I think they're really important. And Tim Berners-Lee, he wrote a document in 1998. It's available at the CURL. You can get their presentation later. Also probably look it up. And he said that people keep talking about these principles. I think this will be a starting point. Let me jot down a few of the things which are my personal views right now at the, at that point of time. And he said the first principle I think that the web that he kept in mind while creating the web was simplicity. Okay. That the things have to be very simple, as simple as possible. The next was modular design. Most of your coders, you don't need to be explained what modular design is. Basically, you take your entire piece of code or you take your project and you divide it into loosely coupled modules, which within themselves are very tightly coupled, right? So that you can take a module out, put another module in, and they should, there should not be very less overlap between them, right? The other thing that he said that being a part of modular design is also a very important principle. The fact that you are a part of a larger thing in which your own code or your own contribution has to be a part of that modular system. That is very important. So if there is a modular system and you walk in and you push in something which is not modular, then that's a problem. Okay. Another point was tolerance. And this is also known as the robustness principle. If you have come across this, it says be liberal in what you require, but conservative in what you do. Does everyone follow this? What it tries to say is, if you're taking any input, or if you're asking for any information, be very liberal about it. So be tolerant about it, right? So if I want to give a X amount of information in a different format, for example, there are so many hundreds of date format today. There are hundreds of languages today. There are hundreds of different ways you can give input today. If I want to give my name, I can give in 10 different languages. Probably, if I want to give my credit card details, as an example, I might put a space, I might not put a space. If I want to write an HTML code, even in that, I have a huge flexibility. Really, when you see that when you write some syntax, your browser will throw an error. It'll accept your HTML code and try to render the best page possible. That is a very important, and I wanted to spend some time in tolerance. That is important. Decentralization is don't have a single blocking point. And a test of independent invention, I don't think we have some part of it cropped away, but that's because right outside, there was an Adobe update, it just took away all my phones. Anyways, but test of independent invention, basically, some cases, if somebody else already has invested in your system, would their system work with your system? So is your system independent enough that someone else's system will also work with? Clearly, you can go and read up. This is not something that you're going to spend a lot of time on in the things we do, though. But some part of it is important. And the other important thing was, and this is extremely important, says principle of least power. And what it says is that if you write a document or I'm giving a very rigid example here, if you create a document in a technology, which is very low powerful, very low powered, it can be consumed in a much more wide wider fashion. So for example, then the example he writes in that same piece of text is, if there is a Java applet, which does some kind of functionality, the only piece of software that can decode it and make sense out of it is Java and the applet's engine that is on it. If you write a document, which is so low powered on so simple as HTML, there are thousands of different engines that will be able to make sense of that document and consume it. And that is one of the reasons he goes on to say that I did not intend HTML to be a procedural language. I wanted HTML to be a marker plan with so that there can be thousands of systems that can read the code and interpret it and make use of that. All right. Does this, does this make sense? Because this is very important. Anyone who opposes this, I don't like this. I want to write in a very complicated language, but I want, doesn't matter if it's a proprietary language. I don't, to reach out to a wider audience is not my goal. Is there anyone with this mindset? Because that is against the principle of the app. There's nothing wrong to be in that mindset, but that's against the principle of it. All I'm trying to point out. Right. Further from there, W3C went on with a lower range of principles and readability, timeliness, what is there, go and read about this. I'm not going to spend time on these. But further and they went on to a mission where they said that we want web for all, web for everything, web for a rich interaction, data and services and trust. And that is important web for all and web for on everything. And because of these principles as a result today, it has been around for more than two decades and it's been there in so many devices. Like every handle device that you think they're connected to the internet, refrigerators get connected to the web, your, their browsers, their cars, every place that you can think of, they can get connected to the web because of these open principles. They said, I, we want it everywhere. We want it very simple so that anyone can take it and consume it. And today that is why web has been turning complicated, right? This is a good thing for us. But challenge for us is there's a fragmentation of client. There are too many things that are consuming our HTML pages today, right? And it's not just the browsers anymore. There are plenty of things that are consuming our website today. And for a long time, what we have done is how have we coped up with these browser fragmentation. There was I Netscape initially very early days, slowly moved on, Firefox came in, Safari came in, Chrome came in, other browsers are coming in. How did we cope up with all these things? Generally, I would say it was graceful degradation. That is the way in which we did it. And graceful degradation, what it means is you take the most latest web browser. Okay. For example, let me talk about today. I take say Chrome and I'm not advocating Chrome, but let's say Chrome. I'll make my website on that. Put in all the amazing things. You see SS3 use HTML5, use JavaScript, make it slick one page single page application, right? We make all that. And then we think, okay, let me just go ahead and test on Firefox. Yeah, most things work. There's this one point that doesn't work. Oh, let me just patch it. Let me just go and go to Internet Explorer. 10 things don't work. Patch it, patch it, patch it. Let me should I go for a older Internet Explorer? Yes, let me go to IE9. Few more things don't work or few more things do work. We are in a different way. Oh, my God. Patch it, patch it. ROI goes down, right? I ate very low ROI. You don't want to do it anymore, right? Who wants to patch a world browser? And with so much, so many different kinds of browsers available today, we can't cope with that method anymore is what I'm trying to propose. And this is not a new proposal actually. In fact, there are a few more points that I have. You have only, if you have been only testing in browsers, there are text-mode browsers. I don't know if you have actually gone ahead and used any of them. There are screen readers for people who cannot see. There are read it later services that have come up today. Insta paper, pocket, okay? They go to your website and just save the copy of your web page for that. You can read it later. Flipboard has started consuming it. Google has always been doing it. And you have always been later bothered about the fact or no SEO anymore, right? SEO is not there. I am not getting indexed on Google, right? And if only the things that are consuming, that is not a variable. There are more variables. Like even if you say that I'm going for devices, hundreds of devices, different capabilities, all of them, right? Even if it's the same browser, maybe you're running Chrome on five different mobile devices, maybe one has a older version of Chrome, maybe one has a new user, maybe the device capability is different. It has a function differently. The screen dimensions are changing. The method of interaction are changing. You had a numeric typepads initially. You have keyful keyboards, Quoty keyboards. Now you have touch interaction. So even the browser remains the same. It's actually working across a variety of devices, which have different ways of interacting. And this thing is only going to get worse, right? Does anyone think that it's not going to get worse? No one thinks. And 2003, it's a little ironic that 11 years later, after this presentation of inclusive web design for the future by Steve and Nick, 11 years later, also in the world, we have to promote the fact that progressive enhancement is important. Okay. And what is progressive enhancement? I'll just come to that. And this is the presentation at which they actually gave a term to a different kind of way in which we start coding our websites. They proposed it, gave a name for progressive enhancement. And the method is this, that what is the most important thing in your website? Most important thing in your website? Content. Does anyone read it up? Content, right? So you take content, then you mark up around your content. That means you structure your code, you structure your content, right? Once you do that, then you add styles, right? And once you do that, then you add JavaScript, right? And this is the method in which you follow and you do your coding practices. You never thought of browser. You don't have to think of browser. You have to think of content, you have to think of HTML standards, but not a browser because you don't know what kind of browser will be consuming it, right? If at any point of time you start visualizing, oh, my heading is going to be this, this big bold thing in the center. You are assuming that your heading or your page is actually going to be put up on a display. It might actually not be right. Today in the villages of India, people are accessing web on SMSs, right? That's a big thing in the villages of India. There are services that have come up. So assumption that people will always be able to see our content, even forget from accessibility purposes, right? The fact that outreach purpose, we haven't covered majority of the world yet. The web hasn't covered majority of the world yet. And people are still accessing through very, very, very low-powered devices, just about being able to communicate on the web, right? So quickly, what is the web again? I don't want to define over there, but very specific points. We have a protocol, right? HTTP is there. HTTP serves URLs and URLs are what help you locate resources on the web, right? Address them. The other thing is files. They are mostly accessible CSS, just when there are media files on the web, right? So these three things put together generally make up the web. So here I want to introduce the workshop project, okay? I wanted to keep a very small project, very, very, very small so that we get more time on this. So I thought that I do the back-end. I'm your back-end guy. You're the front-end guy, guys, right? So you all interface your code with my back-end. And the functionality that I'm trying to provide is I'm trying to let people just store their expenses, okay? As simple as that. Making an expense of that. So what is the functionality in the app right now? It's a person can sign in, can enter a new expense. The expense gets recorded. He can edit or delete that expense and he can sign out. Nothing else, all right? That's as simple as it is. Anyway, it's okay to use this. And I take my liberty and call it has expenses. I might have actually done a few IP violations by calling it has. Now, what are the knowns in the system? Can anyone tell me what are the things that you can be very sure of that the system will have at least between you as the person who is creating the website and publishing the website and people who will be consuming the website. Between that, what are the knowns in the system? Can anyone just point out a few? Browser, okay? User is the known. So let's talk about, okay fine. Let's pick that also. User is the known. Of course, there'll be a user. There'll be a user. There'll be a browser. Transaction. Do you know that transaction will actually happen? You don't know. If after it starts being used, it may happen. Any other quick points here? That is, we are going to design an API right now in a way. But before you take a decision on that, you have to figure out what are the knowns in the system, right? Otherwise, how will you, for whom will you make an API? What will you make it for? What purpose will you make an API? Think about it. Let me give a simple thing. According to me, the only knowns in the system are that there's a server. There's a client. They talk over HTTP, right? And there will be a browser there. And the browser might be of any kind, okay? And let me simply call it client, because when, as soon as you hear browser, you think Chrome or Firefox. So that's why I'm saying client, server, and they'll communicate over HTTP. And the fact, the very basic minimum basis is that the client will accept an HTML file and will be able to figure out what to do with that. Am I okay with my assumptions here? Okay. We can't assume anything beyond that. We can't assume the fact that there'll be a mouse pointer or a screen or a keyboard or the fact that what viewing distance that the user will be sitting from, things like that. They are all unknowns in the system when you start a web project. Agreed? What about, how do I do this? Can we do the a fist of five? A fist of five means, basically, you raise up your hand and put on the rating of one to five, how much you agree. So five for if you agree with me, one if you don't. So can you just do a fist of five? So for the fact that these are the knowns in the system, agreed? Okay. So most of you almost 100% five means 100% agree that yes, only these are the knowns in the system. There's nothing else. Those who did not, did you want, do you want to give any other point that you think want to add to the knowns in the system? All right. No point. First activity. We want to identify purpose and prioritize our goals over here before we start on the web project. And what can our goals be? I've told you the purpose before. We want to run an extension app. But in our goals, I feel that these are the goals that we need to prioritize. Whether the fact that our content is going to be consumable is our system going to be functional is the final thing going to be aesthetic. That means good looking. Is it going to be fast? Is it going to be accessible? Is it going to be reachable or locatable? If you have to prioritize this, or if you want to add anything else, right, you can add any more goals in this. If you have to prioritize, what is the most important of this? Speak up. Out of all these, most important. This accessible. The fact that the content is consumable. So reachable is first priority over one. Okay. Let me say this. If I can't reach your content, how will I consume it? Do I have a point? If I can't locate your content, I can't consume it. I'll not reach your content. Agreed? Should I translate it to technology? Yes, you are right. Yes, so that's implicit, right? I'm trying to make everything explicit here. So make it explicit. If you think that is implicit, take it out. That's a no, because we are going to have a client as our server. That is definitely unknown, because you are talking about SITP. SITP will support URLs, but what are your goals while you're creating the design of the system? What should be the priority number one in serving? Will you have question? Would you first spend your time or would you spend your time over creating good content and just totally not think about whether it's accessible over URLs or not? Or whether you prefer to give a URL access to it than consumable? Let me give you a solid example. If you have a single page application which does not update the URLs in the browser, fail according to me. You're giving the content, you're not updating the URL. Fail, according to me. Because you cannot return to your state, you cannot locate your state, you cannot link to your state. These are the bases and I told you what the web was made of. SITP is there, URLs is there and files are there. You're giving a file, but you're not giving URL, you're breaking the web. That's why I think this is first. Most important thing that it should definitely have is a reachable thing that is according to me. Let's see, what is point number two? Functional over content. Content more important, functionality more important. I think content. Why? If I don't give you content, how will you perform functions? Or maybe you've misinterpreted what I wanted to say. Reverse, I mean, if it's consumable but not functional, that is again. Okay, let me give you an example. If in the expenses app, I can see what my expenses are, but I cannot edit an expense. What is more important? Should people be able to only feed data to the system and edit expenses or at least see the expenses? That is more important. Rendering is a particle function. So let me point out, when I say consumable, I mean well-structured HTML. And only if you have a well-structured HTML, will you be able to render it? And only if you're able to render it, after that people will be able to perform functions on it. Does it make sense? So same way of thought, it's reachable, but it doesn't have content. It's useless. Absolutely. That means consumable is more important than reachable. Consumable? Okay, let me take a step back. If you read something and there's nothing there, what's the point? I think we're doing that. What can happen? I'm saying what is one, I'm just prioritizing. I'm not saying what happens the second. The thing is that I need to build this app, right? Okay. My priority is not that 10,000 people use the app, I need to build it first. Agreed. So is it content, the most primary thing for you as a developer or as a product person? Did you realize or did you rethink that when you're developing, at the point of developing, you're continuously making use of URLs to access your even development files? I think maybe the definition gets skewed. Maybe, maybe, maybe. So reachable as we said is being able to reach a certain state, not just being able to reach a website. So as an example, I think this is more of seeing that every point would give you all the goals in mind and every stage of the app. It does not mean you book a URL first before writing a website. It basically says that the goals should be at every point you should focus. Or rather, when you put out the product, let me say this, when you have the final stage of the product, you must in this order ensure that your product is reachable, it has content, it is functional. What about the rest? I think if you're developing a new content or a new functionality, you should make sure it is also reachable. Reachable I think is always first in my opinion. So you can deliberate over this. So we are taking too much time on this. I just speed it up a bit. Okay, just for the interest of us getting into code. Anyone who wants to comment on these three are the unknowns. I think my viewpoint is we should be, everything on the thing should be addressable and reachable. If you can't reach it, you can't use it or you can't even consume it. Then you make sure that once it is reachable, once the user is able to reach your thing, you are able to provide him the right content. Once you get the right content, he's able to perform the functions. At the very least, do the work that he has come to do on the website. It could be just to consume the content, then the thing ends there. But if it could be to do other steps, like in our case, we would want the person to add a new expense or edit the old expense or change things, then he should be able to do it. These three, any ideas on these things? Accessible over fast, fast over accessible. I think web for all, web for everyone, means you need to make sure that everyone is able to access. Doesn't matter, you are differently abled. That is one form of accessibility. Many other forms, you might not be differently abled. Your devices might be low powered, old browsers. Anything else? It should be able to access that. I think fast is a part of accessible, because if you have a slow internet connection, for it to be accessible, it needs to be fast. Maybe it could be a subset. It may not be, I am taking it to be, let's make all these modules are okay. Let's not overlap these in a way. So once it is accessible, I think it will be fast in aesthetic, fast and then it should be pretty. So if a person has amazing internet connection and latest browsers, he gets all of it in a way. And also if someone doesn't get all of it, doesn't mean that the thing is not aesthetic. There is always some aesthetic. There is nothing known as absolute zero in aesthetics or absolute zero in speed, unless the internet is actually zero. So it always has some aesthetic. How much time you want to spend? How good do you want to make it from the aesthetic point of view? Best browser, best device gets all of them. But if you build it from these at this level, if you prioritize this while building, right at the beginning, maybe at the moment you do reachable and consumable, you have a product. That is at least reachable and consumable. Then you add functionality, you have more things. And so on and so forth. Okay, so I talk a little bit about the protocol because I think this is always a spirit of a bit. We have four methods, get, put, post and delete. Unfortunately, I won't say unfortunately, but I would say it just so happens that today we are only fighting between get and post because the other two, put and delete, are not being implemented by most browsers and things like that. But it's very important to know the difference between get and post. Can anyone quickly tell me the difference? One of you, sorry? Get, simply I want to get the content in very simple words for everyone. Post means I want to make a change in the system. It could be created, it could be added, it could be deleted, it is making a change in the system which is not done by get. So get will never make a change in the system. Post will make changes in the system. Keep this in mind always at any point and I'll give you a very prime example over here. Logout should be a post request. You should not have a link, a link, a tag which says logout click and you have logged out. Why? Because it's changing the state of the system. Does it make sense? This is one of the biggest mistakes that lots of people make throughout ATIPS for the wrong reasons. Post is only associated with forms for people. Generally for start, as a starting developer I was like forms hai to post karna. Is the thing, forms post, right? But that's not the idea. The more basic idea is making a change in the system. Then next thing is URLs are for people who want to design the best URLs as possible. And there's a document that again says cool, URLs don't change. If you make something locatable and addressable, never change it. Keep it there for eternity as long as you can serve that page for as long as you can. So I want to come to this small activity. We want to give URL to everything. Can we quickly, quickly, I'll give you five minutes max. You know what are the things that we are doing in the system? We are going to have a login. A person who is going to sign in. Person who is going to be able to see his expenses. Person can make edits to his expenses, add an expense, delete an expense, and sign out of the system. Can you quickly work me out what can the URLs be? Five minutes, please. Two of you together would be nice. Just quickly self-organize. Because I think this is something that Sorry? Okay, so when I'm saying URLs, I don't want just tell me post, give me a URI in a way. Don't just forget the domain part. Okay, everything beyond the domain, what it should look like? What would be the most human readable for people addressable and easily understandable URLs? Domain is the entry point. Yeah, so domain, just avoid the domain in there because you always have the domain. So I want you to decide the things inside because in domain you cannot control. So you are required. You have something in here? Slash login, slash my expenses, slash add delete expense. Okay, so I have a quick, thankfully someone has done something first and I'm going to just jump ahead because we want to get into code quickly. Someone says that you have slash login for signing in, all right? Slash my expenses to view our expenses, all right? Slash add expense to add an expense. Slash edit expense, slash 10, 10 being probably the primary key of our object over there. One part of the URL, when you're designing URL, one thing that you should consider is at any point the URL should be hackable. So if you just top off the last part, it should still make sense, right? So if you just top off slash modify expense or edit expense, slash 10, I top off 10, slash edit expense, it does not become a complete thing. So you just switch the order because slash 10 means, show me the object. Slash 10 slash edit would probably mean I want to edit this object, make sense? And I can chop off the last edit part and still have a valid URL. Similarly, chop off the add part and have the URL. Sorry? You don't actually need a slash delete or a slash edit. No, you don't need a slash delete, but you do need it if you want to send a confirmation. If a person says, I want to delete, there are two ways of looking at it. You immediately delete or you confirm that you want to delete. In case you want to confirm, for that you can make a get. And the thing that when you're saying there can be a post and there can be a get, people will always be making a get request to one of your URLs. So if you say the delete will always be post, right? People can make a get request to that URL. What happens then? Then you show them, you show the icon. You show a confirmation that you want to delete. You want to actually use the HTTP method, delete or post to differentiate during your edit. As I said, we have get and post. Unfortunately, most browsers are not implementing put and delete. I would love to use put and delete actually. I'm with you on that. Unfortunately, the implementation is not there in the world. Can you name some browsers that don't support put and delete? Actually, I think it's best to do with the browsers and more to do with the routers along. Routers along, servers along, capacity. So the except, even today at this point of time, we have actually boiled down to get and post in the world. I'll have to look that up exactly which are the browser speaks about because slowly it is adding. I turn with graph domain request put and delete or talk. I turn graph domain request. Okay, so anyone else has an idea about browsers that don't, older browser definitely some of them don't. The thing is because all of that, all apps and frameworks that rely on responsiveness, they won't work. Yeah. So I get your point. Now, I'll also tell you one more point in the browser is not being able to think. If a person has to use your system and he has to make a request to your system. He the only request that he can make first initially is get. Because the URL bar suppose that, right? Beyond that, beyond that get request. It's your application, it might enable it. It might not enable it. It's a little unfortunate and I do agree with you that put and delete should be supported. But a harsh reality over here is it's generally not and that's why we are clubbing them together. Just for this, but I totally agree with you that put and delete are important and can be useful. Unfortunately, it's not supported. That's at my example. Yes. Do you have any point? So the frameworks like Rails that use, put and delete are actually using a workaround where you have a form which submits a post request and has a hidden field which specifies put and delete. That it is put or delete. You can always do that in the middle. So first of all, cross domain request is also called most things. That's not a browser limitation, that's a framework in writing. When you have a cross domain, it's a security limitation. We are not in anything cross domain here. We are not in anything. No, no, when we ask a question which browser doesn't support, you say cross domain request in IE don't support put and delete that's a security limitation, not a browser limitation. So it's not a security limitation. It's not a security limitation. It's not a security limitation. No, cross domain request. Cross domain request, the fact that cross domain request have very limited things that it can take is a security issue that has been implemented there. That is why the things are very limited. It's not a browser limitation. IE don't support put and delete. If you do a same thing, it's a cross domain request. Either way, you cannot do it. This is either way, because even if you want to use put and delete, your URL should still support. Your put and delete URL should still support. That is the point you're trying to make. Whether you want to use put and delete, most of what you're deleting is irrelevant to us. Anyone should open a get page anyway. Yes, for a confirmation, for a code operator. That is the point. Whether you use it for support. Okay, I'm going to cut it off here and we are going to talk more about this so that we can quickly get the activity. It's taking a lot of time. But switching that makes sense. In a way, that is what I want to say. One solution for you are us. But instead of having modify expense, show expense. Just have expenses which shows the list. Have an ID which shows the item and has slash edit which allows you to edit or slash delete all of the put and delete. Yeah, that's what we're talking about. My system does exactly that. That's what happens to us. So I have a slash. Just to be clear. So a lot of us who use frameworks that I know have implemented certain delete and put methods. Okay. Those are not technically printed. Those are workarounds. Those are workarounds. They are post. They are generally post with a workaround. And inside the framework, it says that there's a hidden field that says do a put. And then you translate that into okay. I have to do a put. We can just open the browser source to see the form. The headers. You can see the headers. What are they going out? Not even the headers. You can just look at the HTML source itself. And you will see that you will have a form element that translates to So then the routing on the server will take a look at that and modify it within the server. It's really like this browser doesn't support so let me integrate it. It always goes over for post. As a standard today, we are always doing things about post in reality on the wire. You can open it. On the wire, it's always happening over post and delete. Post and get. So I'm going to hack for a sec. It's basically everything. Yeah. Well, I don't know. I can't answer that. It basically is a hidden field. Whether it's a hack or not is up to you to decide. But it works. I have a slide at the very end which will probably satisfy this point, which is something that I have. Anyways, now we are going to quickly move on to the files. Markup. So what does HTML do? It gives structure and meaning to the content. I don't want to highlight much on that. Except for this fact that when do we want to give structure and meaning to the content? Is the fact that if I have a structure and a meaning, then the content is functional. Many systems will be able to understand it and interpret it. And do it differently. The fact that you have a Safari reader that can take a page and can generate only the article and just remove everything else is primarily because your content is structured. Otherwise, it will not happen. The fact that flipboards work, fact that lots of different systems are able to extract data from your pages is because of HTML. And that is something that we have to really take care of. While doing HTML, think just the meaning, not the looks. Don't go by the fact that I need a big, a big statement like we have launched. That's why I put it in H1 tag. Is that the most important thing in the page? Is that the most meaningful heading to the page? If yes, then put the H1 tag. Don't figure out. Because today style is separated from your markup. There's an excellent post on the NPR blog that says create once publish everywhere. This is something that has started very recently where you're trying to make sure that your content once created is able to publish it everywhere possible. So today I make some content. If I write a blog, it should be on Insta paper. It should be consumed by plenty of different things today. And you don't even know tomorrow what use case it might serve. So because five years back, we did not know that something like Insta paper or 10 years back, we did not know something like these Safari readers and all these things can come in because of this. And in the future, we don't know what can happen. Amazing design principles of HTML. HTML is forward compatible. I'm just focusing on one. HTML is forward compatible, which is so brilliant. The fact that even if you have a older browser, the browsers that we hate, they will be able to have, they'll be happy to work in newer times. They have a very healthy default. They say if I don't know the tag, it'll be div. Okay. I'll just process it as they want to do it. And that's the beauty of the system. That means you can extend the types of HTML and today we have HTML five tomorrow. I don't know what more many more tags we are going to have. And older browsers will technically be still be able to support it. The reason they some they don't is because they're buggy and bugs are a different thing. Being aged is a different thing. Okay. So on the flip side, the consequence of this is any code we write with the actual render final browser. That doesn't mean that it's good. Okay. So you have to be careful about that. Just because it renders fine, that's good. That's like I and the italics and gold that was there earlier. They have subtle semantic meaning today. Go up and look at the semantic meanings. Don't use them for the visual styling of italics and gold. Even though that might be the case how it is served by some browsers because tomorrow browsers might not make it italic. Okay. Right. I should be method we discussed a little bit about this. Unfortunately, it's a problem with my system. I'll only take get and post. Please bear with me. And before we move on to the style, you want to jump into our HTML calling. So here's what I want you to do. Okay. I have a single computer here. Can anyone go to the IP address 192.168.1.5? All of you don't go there. Please. I just hope that my computer will be able to handle it. 1.5. Does it work? Yeah. Yeah. Something open. Okay. Not that half. This is for half. Just register. There's something that's initialized there or something. Go there and give yourself a name. Just for me. Okay. That could be any username that you want to use. And all your URLs that you have will be served under that. Okay. So if you have, if you, if my name is Sovik, if I give Sovik, so slash Sovik and onwards will be all the thing that I'm doing. So make it URL friendly. Also don't put spaces. Sorry. So you, you just give a name for your own dev environment. And the name that you give will be also used for you to serve on the network. All right. It will initialize repository also for you. And immediately later, it will give you a few instructions. How can you clone that repository onto your computer? If you use Mercurial, so how many of you use Mercurial? I'm very happy with it. Very few. Okay. If you, if you don't know Mercurial, you can use a GUI, a few downloads there right there. Just come out of the computer quickly install it. You'll be able to clone the repository. If you are a Git fan, there's a hacky, not a hacky, but a tricky thing underneath on that page. You can install those things and you can use Git commands on a Mercurial repository. That can also be done. So command line. Largely the same from some functionality. Some of them are a little different. So the objective is not to waste time on this. That is why I'm asking you quickly download the easy Mercurial or something like that, that is there. Install it in your system and let it clone the repository. The repository at the beginning is empty. And if you click on one of them, the link that is there. It should point you to open up a page for you in which you'll see just a JSON dump. Does it do that? It does. So someone confirmed it does. So I'm going to take his word just to say some advancement. Okay. We have about 20 minutes to do the estimate just because we have lost a lot of time. Try to make once you complete download the repository. I suggest start with just plain HTML pages in case you know how to do moustache. And if you have a moustache compiler on your computer, if you can do that, that means probably run moustache PHP or something like that, use that and compile it. Otherwise, make a simple HTML page starting from HTML till closing of HTML tags. And in the body, what do you want the first slash root URL to do? Okay. The homepage of the app to do. In my view, the functionality should be there to be able to sign up and sign it. Okay. Inside that introductory welcome page, if you just scroll down a bit, I have put in some resources which you can read and refer to. In case you're not aware of those resources, they're really handy. The HTML docs are there. Right. The developers at what wg.org is a very, very designed site for developers. It removes all the HTML docs that developers don't need and browser managers need. So for you, what is the semantic meaning of HTML tags with use cases, with examples, where it works, how it works. They're all there. Feel free to refer to them. And just in case you have completed the page of slash sign in slash sign up slash sign out. Just let me know. By the way, let me also add when you go to the actual URL 192.168.1.5 slash, you put the name that you've given. It will be showing a JSON down. And that is the way in which you can figure out what are the variable that you get when you go to that URL. And therefore in your mustache, you can put in those use those names. Right. Does it make sense? My computer's resolution is here. I don't know what he is. Let me see. I can't see all the things. Oh, it's open. Super. So let me initialize mine. That makes sense. So I'm just giving this everyone don't do it. I'm in quotes. A new repository. Thank you. Thank you for not losing my. Preferred. So if I go to slash Sonic DG here, I see a JSON term. These are the variables that are available to me. If you see the URL is there. They are the handy pointers for you. What are all the URLs in the system? Right. You know from there what URLs you have to use. In fact, you don't have to hardcore URLs. You can start using these. You can in mustache. If you use mustache, anyone, anyone who has no idea about mustache, please raise your hand. Plenty of people, people who have idea about mustache over here. Any anyone you have. And you. So I can be, you know, are you comfortable with mustache? Yeah. Can you quickly help the last row out what it is? By the way, if you're not uncomfortable, I have some handy resources for you as well. Just go just scroll down into the main page. There's a mustache manual here. Are you able to see it? Mustache manual. By the way, right now I'm not advocating that you start using mustache immediately. First rule is just an HTML. But just in case you want to know how to use those variables in your code, just download this mustache manual. It tells you basically a templating language, which is a logical template. All it does is it takes us a variable context variable, which you see on the screen there. And it will give you an access point, points to embed those values inside your HTML template. So you have HTML, say you have a paragraph that you want to put in some content from that key value pair that you see in the JSON. So you have to just use two curly braces. And you see URL is not, say sign up. So right, URL is not sign up. That will just come here. It's just that anyone has a little bit of confidence once you see the manual. Just for the benefit of those who have still not managed to get their initial things started, when you go to the first page, just look at the slides. When you go to the first page, there's an initialize your dev environment. That has checked out for me because I've already initialized ones. But if you click on this, you get to this page where you can put any name and submit it. Once you submit it, you get a set of instructions. The instructions are how do you clone your repository and how do you access your own website on to the server. If you follow those, then we know that we have to create three HTML pages right now for a start. What they enable you to do is create a home page, create a sign in page, create a sign up page, because these are the only three pages that people can access without you logging into the system. Once you create those three pages, and I'm going ahead with the instructions, once you create those three pages, you can get the jumpstart code right at the beginning. There's a get a jumpstart code. What the jumpstart code contains is a list of moustache template file names, and you need to use those names so that my code is able to recognize which template file has to go for which page. So I'll just show that to you. Makes sense. So if you come here, okay. So I have this jumpstart folder here on my desktop. And I have opened them up. So you'll see a list of files. So if you go through the list of files, you'll see lots of files will start with page underscore. So all your sign up pages are going to be this moustache template is going to be served. So your HTML file, your complete HTML should be generated out of, for the sign up page should be generated out of page underscore sign up dot moustache. Right. That means your complete HTML code for your sign up page should be kept inside this. But moustache allows you to combine, slice your templates and combine it in a different format so that you can have a common header, that is from head to body, common footer, anything that is there, common across all pages. For that I have created two more files, footer, header, and for the main body, there are these are the body. I'll just open this up in a text editor. Okay, guys. So say I'm going to go to the homepage. So I have page underscore home. You see include, this is the moustache template code to include a heading file, to include a partial template basically. So you have a header template, a footer template, and the body template. So the header template is underscore header dot moustache, which has the initial HTML till opening tag of the body. My footer is closing tag of the body and closing tag of the HTML. So this is across all pages I have up till the opening body tag and the closing body and closing HTML tag. My actual homepage is anything that I write inside body underscore home dot moustache. So whatever content you have inside body, right now in your HTML pages, just copy it inside body underscore home dot moustache. And you can put these files in your source code repository, commit it and push it. For those who need help in how to push and commit, just ask me, I'll come and show it to you. Or what I do is what I apparently also show it to you over here, how do I do it? There is something that I've done right now just to get you an even deeper jumpstart. And that is, there's a repository called, obviously this is local because it's running on my computer in your case, it will be 192.16 at 1.5. I hope everyone can follow. There's a repository called sovietdg which is my code. It has all the HTML written. Maybe we can get a jumpstart on the HTML front. I would like you to review the code for just a couple of minutes so that you can be sure that there is no CSS there, only HTML, and the fact that that file can open across lots of browsers. And one of the examples is of course, just in case you have an option of opening these files on the links browser. How many of you have used links? Has anyone heard of this? So links is a text browser, what I'm sorry, these colors are all gone. Okay, okay, you can still view it probably. This corner you can still see. I can probably try to do a font-size interface. A font-size interface changes the... Okay, makes sense. Okay, so links browser, what it does is you can only read your HTML file. Okay, and it did not read any CSS. It did not read any JavaScript. This is one of the best ways to ensure that all the content that you have written makes sense. So there is something known as, something that looks like title, something that says welcome. You can go sign in, sign up. There's a sign-in form. You can fill up this. You can submit it and the entire process will simply work. All right, your entire thing work. Just in case you made websites, it would be great after you write your markup or even if you intermingled your markup with your CSS and JavaScript. You make sure that the links browser is able to read it and you're able to as a human be able to read through the things. Just in case you're doing things in which there is too much Ajax and the things are actually not on the HTML page. It did not show up because it's not going to run JavaScript. And most likely all search engines, all bots, everything will be using this and using this also makes the content really accessible. If you use the semantic markup tags of HTML, that's one of the foundation of accessibility on the web. Right? Because when the screen reader reads it, if the user says, I want to see the navigation, it will jump to the nap tag and it will tell you what the nap tag is. At least you can enable those features for whichever systems that support it. A screen reader is what a blind user uses to read things on the screen, hears it and says and use the keyboard or some other control to go next link, next link, next link. Things like that. So it will read it out for you. Much like voiceover if you have iPhone, if you have this. The screen reader is on Mac as well. So you can go to the next page and go to the next page and go to the next. And some, of course, this session is not on accessibility, so I'll just skip over this part. But the idea is to make sure that you use structured content. Is the network up? No, not yet. Not yet. I would have liked you to just take this code and continue from here. Okay? Because, and that is not being possible. Let me just continue with my presentation for the time being. I just move on to the styles for the time being. Assumption is, so here's the understanding. We are going to write HTML, no styles, no classes. I pointed out to a few people, no styles, no classes. There are a few people who I saw who instead of using the label tags to label a field, they're using the placeholder, placeholder attribute inside the field. So what happens is it says username inside the field. Once you click on that, username goes away and you can type. That's semantically incorrect. Placeholder is not a replacement for label. Right? Few things. So don't go into that. Once the HTML is structured, it's clear. Let's move on. Let's move into styles. So we are going to styles in CSS. Style can assist functionality, but it's not the most robust mechanism. And it is not robust at all if you want to give functionality. Right? Functionality should primarily be done over just the initial layer. Your entire HTTP, your forms, your request should be able, should enable people to create a user, start adding expenses and things like that. Once the network is up, you can download my code, start using, start creating users and things like that, and start adding expenses. So CSS has advanced a lot. It can do quite a bit. Some of those things are used to do before, right? It never does any functionality. What does it do functionality? I mean, it addresses up things with JavaScript. Give an example. Open or close the things, move things around. Yes. So I have been able to display text, animate the text, that I would probably use JavaScript when it's working, where I can use it and animate from what text to the word by word. Like R to net color. Okay. But again, remember, animation is not necessarily a bit heavy yet. Animation used to be done by JavaScript because there was nowhere to do it. So I agree, I agree with you. CSS does more things. I'm coming onto that actually. So you jumped ahead a bit. My point over here is your style should not be the functionality. So just question these things. If you're coloring things up to give meaning to them, then you are actually leaving out people behind, right? There are people who cannot identify colors. Which is why if you have to give meaning to things, use the first, first use the right marker. And then when you go on to the styles, just keep a little bit in mind that, okay, my style should be very accessible, right? If I have to give a link color, maybe I also underline it so that it's more accessible. I don't know how many of you've done it. People often use name, colon, the input field. Use a name, colon, input field, password, colon, then it could be. The thing that is there in colon is a convention, it's a convention, right? It's primarily convention style to indicate the separation between the label and the thing. These things go into CSS. So CSS has something known as after. And you can put in custom content inside that and you use the colons and put those things over there instead of putting it in the markup because they are not wanted. Makes sense. These are little pointers that I'm giving you. CSS itself is pretty robust and unknown rules are ignored. If the rules have any error, if you're an old CSS parser and it sees, say, RGB color or the REM text, REM font size, it will just ignore them, right? So you can go ahead and use the new functionalities. Use your name. A few things to keep in mind is, if you have a group of selectors, then the entire block gets ignored. So that is something you have to keep in mind. But, yeah. Was after there was the old CSS? After was there in the old CSS, I think. I think so. CSS is too old. Okay. Works are different. Also the fact that one thing that you have to ensure over there are style is something, please understand, style is something that you're making for a certain, after you have taken certain assumptions, what that is going to be on the screen maybe, right? So the absence of style should not make your website either unusable or not functional or no content. These things should not happen. So your website should still be usable and I hate even if the columns are not there to go after, right? A person sees name and input field works. It's more important to make it work than to make it look the same. Anyways, so order rules carefully so that the newer rules are right at the very end because if you use the old rules at the end, it will override the newer rules for newer browsers. So in order of the CSS rules should be very in the right order. And there's a big question. Do you know the answer to this? Yes, the answer is no. First of all, how many agree the answer is no? Very few. So many people are still confused. Why should a website not look the same in every browser? In fact, that is... It should get possible if you look the same in links. If you go to this website, you get the answer as well. It says no and it opens differently on every, depending on what browser you are opening it. Old browsers will still open it. It still says no, but in a different way. Okay, it doesn't have to look the same because the main purpose is again as we know prior priority, once we are making it locatable, content should be consumable, functional, aesthetics comes later. So it's okay if the old browsers do not have any parity of points. Media queries are their helpers now. It is very important that we start using these media queries. We don't use them very well, honestly speaking. Even I don't know some of them because I'm not used them. It is important for us to start using them because only if we start using them, will these things get better and more things will come in. So today you can probably say that is it a handheld device? You can target a particular style to a handheld device. You can target a particular style for a large screen, for a small screen, for print, for different things. Whether what's the orientation like? What's the DPI, the display resolution like? So based on how dense your display is, how good your display is, you can sell different kinds of images or styles for that user. Make use of that. These are our friends right now. The other point is web is responsive. Keep it that way. The very fact that everyone comes and says, okay, responsive web design has come and the fact that I need to support all the things. There was such a lovely presentation of, even though like if I, the very first website, is the networking now? Seemingly, yes, oh yes. So let me just go first. Okay, so this is someone's website. Not someone's website. It's the website that someone is still hosting and it's still keeping for, prosperity sake probably. And it says that, okay, you can browse the first website here and this is the first website that had come out. You put it on any way that will work. And so it never said that, okay, if you reduce the width down to a small thing, then I will not work. It's fluid, the text wraps automatically and that's an inherent nature of how websites work. Because it's only text. No, because even if you put any, the idea is it's inherently like this, by putting something that is not text or not scalable like this, you are breaking it. It is inherently like this. Like if you take a word document, it will not scale like this. It'll give you a scroll bar. If you take some other documents, it's not so fluid because it never thought. And therefore one of the good ways, one of the good ways. So you always have to start at one point and go towards the other point, right? There is only one end of the spectrum when you come to at least screen sizes. That is zero. So the minimum screen size is zero. It cannot be negative screen size and it can go to as wide as I don't know what. Right? It makes sense to start from the minimum with as you possible as you can and then start out from there to increase the width and change your layouts and things according to that. And this approach is generally called well first. All right? I think this is something that you should also do. Design something for the small screen and then scale it up to bigger screen for something that you design for the small screen. But anyways, automatically scale to a bigger screen. But something that you do for a bigger screen will not scale down. That is something that is possible or not possible. So I would want you to write your CSS in a way that you start, it works in a very small screen and then from there you can proceed from there onwards. The last slide before we start the CSS thing is that there is no mobile web. This has come up very recently. Oh, we are in the mobile industry now. We are making websites for the mobile now. It's the same website that generally people see. So make sure that it works across mobile to any Broadway that's possible. Just keep these points in mind. If we have the network up, just clone my repository or just copy the files of my repository. Take two minutes to assess the code and start adding CSS to it. Now, one thing I really don't want you to go into and I'm going to give you only 10 minutes to style this code. Only 10 minutes to style this code. Why? Because styling is not that important, as I just said. We are going to quickly move into JavaScript because that I think is more important. Just go check out the code, create a new user, add a couple of experiences, write, see how the thing works and make a style sheet for that. When you make right size, you might have to modify the markup, but the markup should not have any change in semantics. That is something that you have to ensure. I cannot come to you and ensure that. Which basically means this. Add classes, they don't change semantics. Add any containing HTML elements that have no semantic meaning, things like div. If you want to add div as a container, like you did, add that, but only if you need it. And the goal, as I said, is not to make a very pretty website. There's a bootstrap CSS there. You might as well go ahead and just slap that CSS. That also works. So 10 minutes for you to just discover my code, get the CSS a little bit working. If you want to make something fancy, you can make something fancy because CSS 3 now allows you to do a few of those fancy things very quickly. Here's a quick set of steps that you need to do to get my code. So my assumption is, my code is always in the repository. I'm creating a new repository from scratch. So I go to initialize my DAF. I give a new name. So this is something that you would have already done. So it creates me a repository over here. I can clone this repository through this path. I'm going to use the terminal to clone it. If I have already downloaded from your OS. Oh, you can download the zip file also. There's a download option. You can download the entire source as it is. Here you go. You commit it? Do you have source feed now? Do you have source feed now? Do you have source feed right now? Okay, I'll do this uninterrupted so that people who want to follow can follow this. Okay, so what I'm doing over here is, I have a fresh repository. I think it's time. Again, that's my mode. I think it's time to do something. Okay, so I use the local host over here. So I have a new repository called stg on my computer. Now what I have to simply do is go to the code I can use. Thankfully, it's on my computer, so I can continue demonstrating. I can go to slash g slash. So here I am. This is my source code repository. Everyone following? This is my source code repository. I can go and browse the code from here. And I can clone this repository on my computer using this. So here's what I'm going to do. So I'll go with the presentation. Okay, so such a network confusion. You know, I started off with saying that there are things are failing right at the beginning. And more things are failing. But anyways. So is the network, am I doing it? Is it a futile exercise? It's a futile exercise. Showing people how to get my code? I don't know. So my code, my code is there in this folder of Sovik DG. So for a graphical user interface, here is my code. That is my code for you. Okay, so you take this entire piece of code and dump it in your, this is my own repository, which is empty right now. Just paste it here. This is my code, a fresh repository that you might have for yourself. From there, if in case you're using a GUI, you can just see the changes. So it will show all these files are new. So I can do a HGST. So these are all the new files there because I've copied it from a different repository and put it in this repository. And I can do a add and I can do a push. So all I did was copy files, add these new files, commit it and push it. So now these files that were there in slash Sovik DG repository are also there in your own repository. The GUI way of doing it will be using source tree. After you've pasted it, it will show you the list of changed files, add all the changes, commit it, push it. Then all those things will go through. I'll run you through the code just because things are failing and we don't want things to fail. At least reach some. Doesn't matter, we're losing on time in any case. We're losing on time in any case. So what I had over here, I'll just quickly walk through. I had different pages, right? And I had split it into body. So I had a homepage where I said header footer and body home. And the body home was here. And the header and the footer are in these two files. So there it's what must have is doing is just compiling these three files. So and on my browser, then I go to local host. I see this, right? So this is my homepage put together. The code that you see, if you already have my code put together, that generates this file. So I can sign up as a new user, say, I may say, my name is Servic. And I want to go password, I'll say nothing. I'll say sign up. So it takes me to a page, which in case, in this case, the URL is still the same. Which basically is, in case my state is signed in, I'm serving a different content on my homepage. It's like a signed in homepage. In case I'm signed out, this homepage was the first one that you see. Once I'm signed in, I get, okay, hello, Servic. These are your expenses list is currently empty. You can add a new expense from here. So I am using currently the HTML date type input fields. So you see a date selector over there. Note is a simple text field. The amount is a number numeric field. Right? I can probably say, I need, and the, I have not done any CSS. These things are running out of the box on Chrome. Test expense, and the amount is say, $330,000. Say add. Right? So this new thing gets added, and there's in the list, it says, text expense amount date. Right? That's the beauty of HTML. In case it's a word browser, it is by the default, it will fall back to text. Okay? So you have to manually enter what date it is. Now this part, what kind of, how to make sure that the date entered is in the right format is a stylistic and something that you had to do in as a part of your HTML. Probably how do you make sure that that's generated? But good, that doesn't matter. So I, I, I probably add another expense over here. So following principles of promise enhancement, if you wanted, you could use a JavaScript to enable, enable support for this and also return support. Okay. I'm coming to that, I said. But anyways, so we have two, two of them, and I have this thing linked so I can go and this is the URL slash two. This is my second expense that was created, serves only the second expense, give me an option to delete and edit. So the things that I want you to note, and just because I'm skipping things forward, things that I want you to note over here is that this delete is right now as get request, which is a little bit of discussion that we had. The reason I put it as get request is I don't want the deletion to happen immediately as soon as a person clicks something. I want a fallback where you ask, are you sure that you want to delete it? If yes, then this is a form. This is a form submit that will do a post submit request. If I say yes, delete it, then that thing is gone. Right? So you, all you need to do, you had to do if the network was working was create HTML templates for all these things and make sure these are open. Similarly, if you see sign out over here, it's right now a link. If I go over here, it will confirm me whether I want to sign out or not. But sign out is not such a dangerous activity, right? As a deletion, right? Because you just signed out. So you can choose to give a form submit as a post request over there as well. That was your choice. You could have, if I click on that, it will directly be a sign out. Stylistic things that come on top of this are the CSS. With CSS, what you can do is make a form button look like a link. Make a link look like a button. These things can be controlled by CSS and that is what you have to do in the CSS. Simply slap on the bootstrap CSS or something like that. Those CSS files will come in. Things that I wanted you to take care of was that over here, we have... So what I do is I quickly modify the exercise right now on the flat. Some people did placeholder labels. I want you to implement a placeholder label on your computer, which is semantically correct. And works as a placeholder label as well. But does not use the attribute placeholder because that is wrong. So can we do that thing as a small exercise right now? Right? I'm not advocating that you should do placeholder labels, but before I go into that, this is going to need you to use JavaScript. By the way, I'll just jumpstart on that. This is going to need you to run JavaScript. So I'll just run through my JavaScript slides once before you get into that. That will be the final exercise which we do as a part of progressive enhancement and we'll end it because the network is failing in any case. So my computer is on the network. You can see it. Yeah, Wi-Fi is off. Wi-Fi is off? Yeah, Wi-Fi is off. My Wi-Fi is not off. It's not working. Yeah, it's not working. One point five. Okay, okay, okay. I am going to get this idea. Time out. The regular work. Work, work, work. And while it works, I'll just quickly run through my things so that we can do the closing thing a little bit of discussion, questions that we have. And let's see. My closing things were about the JavaScript which is what I wanted to move in about five or six minutes before this time. About 10 minutes I had to give you some CSS. So we are doing behavior now. Behavior is what is enabled by JavaScript, okay? So any application that can be written in JavaScript will eventually be written in JavaScript. This is something that Jeff actually said. In the year 2007, okay, and he said that as a corollary to the other, the principle of least powerful device thing. And he said that as a joke and in a way to mock things that were happening even at that time 2007. What people were doing was, oh, I can do JavaScript and I can get this page. I'll just get this page in JavaScript. I can do this. Let me do that in JavaScript. And simple web page loads were increasing. A lot of JavaScript content getting downloaded. It gets slower. JavaScript is a procedural object-oriented now as well. Language, it takes more memory resources than on low-power devices. And everyone had a tough time hoping up with these feature phones at that point of time. And even today, feature phones are just not my support. So the JavaScript error handling isn't as robust as HTML and CSS and I'm sure you are aware of all this. Are you aware of all this? Because I think procedures cannot probably have a default logic. Do you agree with me, first of all? You cannot, if something is not unacceptable, there cannot be a default alternate logic, right? But there can be a default alternate tag. If I give a tag that the system doesn't understand, it can say if I don't understand, I'll go by default div. If I give a logic or if I try to access an object that it doesn't know what that object is, it doesn't know what is the default behavior I have to do, it has to throw an error, right? But you can always just try to catch the error. Yeah, this is easy. You might not be writing that code which is throwing the errors. No, but what is HTML essentially doing? It's just try catching the error, right? Well, I don't want to go into internally how the HTML engine is running. Its implementation will be different. HTML is only a standard. HTML is not the implementation. But a browser is essentially saying, oh, I don't understand this, but let's do the catch it and then ignore it, right? Agreed. You can always try to catch it. I don't disagree on that. It's risky. And it has been risky for a long time. But because it is possible, there are not so assumptions here. I'll come to that. Let me just go ahead with this slide and we'll come to examples where we know things fail and we forget to try catch. And here humans, we do errors. We forget that, oh, something like this ought to have to be caught. We do a document.location and oh, no, maybe location doesn't exist on the document in the JavaScript object because the JavaScript was too wide or the implementation was out of something. So do you always do a test on is there a location attribute in the document and therefore start using document.location? You generally start with a certain set of assumptions, right? You never try catch on that, right? When you do the document location or something like that. But all I'm saying is JavaScript can fail and this is a reality. And then there's office law like today. So many things have been failing right from the morning. I come here. My Adobe fonts are gone. I fall back to these fonts. The network is not working. Things are failing even right now. Try catch might also fail. Who knows, right? It might just go. Maybe you're not doing a try catch on things. Maybe there are external JavaScripts that are there which are not following the same principles that you are following in your code. But what I want to simply say is dependence on JavaScript is a mistake. The fact that there is a JavaScript is also a mistake and also depending on application on JavaScript is a mistake. Which is things like as we went in that list of the initial priorities that we did. We said that we have to make it all the things that we said it did not need JavaScript. JavaScript is an enhancement. If there is JavaScript, then we will give JavaScript and we will enhance the experience. But there are plenty and plenty of websites. Even today, new websites coming up reliance 100% on Ajax. I come to a page, it will start loading, load this resource, load that resource, and then the page will come up. That is relying on JavaScript. That is a bad idea. So that's a very bold statement but very context-based, right? You could be having an application that absolutely has to rely on JavaScript. Suppose you're loading a list of 10,000 elements and you want to page it. How are you going to do it otherwise? Here's the thing. With bare HTML CSS, how are you going to do it? I have to show 10,000 elements. Look, now design can happen at different levels. If you know the limitations of the system, you will design it in the system in a way in which there is a progressive enhancement. You start off with listing 100 and give a pagination on that. If there is JavaScript, kick the JavaScript in, load the next 900. It would have a fallback. Not a fallback. Progressive enhancement, not graceful degradation. Is the other way around. I would rather say the fallback is JavaScript is there, cool. Let me also load the other 900. Okay, so let me ask you this question. Yes. So in the day and age where writing extra code just makes a nightmare later, if you can reduce the amount of code that a developer has to write to do anything, and that requires JavaScript. Considering that 90% of the browsers in an enterprise app world, right, will have JavaScript enabled, why shouldn't you do it? So is your, can I translate this question to your assumption being JavaScript is always enabled? And therefore it's okay. It's context-based and you can't just say you shouldn't use JavaScript. Did I ever, did I ever say, do not use JavaScript? I did not say that. If you got that message, don't take that message. This message says dependence on JavaScript is a mistake, not using JavaScript is a mistake. There are apps that work without JavaScript also. Yeah. And let's take a little discussion after the session gets over. Right. I wanted to make a point for this specific app as an example. Suppose you are doing for behavioral things, you're hiding a diff, and you give a button to open that diff. Say there's a form, right? There's a button, there's a link to add, to open that form and to close that form. Be prepared for the fact that if JavaScript fails, and if someone hits that link, it actually takes to a page that serves that form. So you design your system like that. So right now, if I have a page for sign-up form, sign-in form, and on my home page, I have a sign-up form and a sign-in form, and might collapse them. The, you can always inject a trigger on click, on hand, have a on click handler on A, and you can hijack the behavior. But in case the JavaScript trigger is not happening, or even the fact that when you do a prevent default, or you're on a particular event, do it right at the end. Don't do it right at the beginning. Because right at the beginning, you prevent the default behavior that is running through the link, and then somewhere something happens in the code, whatever it might happen. Say it happens in the code, and what this user is clicking on that and nothing is happening, that's a bad idea. Some websites do this because some websites have, like, a login in the corner. We click on it and dropout comes out, but when the website is still loading and somebody clicks that, nothing happens. Nothing happens. But some websites put it to go to a login page. Absolutely. Which is like a good point. Very, very, very good point. That is, in fact, very important. In fact, I think it's even a bigger message that I want to give, that JavaScript dependence is a mistake. Even things like when you're doing any Ajax calls, don't do a page change or a main page content change unless and until you are very sure that you'll be able to, in my opinion, update the URL. Which means it should support the STML5 history APIs. Right? So you should know that it supports history APIs and therefore I'll use Ajax on this. Because the older systems, in any case, it will work as a simple click-through. Right? So don't make such mistakes. I have a question. Yeah. I was just building an Angular app or some MBC or using an SP or making an SP. So, using these things, like I have to make Ajax calls to call in my views. Without doing that, like, I mean, if I want to go progressively, then I would have to build that on a conventional system, PHP and all that. And then click in JavaScript and remove all that content basically in my, right? I'll be very honest. I did not follow all the parts that you said. What is the place in which you will not be able to... What is the part that you will not be able to do? You know, the point is that my entire dealer uses a certain framework or certain system. If you want to follow this method, you would not be able to use Angular, you would need to have PHP as a back-end line. He's talking about using with an API and have a... Oh, just an API in a JavaScript? Yes. And I'm saying that in my view, that is not the... JavaScript is always an optional component of the app. We talked about so many devices that do not... All of my views are coming in through ADAPTS. If all... All of my views, everything that... So, it's coming in through... So, there are two... In principle, that is wrong. In implementation of that, in principle is wrong. But of course, your... And the other part is, this is also a short-intercat kind of situation. You don't know what the other views might come in until unless you implement the other options. When... Because the other options are not there, the only way the calls can come in after the JavaScript calls to the ADAPTS, right? So, things like, as we said, initially loading and some things happening at that point of time can easily happen. Then the thing is... Are we sort of like clinging on to like... If we keep supporting crappy devices that don't support JavaScript, that's when they'll stick around. But if you just say, okay, no, like, you know, I'm going to start coding in Angular, I'm going to start coding in Node, and I'm going to be serving pages which have the exact request, then everyone will just move to devices which are metal, right? So, it's sort of like, you know, holding on to something old so that we don't, you know, use the latest technology. Sir, did you also give me a fist of fire when I asked that you agreed with the mission of worldwide WTC? I think it's not about even devices. So, when you mentioned that you're assuming that JS is enabled, right? It also means that you're assuming that the guy's on a good bandwidth. So now, in this scenario, a lot of sites will actually not work when you have like a, you know, an issue with the vibe or whatever, or you're on the phone and you're on an edge connection. I think the whole idea here is that, you know, whether a person is on a... I mean, even on a low bandwidth, he should be able to actually go through. I mean, I'm giving examples in theory also, right? When we designed, like, we were depending on our home page who have JavaScript, right? So even for an online service and stuff like that, right? And there were people who actually couldn't receive the user's search. So we actually made the home page JavaScript free, even though, like, it's a single page app. But in fact, from search form to search results is a single page app. It actually works. So if you don't have JavaScript loaded, it will actually render the SRP and it will give the single page app a second chance to load the JavaScript. And so I think that's an important sort of point also to be included here. Devices, even though they'll get capable, they may not have network connection. So it's the first thing, right? Going to the clear proof example, you said on the home page, you made it JavaScript free. But once I search for a flight and I will look at the option, you can't make the page JavaScript free, right? I mean, we're taking a call, but I think... I'll tell you, I think you can make it JavaScript free. I don't see any reason for it to not be JavaScript free. How do you do it? We'll talk about that later, because we... No, but the reason I want to ask... Okay, so what is... So you're claiming that dependence on JavaScript is a mistake, right? Yes. Obviously not a very niche website. It's a public website accessed by thousands and millions of years. Okay. How are you going to make it JavaScript free? Are you saying you can't shoot data without JavaScript? Is it going to have the same user experience? That is different. That is different. It's not different. Are you saying that you can't show a resource on the web without JavaScript? That is what you seem to be saying that you... You are not making it reachable. You're not making it located to be. I don't see that don't have JavaScript. Exactly. You have to understand... Really? No. So, hold on. Hold on. Can you... Can you... I think statement of dependence on JavaScript is a mistake. I think it's overking. No. The right hand is not used. JavaScript may be a better way of saying it. No, I'm saying... I'm saying I'm inverting. All I'm saying is I'm inverting. Build something without JavaScript, then add it. That's what I claim. I can't build something just so that you don't have this ever... Even in your example... You don't want the error dialogue coming up. You don't want the client to be at any point of time stuck. And also the fact that it's not always about enabling. It's... There are two factors to it. One factor is JavaScript not being there. That is hardly a question anymore. If you just narrow down your vision, to just five browsers, six devices or six mobile browsers, that's it. The world today at this very point of time has more browsers than we can think of. First, the second... The second point is you can always claim that, okay, I'm not... I don't care to serve those people. I don't care to serve places which have no bandwidth. The third thing is it's also about a good practice so that if there is a failure of technology, then it can still continue serving the content. There were cases and many of them famous in past where their JavaScript has failed even on the Google Chrome download page. And they were using a JavaScript hack in their own page and the download was stopped for two hours. That's a mistake, a person... And you did not need JavaScript at that point of time. Which is again not to say I'm insisting on this. I'm not saying don't use JavaScript. I'm saying that you build your system for without JavaScript, then bring in JavaScript. Or JavaScript is always an optional component on the web. Plus the fact that you want to serve as much set of devices, as much as of user agents for everyone going into the future because five years down, back in time, we never realized that we're going to run into such bandwidth issues as we have run into right now. Because five years back, there was a phase of time when we always assumed bandwidth was going to increase. Then send to mobile payment and the mobile networks never had that bandwidth. Everyone thought everyone will have a line connection. Bandwidth went down, everything went down. So the fact that you're relying on something that is... And we also established that this is an unknown. We also said the only thing known right now is there's a client and there's a server. There's an HTTP connection. There's a... I should be able to serve a resource. That's it. But use JavaScript. And I'm not saying don't use JavaScript. So just be prepared for failures is my message. So dependence basically means if the person doesn't have JavaScript or if the person doesn't have... The JavaScript has not kicked in yet. It has not loaded. Any of those things have happened. The fact that you're able to still wake up from a failure situation right now, like the way things are having right now, because somewhere someone could have said that Wi-Fi is a reliable. It will never fail. It will never break. And a room of 20, 30 people will never have a problem. Well, we are not having that in 2014. Right? So the other thing that I want you to share is just in case you are modifying the DOM and styles, don't put in inline styles. It hampers the principles of modularity as well. Styles will be separate, put in classes. Okay? Don't do this. Make your JavaScript unobtrusive as well. So if you go through the HTML5 boilerplate that's a very good starting point because they have all the leading edge practices incorporated in their code. They put all their script files right at the end or you may use async attribute to make it load in parallel. Don't rely on the head because the entire DOM loading or the page loading has to wait until your entire JavaScript loads. And these JavaScript files are getting really good. Really, really good. Another point is don't do browser sniffing. JavaScript and also back-end programmers, it is, I don't think there are many back-end programmers here. Don't use JavaScript browser sniffing. Detect features because when you do browser sniffing, what you're relying on is just because a person has X browser, he'll have X set of features and I'll be able to use them. Right? But if you detect features, things like, okay, does it have SVG support? Does it have HTML5 if the history appears? And then I'll go ahead and use them. Does it have those things? And to that end, what helps you is something else, modularizer. Has anyone not heard of the modularizer script? There are people who have not heard of modernizer. It is there. I don't know if the network is up yet. It is there on my computer as well. You could have caught it. Probably go back and read on it what modernizer does. It's a set of tests written right at the beginning, but include only that file in the head, which makes you available two things. One is CSS classes. And the second is a JavaScript object in which you have all the booleans. So you have a modernizer.svg. It will return true if there is SVG support, false if there is no SVG support. And as an example, even today, there are so many Android 2.3, 2.2 phones around, they don't have these things support at this point. So use modernizer. The way to use classes is, then modernizer script runs to the root tag that is the HTML tag. It adds a set of classes, which basically means in the semester's file, you can simply say .svg, space, .any of your element, then include a background image that I just made. Does it make sense? Because the root element has .svg and then .thing, and you can include those things. Look up modernizer. It will be a really useful tool for you to detect features and therefore apply it. It's also very much part of making sure from a weaker system to a more modern system, you're able to use it all throughout across the thing. So I gave the slide exhibit restraint and plan well, but do use it, and I wanted you to do it. We have less time. If anyone can do a quick implementation of placeholder labels, that will be good. We can do a JavaScript placeholder label thing. Otherwise, I have a couple of more slides, and then I'll end. Yeah. I haven't discussed web fonts. I wanted to discuss web fonts. And as a part of these JavaScript things, I wanted to discuss a little bit of web fonts. One, from my part, the web font usage, the flaw that I see most of the websites have is the fact that you rely on the web font loading until the point of time the page is written on the screen. And that is the flaw that I think. So what exactly do you want to discuss in web fonts? Can you just highlight? You want to do that where we need to end up using JavaScript. So there's this thing called... Answer is yes. If you want to do that well, you end up using JavaScript. That is correct. Which also means that if there is no JavaScript, you are running on fallback fonts, which is okay. Okay, because not all websites have to look in the same library browser. Enabling functionality is more important. Fonts are aesthetics. Do you agree with me? So if there is JavaScript, go ahead, use web fonts. There is something known as web font loader. That's an open source library. It also has these events. And what you can do is, while it's loading web fonts, you can detect whether a font is loaded or it has not loaded. And therefore, once the font is loaded, you can just replace the page content with that. And with CSS 3, you can also add some effect or something like that if you want to do that. But there are plenty and plenty of websites which just show me a blank screen initially on my phone for at least about 15 seconds before then the font loads. And thank you. Part of it is also bad because of how the browser needs with fonts. For example, WebKit and Chrome, they basically don't load the font. Firefox does it. Firefox waits for the second or two and then loads the backup font. I am coming to that point. I'll just complete the presentation. We'll try to do a placeholder label implementation right at the end of the thing for whoever is interested because we want to end on time as well. My parting thoughts are before this. And this is what I wanted to say in a lot of your questions. The answers are design has said, okay, as long as you're following standards. And this part where the behavior of one browser is different than the other, this is actually true in not only these implementation, also JavaScript implementations, also HTML implementations, because at the end of the day, all these are standards. All rendering engines are advised to follow or they should be following this. But they can always take a detour on this. Be it CSS, be it HTML. They have been doing it in the past. There have been bugs. And that's why jQuery exists even for JavaScript. And there was a recent long list of bugs. And I remember that one also retweeted it by Paul Irish. There was a long list. There was a recent page published that you might not need jQuery. And it had a parallel code samples using pure JavaScript without jQuery. A follow-up by Paul Irish and the other guy, they said, you might not be jQuery if you follow, if you are careful about these bugs. And they went on to list. I don't know, there was a huge list of bugs on even modern day web browsers. So this is another point where be careful because things might fail. It's just about being able to recover from a failure, nothing else. Nothing is stopping you from using Ajax or something else. And things like that. Any fancy JavaScript effects. Go ahead. Provided you take care of the failure standards. Then next, I think this is different. So be very clear about this. When I took the name of the browser that should not be named, that's usually an hatred for browser bugs, not the fact that it's a word browser. And also keep this in mind that it doesn't have to look the same in that browser. It just has to enable functionality just in case people are accessing the web using such browsers. And countries are there which are still using that browser. And all different browsers which are probably worse. Which is a different case. So supporting the latter does not mean that it has to look the same as the new one. So please give away that notion of whatever is the experience that Sir pointed out, that we need the best experience. It is okay in the older browsers, you just give the basic experience, but make sure the thing is available. That's it. Give the best experience in the latest ones. And this point about polyfill, something that Arpan just pointed out, that you can make some people do or make browsers do things that it relatively doesn't support. I think that those are unnecessary. You can do away with polyfills. And when I say unnecessary, I'm not saying don't use it. I'm saying that it might not be required. So you might do a slight design workaround because all these polyfills and all these hacks that you do, you're targeting specific either browsers or user agents. They're not based on feature detection. This one is based on feature detection, though polyfill and there's a long list of polyfills on a site called HTML5, please. I don't know if you've heard about that site. Also was there on my page in the list of links for your reference. If you want to use those polyfills, you can. But say as an example, if you do a standards-driven code, let me take this placeholder example itself. If an input doesn't have the placeholders because it's following the order of stable standards, it is okay because neighbors and states should have. It is okay if the placeholder is not visible because you should not rely on a placeholder in the first place. Placeholder is only supposed to be a hint on top of what a label is. And using front-end frameworks doesn't really prevent progressive enhancement. AngularJS is something that he's pointed to. I've not used it. We can probably do a discussion on that whether it's a good idea to do it or not idea to do it. But this is a big thing. I think every web developer, web user should just remember this part that we should not assume. There is too much unknown in this thing and it's only going to get worse from today onwards. If today we give a bold statement saying that, of course, there are only these five web browsers today. Of course, there are only these many things. It's not going to be the same tomorrow, five years from now. And there's a very good statement that says that only if you're backwards-compatible will you be forwards-compatible. For you to be forwards-compatible, you have to ensure backwards-compatible. That's one of the best ways to deal that. So just because older systems are able to use it, you can almost assume that your system will be able to use it, although your particular implementation might not work the way you are intending it to work in a way. Coming back to my original question, why do we not care about some web browser? Do you have a different answer this time, anyone? Okay, I'll break this. I think we are not as flexible as the medium demands are to be. Clearly. Web is a very different medium from everything else, at least today. It is something that is giving us, it's not like print, it's not like a TV, it's not like a cell phone. It is such a mixture of all these things. And if you can read this article, and I strongly urge you to read this article, this is an article that was published almost 14 years back. And write it at the beginning when this was finished. If you can read it, you will probably understand what I mean by saying that you're not flexible enough. I can take some questions. We can go ahead with the code. I can probably share you my buggy Python code so that you might want to interface your things with that code in the future. We can probably implement a placeholder label implementation in a progressive enhancement way. That's a very small thing that I'm taking because of all this confusion that happened. How do I know the placeholder implementation? I have a small implementation. I had, let me see if I can quickly fetch it. That was a date field, right? Sorry? That was a date field, right? That was a date field, yes. Input IPv2 date. So let me see. So this is one thing that I did. So there are a few things that I did over here. If you remember, these were date fields, right? Unfortunately, again, this is a design hack that I had to do in a way. I had to replace the date field with text fields. Why? Because the date field has a default way of taking input and you cannot override it, at least till today in Chrome. There are proposals that will let you override what the default text comes like, whether you do not want the dropdown of the calendar that comes and things like that. So I have to convert that into a text field. And these things right now look as placeholders, but they're actually not. And they are the same labels and I can tell me get you the code. Can you type? I just want to see what happens to the one character. And the thing is in the date, I can always ensure that the field is big enough that the date fits by this type, this space. Or the fact that there's a padding, enough padding that this thing keeps on the side or the fact that this thing is small enough to be on the top and the text runs in the bottom. I will quickly show the. It is, this is Chrome browser, this is standard program. Okay, so if you look at this, we have a label. We have an input. There's hardly any change from the code that you had seen over there, except for there's a date field class. There are a couple of classes over here. And no placeholders. What I'm simply doing is I'm positioning it absolute on top of the input. I'm registering a click over there as soon as you tap. In fact, I don't need to register a click. Because if you click on the label, it automatically focuses on the field. Right. That's our native thing of the browser itself. So as soon as this is the label or in the field itself, so you see this becomes a pointer arrow to this so the label actually ends here. So I can, of course, this behavior can also be overwritten by CSS. So when I click on this, what I've done is, I'll move the label text on the side, because it's very important for the person to know what the field stands for after he's written something. Again, one of the very basic design flows that people make when they use placeholders. Whether if you put a content and you don't know what the field is for, that's a problem. So one of the ways is, this is one of the solutions that you can go for. But you don't really even need to move the load to the corner. Like, it can leave it where it is and have the load. Absolutely. That's a design choice. That's a design choice. It's up. You can do it. The reason I moved to the corner is because I had to make the field bigger, height bigger. That's it. And this will work across even older browsers, I think. It should work. Let's see. I have actually, this code was not incomplete. So I just go back to it. Okay, I don't know what user I'm using. Sorry. But the idea is not that you have to have disabled JavaScript, okay? So I have an ad field here. So if the JavaScript is disabled, this is how it works. So I have the fields here. I have an ad here. This is, it becomes a list for you. If I click on add, I jump to this field, the form that is below this thing. Right? So the functionality is still anyway, even if there's no JavaScript over here. The only thing that I need to take here over here is, the moment I hide this, at the point of when I include JavaScript, this is a hash fragment URL right now, which is jumping into that div ID of the form. Because you click on that, this link and you jump below. The moment I hide that form and I collapse it, I should, what I do is, change the link destination of the link to a page that is giving me the ad expense form, which is slash add in my URL. In that case, even if JavaScript fails later, right, the form is hidden. If someone clicks through it, at least go to that page where you can add a field. So here are little things that you can do to improve on the implementation. So URL can be added through JavaScript, right? Right now it is not. Right now it is not a complete solution. But I'm telling you this is how it should be done. How do you do this? The placeholder? No, nothing. So what I did was I have an input field and I have a label. It says a container box paragraph for me around that. I make a position absolute of the label on top of the input field. Do you actually do a virtual location on hlet and then append hash back to it? Over here, this is a native behavior on the browser. I don't do this. Over here it is the native, when you can add it to a single page after it goes down. That is something, as I said, again a native behavior on the browser. I did not add it. The browser added it. I did not have to do anything to add that hash. All right, thanks a lot. If you have any questions, I'll be around. And feedback is appreciated. I just need to make an announcement. I think yesterday, you must have come to know that we're going to basically have a slot on Saturday, 5 p.m. You guys can actually present your design solutions that we worked on yesterday. So I think it's like I also tweeted this. It's important that everyone works on this and at least comes up with some concepts so that you go through the entire process. So I really encourage you guys to actually work on it and maybe even present it. And if you guys want to run it by me or discuss some ideas around till Saturday. I think some people have actually put it up. So I'll be reviewing that today. Can you also present what you think are good ideas? Yeah, I mean, I'll put out some thoughts, but I just don't want to kind of influence your... Yeah, sure, okay. All right, thank you, guys.