 My name's BJ Clark. I guess there's still a few people filtering in. I work for a company called Goldstar.com. We sell event tickets for half price. And if you're from around here, it's OK if you've never heard of us, because we don't sell tickets here. But if you're from a big city, New York, Chicago, LA, something like that, and you go out a lot, then check out Goldstar, giving you a little pitch. OK, you guys don't look very excited. Are you tired? Let's get excited. Woo! Woo! OK. So my talk's called Dr. Strange Love, or How I Learned to Stop, or How I Learned to Stop Wearing in Love, HTML, CSS, and JavaScript. I have a picture here of a guy. I don't remember what the guy's name is in the movie, but he's Slim Pigans. That's right. And he's essentially writing a nuclear warhead after it's been dropped out of a plane. And I think that's a pretty apt metaphor for people who really like doing front end code, because it always seems like a good idea. And then somewhere along the line, you realize that in the end, it's going to be painful. But this is sort of a collection of pro tips, and tricks, and techniques, and things I've learned over the years. Doing front end code. Pat was, we were pairing up here earlier. I met Pat in about 2002, I think. And he was a Java developer. And I was basically a designer. And we started making apps and stuff. And I ended up always doing the HTML. And then I got really tired of being the only guy that did HTML, and Pat doing Java, or Ruby, or whatever. And I was like, why don't you do any of this? And he's like, I don't know any of that stuff. So I've set out to change that. I'm going to make all Ruby developers actually like doing HTML, CSS, and JavaScript. So it's not that hard. It's not that bad. I know I started off maybe with the not the right metaphor, I guess. So pop quiz, how many people in here make web apps? Or something that has to do with the web, right? So how many people write Ruby but don't have anything to do with HTML, CSS, or JavaScript ever? I know Pat's lying. Really, you write Ruby that doesn't do any HTML? Really, sometimes. But sometimes you do. So it's HTML, JavaScript, and CSS are almost completely unavoidable if you write Ruby. There are very few, I think, use cases for writing Ruby that doesn't have anything to do with the web. So I've made a little fake application. You can see that I've ripped off Flickr. And I don't know if it's a copyright violation or not to change the name and remake the application, but I'm going with it. And it's just to illustrate a couple things, a couple techniques. And I don't know if Flickr even does these things, but I wanted to use a couple tricks. And so I made this. You can check it out on GitHub. I'm BJ Clark on GitHub, and it's Dr. Strangelove. And so it's just a basic Rails app, 2.3. You should be able to get it going without any trouble. There's nothing funny in it. No, I'm not going to Twitter it. But Pat will Twitter it, so everybody follow Pat. Anyway, this is a love story in three parts. And the third part, excuse the profanity, but sometimes I don't think people actually care when they do JavaScript and that's unfortunate. Caring is good. So anyway, why? Why even care about your HTML? Why care if you do things right? Like browsers don't care, right? Well, I've worked as a consultant and I've worked at numerous startups and it's incredible the amount of time you waste when people don't care who came before you, right? And if you don't care, you will end up wasting your own time down the line. It's a legacy code thing. It's just something that if you cared up front, you will love yourself in the end. And this, the app that I have on GitHub that you might have had enough time to get the URL for, it validates as HTML5 and we just learned about HTML5, that was great. But the first tip I'm going to give you is if you need to support browsers that don't support HTML5, validating your website against HTML5 probably isn't going to help you very much. So maybe you should think about validating your website against HTML4 or something that would probably help a lot. I don't know if people out here deal with IE6. We make a lot of money off IE6 at Gold Star. We have lots of people like eight or nine a second come to our site using IE6 still. And a few more than that come using IE7 and almost nobody IE8 and I've never seen IE9. So if we ignored IE6, we would literally take zeros off our bottom line and the business people don't really like that. So this validates against HTML5 but we validate against HTML4 at Gold Star and we don't validate very well. And we support IE6 and we support, we have even thought about trying to support Web TV still because people still come using Web TV which if you've ever used that is extremely, extremely painful. But anyway, getting on to what is good HTML. If you go out and you went to some of the designer conferences like Event Apart and stuff like that, they'll tell you that good HTML is semantic and you go, well, I don't know what that means. And it just means that it's meaningful. It's something other than divs and paragraph tags and spans. Those aren't very meaningful. They have a place but they don't mean anything. What does div mean? Does anyone know what div means? Right, maybe. There isn't even, nobody even really knows what div means. No one even knows where it came from. It was some guy at Netscape in like 93 or something just said, well, we need a divider or a division or something, let's call it a div and let's start wrapping our content in it and then we have something else to style with CSS. So the first pro tip is learn HTML, learn what's out there. If you only knew four or five Ruby methods, could you write a really awesome Ruby program? Probably not. Well, if you only know four or five HTML elements, you're also not going to write a very meaningful HTML document. So has anybody ever used the sample tag? Even heard of it? Abbreviation, site, ordered lists versus unordered lists versus definition lists and there's many, many elements. There's even more in HTML five as we heard. Learn them. And the next thing is use tables for tables and lists for lists. There's a backlash against laying out with tables. Yeah, laying out with tables is bad but some of us display tabular data and those go in tables and some people, some of us display lists of data and those go in lists and whether it's unordered or ordered or a definition list or whatever, put it in a list and put it in the right list. I don't know how many times I've seen a div within sets of divs inside of it that make up key value pairs. Well, that's actually a definition list and there's an HTML element family for that. And then HTML five, I usually talk about that and I'm not gonna talk about it because we just learned about it. The next thing is understand the difference between IDs and classes. That's, some of you will go, well duh and some of you will go, I might not actually know that. These are really important and they have different uses and you can't validate a page that has two of the same IDs in it. It doesn't validate, that's not legal. An ID is an ID, it's unique. Rails has things to do this for you. You can do div four and pass it an active record thing and it'll give you an appropriate ID that's unique and an appropriate class name. It's already in there, people never use that. It's in there, it's done, it's free. Dom ID will give you an appropriate Dom ID for any given active record object. It's in Rails, all the helpers in Rails use it. Your designers or whoever does the CSS, if you don't do it, will love you if you use that because that makes it really handy. Microformats, who has, who's ever made a webpage with a microformat in it? A few of us, so microformats are awesome. Who's written Ruby code that used a design pattern? Like, you know, Delegator or something like that, right? Most of us, a lot of hands. Microformats are design patterns for HTML. So if you think that using a design pattern in your code is a good idea, then using a microformat in your code is a good idea. And there's, this gives you free things. Browsers have extensions that do special things with microformats. The most basic and I think widely used one is the H card. Has anybody ever used an H card? Basically, if you use the proper set of class names and attributes in HTML, someone can download your information directly to their address book. And on an iPhone, it goes right into their contact list. So if you have your contact information on a website where you were making an intranet site, intranet site, or something that had a phone directory or something in it, you should encode it all in microformats. Microformats have been around since about 2004. There are microformats for many, many things. Media, like photos, videos. I use a microformat in the most widely used one in the sample app is this H media microformat. And it looks scary, that top box is what goes in it and it doesn't really make any sense FN, like that doesn't really mean that much. That's just formatted name. But it tells you exactly what needs to go into the microformat to make it essentially machine readable. And the data mining stuff, if you put this microformats in your app, you get actual daily use out of data mining because I have down here MoFo and XOXO. MoFo is a microformat parser for Ruby so you can curl a page that has a microformat in it, pass it into MoFo and it'll spit out all the information that was microformatted in it and it's like one line of code. It's not really built in to many browsers but there are extensions for just every, I think every browser, maybe not IE6, but modern browsers. There's numerous Chrome extensions. There's Safari hacks that go back to Safari 2 or Safari 3 and stuff like that. And so it has a dual use, it has that use but it also has the use of how do I lay out my page and what do, if I'm gonna put an image or review or a comment in the page, like what elements go into that? The microformat I'll tell you and the XOXO format is actually a microformat that you can use for navigation and there's a gem for that and so if you link to your in the page, if you link to your RSS feeds and stuff like that using this XOXO gem it'll, you can get all those links out of the page very easily. This is an example of the XOXO microformat. If you notice it looks just like HTML because it's HTML. It just has a couple classes and specific attributes that make it into this special microformat. So it's not hard to get into microformats but they're very useful and they get you past that what you name stuff and what elements do you use. This is another sort of trick or technique I use which is I call it doing resourceful views and so in this app we have a photo and so there's a photo partial and the photo partial renders a microformat for a photo and it takes a photo object out of your database. So you can call render partial and pass in an object, a photo object into it and it renders out a completely microformatted photo anywhere you wanna go or anywhere you want it to be and now you can use that throughout your application anywhere you need to display a photo and it's right there, it's really easy, it's microformatted, it matches our domain objects and it's reusable and everybody knows what it looks like, it's easy to style, it's easy to style in multiple places and you just kind of, you just get benefit all over the place from just setting up sort of, it's a coding standard. Usually I store a URL from S3 in the database and that's what, but using a decorator or something you can, it doesn't even need to know that, your partial doesn't even need to know what's there, if you pass it in a decorated object instead of an active record object or something like that. We have the same thing for tags, this application does two things, it has photos and it has tags. So anywhere I wanna display a tag, I have a tag partial and I pass in a tag object and it looks and it renders out a tag and my designer knows what a tag will look like HTML, why is anywhere in the application now and he can, he doesn't have to know any programming, he can just write some CSS styles and he's done. So that's, those are my HTML pro tips. Next thing is CSS, this is a flag of Cascadia. It's a little obscure. You can look it up online, the Republic of Cascadia. I'm from Portland in the Republic of Cascadia. Yeah, it's a really obscure slide, it's okay. CSS is boring. So, so WebKit, so this is a, this is from a site called, I just drew a blank, Quirksmode, sorry, Quirksmode. And if you go to Quirksmode.org, you can see this awesome, this is the first page of many pages of every HTML, CSS, and I think JavaScript method or element or rule or selector or anything that a browser knows and whether it works in essentially every browser since IE5, including Opera and Conquer. And I bring this slide up because I'll point out that WebKit supports almost all of these. If you look at the WebKit column, which is Safari, it's green on all of the things. And to show you how to use this, if you click on, say, CSS2, it'll then bring up another page that looks a lot like this with the actual CSS2 rules. This is indispensable, hey, the Quirksmode itself is indispensable, but I also find that developing in WebKit to begin with is a really nice way to go about it, both for CSS and for JavaScript. And that's because WebKit tends to stick, WebKit's either Safari or Chrome, WebKit tends to stick to the standards. And if you develop things that work for the standards first and then go backwards to things that don't support standards, such as IE or older versions of Firefox have lots of things that don't actually follow the standard. You tend to do a lot less sort of CSS hacks or, which this has all of the CSS hacks, or weird tricks or whatever to get around all the inconsistencies with CSS. So that's the number one thing that I think most developers complain about is I never know what's gonna work. I try stuff and it breaks or it works differently in different browsers. This tells you all of that. This will tell you how it works, why it doesn't work, when it was supported, a hack you can get around it, whatever, that's all in this. CanIUse.com, I don't know why I didn't put the site on it, is another thing that if you have something specific you know you wanna use, you can see if it actually works in the browsers you need to support. I think it's CanIUse. It's either .com or .org. I'm sorry I didn't put the URL in this. But between those two you can actually get a handle on what things in CSS you can actually use on a given day and for the browsers you need to support and whatever. The next thing is, I went to Rails conference, I don't know how many of you went to Rails conference, but there was one of the very few things that had to do with front end Rails code was a session by somebody that I don't even remember. And he said, don't use CSS frameworks, that's just looking for trouble. Well, CSS frameworks are like the developer who doesn't like doing CSS's dream because CSS frameworks are really just a set of basic rules to start out with and they will get you to a point where your site doesn't look like crap from the beginning. They have something called a reset, almost all of them. This one is an example of 960.gs, which is 960.gs. That's a TLV I didn't know. And the reset will basically reset all styles in all browsers to the same thing. That's the number one thing that creates CSS inconsistencies is the default font size in IE6 is one thing and in Firefox it's another thing and in WebKit it's something else. And this sets all of those things to the exact same rules. All the margins are now zero, all the padding is now zero instead of worrying about, well, some of these, if I accidentally didn't put in a padding, it would be 10 in some browsers and zero in other browsers. The other thing it includes is a clear fix. So when you're trying to mess around with floats, which is the other thing developers hate about CSS, sometimes you just need to say, okay, stop floating all these things and put this thing under it. And that's what a clear fix does. And it's built into all of these frameworks and it's as simple as throwing a div in that's called class clear fix. And everything below that will come below, visually, everything above that div. So it's sort of a reset. As far as using the grid itself that comes in a lot of these frameworks, unless you've heard of a guy named Joseph Mueller Brockman, or you're really into 1960s Swiss graphic design that is all about using grids and typography, you probably don't care. So don't use the grid. You don't have to use the grid. All of these, almost all CSS frameworks include a grid. Just ignore it. Don't use it. Do whatever you want. But use the reset, use the class fix, use the default styles and they'll get you to 85% of where you wanna go and then you just have to figure out color theory and design concepts and stuff like that. So it's no problem. Graceful degradation is something that we all need to start thinking about because it's the only way to go forward. The idea with graceful degradation is it's okay if stuff doesn't look perfect in IE six. Stop trying to jump through hoops to make rounded corners and have gradient backgrounds in IE six. Cause they aren't gonna care. The web already looks like crap. Half of it doesn't work. They're used to bad user experience and they just keep trudging on. So just ignore them and use CSS three as long as it doesn't break your application. In this, if you look at the sample app on the right is in Chrome, on the left is in IE six. The only difference is that tag doesn't have rounded corners and it doesn't have a gradient background. That's a trivial example. This is a site I'm actually making right now. IE seven, we don't have a rounded by now button. In WebKit, we do. Is anyone gonna care? No, the rounded looks better and it fits with our design nicer and it only took about three lines of code to actually make that happen and we could have spent like three hours trying to make it rounded in IE seven but who cares? They're not gonna care. They're not gonna notice. The web's broken. So this is how we do it. This is if you, once you get, if you look at float left, all of them need that. If you look at background, now we're starting to set a default background that uses a WebKit gradient. If you notice the lowest common denominator line, so every browser's gonna have gray to start with and we then go back through and start adding more styles that are more complicated. The WebKit gradient, the Mozilla border radius stuff, the box shadow using an RGBA value which allows us to have alpha transparency as that fourth thing so we can say that it's black but we could put 0.5 instead of 0.1 on that last line. That IE six is just gonna ignore that and that's fine. Their users are also gonna ignore it. They won't ever even know but it looks nice in other browsers and it's not complicated. It doesn't, this isn't gonna like bloat things up and it's just a few lines of code. The flip side of this is we could have used like a JavaScript library or something that went back in and like redrew a bunch of divs around the corner of that button or those tags to like make this fake rounded corner on it. That's one of the tricks or it uses a transparent pixel and writes it in there and that stuff's a lot slower in IE six than you'd imagine and it really slows down your page load and you could have just done this and got on with your life. The next thing is that I think a lot of developers don't tend to get this concept is that object, is that CSS is actually a lot like an object oriented programming language that doesn't have any computation. So you can't do any math in CSS and you don't have any variables but the rules to how you put together classes and IDs and style things is not unlike how you can extend things in Ruby with modules. Like we saw in the scraping presentation that he extended things in development by including more modules and stuff. That's how CSS works. So you can give high, you can style every div on your page with a white background and then go back in and say well these specific divs I actually want to have a green background and that's composition and you can, if you assign something to all divs it inherits to all divs no matter where that div is on that page and you also have namespacing. So by saying the class photo navigation and then image we're only talking about images in the photo navigation divs and those photo navigation divs can be anywhere but we're only talking, we're not applying the styles to the image. To all images we're only applying it to one's namespaced by photo navigation. This is a little bit contrived and I don't know if that Ruby code actually works but in my mind that's kind of how I think about how you do CSS. That Ruby code on the right could, I think pretty easily end up generating the CSS code on the left. That looks a lot like programming to me. Everybody says CSS isn't programming. I don't know, that looks a lot like programming. That looks a lot like object oriented programming. And when you start thinking about CSS in a little bit more, a little bit higher concept than it's just this dumb thing that makes pages look nice. If you actually treat it with a little respect and care what you're doing it'll treat you nice and thinking about it at a code level I think is the first way to get to that. By the way there's something else called object oriented CSS which is like a whole sort of technique to doing CSS that a woman who goes by the Twitter name Stubber Nella and I'm not even sure what her full name is talks at design conferences and that's something different. So I'm not talking about that. I put that caveat in because I got questions last time I gave this presentation about what this wasn't at all like what she was talking about and you're right, it isn't. So moving on to JavaScript. When you start talking about JavaScript the first thing you really need to talk about is do you need to build your pages to work without JavaScript and then we'll get to the next ones. So do you have users who turn off JavaScript? Does anybody, I met one person one time who said that he definitely knew people because he worked at a bank and it was like a security thing like 10 years ago that they couldn't use JavaScript. Does anybody else definitely have users that won't use JavaScript? Really? Right. So you can go for his use case and build your site like that. I tend to find that's actually ends up being a straw man because guys like you are a few and far between and you'll click. There's two of you. There's two straw men in here. So I do it because I like testing and I like testing with Cucumber and yes you can test JavaScript-y things with Cucumber and it's never felt right to me. It's always felt right to just build the stuff to not work to work without JavaScript and not have to go through culerity or selenium or some of those things. Like I like to just have it fast and not open up browsers and be all crazy and or not have to have this complicated CI environment. I like to just do Cucumber tests that are fast and work great. So I build stuff that doesn't work with JavaScript and it's really not that hard. You just can't use any of Rails built-in JavaScript-y things, which is okay because that code sucks, right? This is a link, I think this is a link to destroy which is one of Rails built-in RJS helpers and if you can debug that JavaScript I will give you a cookie because that is ridiculous and it's unmaintainable and it breaks all the time and you spend more time debugging and you can't test it. You can test it through selenium but you can't test it in any sane way that you would like to do on a daily basis and since I like to write code on a daily basis I like to do sane things on a daily basis. You also can't reuse it so that's the JavaScript itself. You could reuse that link and generate that link wherever you'd like but you can't reuse that JavaScript. It's actually not really that hard to write reusable JavaScript. This is a little trick that I learned from a coworker years ago which is you set up named closures which sounds really scary and it's not. We have, I set up a closure called FOTOR and that's my application. I keep all of my applications code in there and then I know that my application isn't messing with a plugin and plugins aren't messing with my code. I don't know if you get into, I don't know how many of you use jQuery plugins but all the time we end up with crazy things because they conflict because jQuery people love to do things in the global namespace. Every tutorial out there will show you how to write jQuery code in the global namespace and it'll step on each other all the time. So this is how I do it. I have anything above that return, I can write functions in there and those are private functions or methods or whatever and you can call those from inside of that named closure and you can't call them from outside that named closure. That sounds like a pretty good idea. I think programming languages have done that for quite a while because that tends to help with maintenance and anything inside of that return function which I usually leave as only an init function are callable from the outside world and the only thing I put in my document ready is calling that init so I'm setting up this tag widget. If you play with the code that I put on GitHub there's a little tag widget you can add and remove tags and there's an X to remove it and stuff like that. This is what that init function ends up doing and it's just setting up, it's just going through the page and it grabs all the divs and links and stuff that I care about that are gonna do something and puts a event handler on it and when that happens I call one of the functions that are inside of my named closure that I could unit test or whatever, they're my code. They're not somebody else's code and this isn't gonna step on anything. This is an example of the remove tag feature. So if you notice I don't ever use this in any of the code either because this always changes in JavaScript what this is and it never ends up being what I think it should be. So I try to stay away from this and I try to stay away from writing code in the global namespace and then I don't get problems where I'm dealing with elements that aren't actually the element I want and I don't have functions that step on each other. So I set up, I grab the editable tag and I hide it and I call it JavaScript request and it's pretty simple but I've never seen a jQuery tutorial that actually showed you how to do this. They would just tell you to, this is an example of the way jQuery would tell you to do it. This is for the edit tags feature. So they would just grab all the edit tags and they would just assign a click function to it and they would hide and show things based on that and that's all in the global namespace and other things could do other things to edit tags and it could call other methods and you just never know what's going on. But instead if you put it inside of a name closure you get all the things that come from namespacing your code in other programming languages also now exist in your JavaScript. This is the code for adding a tag and you can see all I'm doing is wrapping an Ajax request in it but if something changes if what happens when you add a tag changes in my app I'm not, I have it in one place. I have it in one file. It's not buried in line in some HTML. It's in one place. It has a name that makes sense. I could search my code and actually find the add tag stuff which you can't do with the Rails helpers and this has just saved me so much time. I don't know how else to sell it to you. So I'm not using IDs on any divs. I'm not grabbing just a specific div. I'm not using this, I already mentioned that and the closure is basically by setting all of this up in a closure each tag and each sort of tag widget inside of the page is its own thing. If I used IDs or classes, the JavaScript would be and I used Rails helpers, the JavaScript would just be repeated in the page every time if I had multiple tag widgets or whatever in the page and if I was safe I said I wanted to just take the return of an Ajax request and stick it in some div and it wasn't inside of a closure. It might stick it in all the divs but if you look in the JavaScript you'll see in a couple places where this would allow you, you're only working inside of the div that the click came from or whatever and that's all done through closures. So anyway, I know I went fast. That's my presentation. Here's where I am on the web. If you have questions. If you have things and stuff to name space but I've also seen views doing that where basically you have to design it because in that sense you would tend to do you know one class, one JavaScript class on profile. Right. And then you have to think about the dependencies and how many files you're gonna bring in to run on the page so that I can format performance. Yeah, right. So to reiterate what he said, if you do everything in external files you end up sometimes having to import lots of JavaScript files and that kind of thing. What I do to handle that is I have lots of files. I like having lots of files. I like having my code split up like that and when I deploy I concatenate all of them into a single file. Where I've worked before I worked at aboutus.org and we actually had a kind of over complicated system to do this but it was good in theory in that we had different sort of roles or something that if you were in this context we can concatenate certain JavaScript files together that only needed to be in this context and then we would concatenate other JavaScript files maybe all of them in one context and only a few in this other context and so you can set up contexts that you, so you only ever have one file per context but you can have multiple contexts throughout your site. So say if you had like on our site we have checkout and that's kind of a big deal and it's separate from browsing for events. So we could have one JavaScript context for, and this goes for CSS as well. We could, we don't do this now but we could have one context where we only have JavaScript and CSS for browsing events and we have another context with a single file that's only for checkout because those things are actually pretty separate and look pretty different. No, go ahead. But then you have to, I don't know what you're using on the, when you deploy to package all those assets but then you also have to make those rules as you package depending on your context. Right. So that's tricky. I mean we're doing the same thing and what I've noticed is that the way those namespaces were actually designed is that it basically forces loading everything or those separate contexts because of the dependencies. Right. And basically you end up loading 600K worse of JavaScript that you don't need. Right, yeah. That's the anti-pattern for sure. That would make the case for not namespacing and going with a dryer. Right. Right. One thing with jQuery is that when you, using this, is that when you select an object and you assign a function to something, it'll actually bind the function to the object that you're selecting so that it'll, it makes it a little bit easier using this to use jQuery. Yeah. Yes, there are, I would say that there are good reasons to use this and if you have a really good reason to use this, that using this is good, but the anti-pattern that I see is using this all over the place and you look, reading through the code, this has no meaning to me. So I never know what this is when I just have to go in and fix something. So selecting a specific element and assigning it to something and then pass, you can pass that into the, to the dollar sign function and I think it does very similar things to just using this. You just have to do it yourself. That's what ends up happening. So, yeah, if you don't have a designer, this talk was probably kind of boring for you and you should use less. But if you do have a designer and you have to work with somebody who doesn't program at all and isn't technical, then less just ends up adding headaches. Less fixes all the things that programmers and SAS for that matter. I use less, I guess SAS 3 is a lot better than SAS 2 was. But SAS and less fix all the things that programmers don't like about CSS, which is you can't do math and you can't have variables. But you're, if you have to work with a designer, they probably don't want math and they probably don't want variables. So if they're gonna do the CSS, just let them do CSS and I don't think you actually gain that much from less than SAS. But if it's just gonna be you, yes, SAS is great. Compass is like a CSS framework built in SAS that you can use and it's awesome, but your designer will hate you if you have one. Yeah, yeah, less.js is maybe outside the scope of this. But yeah, it's pretty cool. I would check it out also. Questions, any other questions? Cool.