 Well, good morning all. Let's just wait for these seats to fill up, and then we will get started. I'm just kidding. If you're looking for Sandy Metz, this is not her. We get mistaken all the time, but she's actually across the hall. Well, it's 10 past 11, so let's get started. So front-end fun, not frustration. This is going to be an unordered list of 12 items, probably going to be ordered eventually, but in random order, 12 things you should know as a backend developer, things that will make your life easier in working with front-end code, most notably CSS. And this is all going to be low-hanging food. Some of it you will already know, some of it will be totally new, but there are good things to know. If you have any remarks regarding this presentation, I mentioned me on Twitter, I'm at Roy. Be nice, though, if you have to say bad things about me, then don't mention me. So I'm Roy Jume, I hail from Amsterdam, Holland, and I flew here just to tell you how to have more fun in working with front-end code so that after a day of working with front-end code, the curb in front of your office doesn't look like this. And you don't need to call your friendly neighborhood front-end developer all the time. So we're going to get started with this list of 12. And the first thing I want to discuss is the box model and a better way of using the box model. So to a browser, every element on a page is a box, and the box model determines or tells the browser how to calculate the size of a box. So traditionally, or by default, a browser uses a box-size-in-content box. So the first three lines, like setting box-size-in-content box on everything that's totally useless because a browser does this by default. Let's say you have an element with a width of 800 pixels, 100 pixels of padding around it or inside it, and a border of 10 pixels. Then a browser renders it like this. So your element is going to be 800 pixels wide, and it adds the padding, which is 100 pixels on both sides, and it will add the border width, which is 10 pixels on both sides. So while you want this element to be 800 pixels wide, you end up with an element being 1,020 pixels wide. And this is super easy to solve by using the border box box model. So in this case, you actually need to use the all selector, the start, to tell the browser that all elements you should apply a box-size-in-content box to. The rest is all the same with width of 800 pixels, 100 pixels of padding, and 10 pixels of border. By using border box, a browser will actually set the total width of the element to 800 pixels, including the padding and the border. And this is way easier, because she says to you, a lot of calculations, a lot of headaches, keeping track of, I changed the padding, now my layout breaks because stuff doesn't fit anymore. So go border box and all the things, basically. A key here is that this is great for percentage-based layouts. Let's say you have a layout of three columns, each 33% in width. You want to add some padding. If you use the traditional box model, the content box model, you're going to add padding, and then your boxes will grow to a wider width than 33% and stuff just won't fit anymore. So if you do fluid design, responsive design, you're going to want to use this box model. Otherwise, you end up with nesting elements to set a width of 35% to the outer element and have a diff within to add the padding, and it gets messy real quick. So use this alternative box model. That was one. Margins. This has confused me in the past. So let's say I have an element with a margin of 100 pixels all around it. I never knew where my margins went. Turns out browsers collapse the horizontal margin. So if you have two of these elements, second top of each other, both with 100 pixel margin, they will have only 100 pixels of space in between because the browser collapses those horizontal margins. Okay, that's good to know. So browser collapses margins. Oh, wait. Not the vertical ones. This is in the specification somewhere. I don't know why, but this is confusing. So you got to remember your horizontal margins will collapse, your vertical margins won't. That's just the way it is. But this is one of those things that I and many like me used to struggle with. Like, I added margin, where did it go? This is where your margin went. Positioning. This is the default. By default, a browser treats all elements as if they're statically positioned, which means nothing else that they appear on top of each other or above and below each other, not on top. And when a element grows, the element below will move down a little. When element two to the left becomes wider, the element on the right will go to the right. Everything is in the normal document flow. That's what position static does and which, again, is a default. Then there is position relative. This is mostly used by people who want to absolutely position an element, not relative to the document, but to some other elements. So they set position relative to the parent element and then add whatever they want inside this element, give that position absolute, and then the top right, bottom left offsets for the nested element are relative to this one. So that's the most common use of position relative. What a lot of people don't know or don't realize is that you can still use the top right, bottom left offsets on relatively positioned elements themselves while keeping them in the document flow. So while we're using position absolute, top zero, left zero, it will just appear on top of everything and you will yank it out of the document flow. Position relative in using those top right, bottom left offsets will keep an element in the regular document flow while still being able to shift it to the right, to the left, or up and down. That's good to know because the one thing that gets troublesome, especially when moving into responsive design, is using absolutely positioned elements. Things are going to break, things are going to overlap and by relatively positioning them and still using those top right, bottom left offsets, you won't run into that issue. And then there's position fixed. So a fixed element always appears, that's always relative to the viewport. So if you have a relatively or absolutely positioned element and you have an element within that you get a fixed position, it will be pulled out of the normal document flow and out of its parent element and will be relative to the viewport. So this is what's being used for those sticky menus on top. If you scroll, the menu just stays there or a sidebar that you can toggle to slide in and out. That's what position fixed does. Now positioning is hard. Knowing when to use what, making sure stuff works across browsers. There are some browser quirks. That's a tough job. So what people often do is just add position relative to everything until it works. SMZ index in there as well. So the stacking order is okay. So that's something, that's a way to tackle it. But I suggest reading up on those positioning values to see how to do it in a more clean way. I'm not going to dive into this any deeper because you already know that you can static as a default and you can use position relative with those offsets. And while I sip some water, I'll have you enjoy some clowns. Inline block elements. Whenever I tell someone this is a thing, this exists, it pretty much makes their day because this makes so many things so much easier. So we have two kinds of elements in HTML. We have block-level elements and inline elements. Block-level elements are things like a diff, a paragraph, an h1. Those always appear above each other, so they take up the full available width. They always have a width of 100%. Then there's inline elements who... Or they are as small as possible, basically. So you have a strong tag, a strong element that doesn't span a entire line. It's just somewhere in your text. So they're inline. The downside of inline elements is that you can't apply dimensions to them. So you can't set the width or the height and some other properties of an inline element. Sometimes you want to. So whether we resort to, we start using floats. We use floatable things. Float left, float right. We add clear fixes and clear both and stuff breaks. But if you float an element, even an inline element, it will turn into a block-level element which you can set dimensions. The downside is floated elements weren't meant for that. You can float an image in a paragraph, so text wraps around it. That was float is for. Not for layout. So inline block elements kind of fix this. So let's say you have another list of consisting of four list items. Here they are, just the all block-level elements. So all those allies appear above and below each other. And you can make those inline while still behaving like a block. So let's set all those list items to use display inline block. Now remove the margins because we want them to touch each other for some layout purposes. And it looks like this. So they're still in the regular document flow. So their parent, UL, will still grow with the content within without using float, some without using clear fix. Now I set the margin to zero. Yes, yet these allies do not touch. There is some white space in between. And that's caused by new lines, spaces. So I'm going to assume this LI is coming from some sort of loop. They have new lines in between them, which is a text node of white space, and browsers will just render that. So they will never touch. So if you tell the browser to make each of those LIs 25% in width, then the last one will wrap to the next line because there's a white space in between. But there are several ways to fix that, but I always do it like this. So on the parent element, I set the font size to zero and then kind of reset the font size on the actual LIs. So the white space is still there because I don't want to go into my markup and strip new lines or spaces or ever. So the white space is still there, but with the font size of zero, you don't see it. So to me it's a pretty clean and neat way of fixing this. So they end up with actually have those LIs next to each other without any white space in between. Key here is no more floats to clear. Like I said, floats weren't meant for this. They will get you in a world of hurt. An inline block is pretty much the best thing that has come to HTML in the past few years, or CSS. Vertical alignment. So I asked this question on Twitter, what do you struggle with as a backend developer and working with front-end? And then a lot of people replied with vertical alignment. I have this login box for my app, which I want to appear in the exact middle of the viewport. So horizontally and vertically centered. Well, it's an easy way to fix this. You create a table, give it one row, one column, put the content in there. You make sure the table is 100% wide, 100% high, 100% high, and you set the table cell to vertical line middle and text line center. That works. So tables are way better than CSS. Yeah, I'm kidding. So what were you thinking? So we can actually mimic the behavior of tables while still using semantic markup. I'm not saying this is semantic. I'm assuming that you'll have markup in place anyway that you can reuse to apply the following CSS to. But in its most basic form, this is what works. So we have some element with a nested element, with the class name of content in this case, with your login box within that one. And we set an element to use display table. And now this diff is a diff which behaves like a table, which means you need to give it a width of 100%. Probably a height of 100% as well to make it mimic the table behavior. And then that nested element, the content element, we set it to display table cell, which, as she would have guessed, makes it behave like a TD. Again, set it to vertical line middle and text line center. And this works pretty well in modern browsers and IE, aid and up or something. So you're okay with using this. So if you were still using tables to vertically position stuff, stop doing it. So an alternative that method that people have been using was taking this element and then absolutely position it, give it the left offset of 50%, a top offset of 50%, and then give it a negative margin of half the width and half the height of the element to get it in the middle. That works well on larger viewports, but as soon as your content doesn't fit the window anymore, someone who will just fall outside of it and you can't see it anymore because of the absolute positioning. By doing it like this, it's going to be centered and if it doesn't fit anymore because your viewport is smaller than the element you're centering, you just get scrolling behavior. So this works well on mobile phones as well. So of course key here is this is semantic markup behaving like tables. And there's nothing bad about that. So using a table for this would be a bad thing, but having semantic markup behave like a table. That's all good. So as you have probably noticed, there isn't really like beginning or end to these things. This is totally random and use whatever you like. Button styling is hard. Especially I have to support some crappy browsers which is IE basically or older IEs. Styling buttons is hard. So there are two ways to mark up a button in HTML basically. You can use an input type submit or you can actually use a button element. And if you set the type attribute to submit on the button, it will actually behave in the exact same way as the input. So you can just tap to it. You can hit enter in the form to submit it, et cetera. So this works perfectly well. Well, the difference is clear. The top one uses a attribute to set the text inside of the button while the one at the bottom just has a node inside of the opening and closing button tag which allows you to use HTML inside of your button. It allows you to add an image there if you want to. So this is way more versatile. It is just a single word in a single styling. The input type submit or just input type reset if you want to use a reset button. Don't use a reset button because people will hit that one by accident. Then that works if you want to have more fancy button styling. Yes, use button. Pseudo elements. Pseudo elements is HTML. Well, there are elements. Yes, HTML elements that you insert into the DOM using CSS. So they end up in what's called the shadow DOM. Looks like this. So you have an element with a class name element. Column, column before with some contents which then appears in front of this element. So in front of the element with class name element, I should have chosen different class names probably. A string consisting of the word string will appear in front of that. Or if you use column, column after, it will appear after that element. This is the UTF-8 representation. This is a UTF-8 arrow in representation that CSS actually gets. So the backwards slash with some information about the UTF-8 character entity and you can just use UTF-8 elements inside your... have them added to the shadow DOM. As you see, this uses two columns. So column, column before and column, column after. What you'll also see is this notation using just one column. That's because the two columns is, according to the CSS3 specification, and this isn't. The upside of doing this, though, is that while your CSS doesn't validate against the CSS level three spec, this works in IE8 and above while using the two columns only works in IE9 and above. So if you're not bothered with... If you can be bothered with supporting IE8, it's okay to use the two columns, but I always use this one because it's just a small change. It makes it work in IE8 and we shouldn't give people who have to use IE8 a hard time because their lives are pretty much in ruins anyway. So I used the single column. Of practical use cases, let's say you want to let people know that a link is a secure link because hard bleed. So this is a CSS level three selector that says for every link, which is a href attribute, so what it links to, start with HTTPS, add uses SSL in between brackets after the link. That can be useful, or maybe you want to show an image instead. So if the href attribute starts with HTTPS, we're going to add more than just a string because what we're adding is not a string, it's an actual element that we can style completely using CSS. So we set the contents to an empty string because you don't need any text in there. Set it to display inline block because you know why, no floats. Give it a width of 12 pixels, a height of 12 pixels, and set the background image to some padlock icon, which I assume is going to be 12 pixels wide and 12 pixels high. Eventually, you will not get this to work and it will take you two hours to figure out why. In total, I spent days on that. If you omit the content attribute with the empty string, this will not do anything at all. So we don't know how many people are here, but it just saves you 150 hours of headaches. You are very welcome. So although you're using this empty string, it still needs to be in there, otherwise it just won't work. Now before we set all items we need to use the border box box model by using the star selector. By just using that one, it won't apply to pseudo elements. So you actually need to add this. So apply box size and border box to all elements plus all pseudo elements before and after, which again is good to know, otherwise you're going to have no idea why your padding is enlarging your element. Those pseudo elements make for less markup in your HTML and it's definitely more responsive. If you're not familiar with responsive design and media queries, you can tell a browser to apply certain CSS based on device characteristics. So the viewport dimensions are the pixel density of a device. So you can target a retina device to use different CSS than a non-retina device. So here you can change the markup by modifying the shadow DOM based on those media queries in your CSS. So if you have a huge viewport, maybe you want to add the string uses SSL to a link. If you have a smaller viewport and it just doesn't fit anymore, maybe then you want to show the padlock icon. By moving this into media queries in your CSS, you can change your markup on the fly without touching your HTML or adding extra spins in there that you just set to hidden based on some JavaScript wizardry. So for responsive design, pseudo elements are immensely helpful. Oh, look, a mechanical chicken. So CSS electors. I just briefly touched on the selector that selects elements which href attribute starts with a certain string. There's more to CSS level three selectors. Like if you find yourself using... This is the only bit of rails in this presentation, by the way. The cycle method. You can just do that using CSS, right? So if you're unfamiliar with cycle, it will just... If you put that in a loop, you're looping through a list of items. You provide it with two class names, other than even. Then it will alternate between those in the markup, which is great for alternating table rows. So give each other row a different background color. You can do that with CSS level three. So let's say you want to do this table example. Here you take every even row in a table. So that's rows two, four, et cetera. And then each TD within make those have a gray background color. Do away with all your cycle methods. You don't need them anymore. Before we matched a string on what it starts with, using the dollar sign, you match on the end of a string. So here, using pseudo elements, which is a wrong code sample, by the way, because there is no column before or after there, if the href ends in .pdf, they're going to let people know it's a PDF. You could just write this, or you could use a PDF icon, which is helpful because people just don't like opening PDFs online. And for some reason, restaurant websites just don't get that. If you want to use any menu on any restaurant website, it's likely going to be a PDF. They could warn us if they would actually add this bit of CSS. Target is an interesting one as well. This CSS rule is matched when... He's going to show you some code because otherwise it's going to be too hard to explain. So you have some element with ID foo, with some content. When a target matches, it will have a red background. So if you go to, say it was on below URL, you would go to hash foo in the URL, then the paragraph would have a red background because the target matches the element. This is great if you find yourself working with, like, scrolls by scripts or things like that. So you scroll on the page and you need to change the active color of some menu item or you want to link directly to a section and make sure people know which one it is. So you can link in your documentation, link to section, whatever, and highlight it by giving it a yellow background color. By just... It's just three lines of CSS, right? And it will immensely improve the usability of your app. The CSS level three selector spec is a spec worth reading. It's not too complicated and there's way more you can do with targeting elements based on whatever. So I want to briefly touch on CSS animations. I believe animation is styling, not behavior, because it's basically just eye candy. So I don't want to write a bunch of JavaScript to animate some sidebar that moves in when I click some toggle button. I want to do that with CSS. So in CSS we have transitions, animations, and transforms. So transition just changes a simple thing. So here the link color is red. We set a transition on color. So if you have more attributes, this will only... More properties, this will only change the color value. So now when we hover over the link it will transition into blue and it will take 0.5 seconds to do so. If you would replace the transition color with transition all, it would transition everything. So if you had a width and a height set plus a color, it will do all of that at once. That can get pretty crazy. So I just try to limit it usually. So back to the sidebar example, which you wish to slide in and slide out. Like on mobile, for instance. It's a common design pattern now. So we have a sidebar, some element with a zero width, with a transition on the width. And then if the sidebar has both the class names sidebar and active, we give it a width of 200 pixels. So now using one line of JavaScript, a jQuery in this case, we toggle class active on the sidebar, which adds the class name to the sidebar element. CSS picks up on that and it will transition and smoothly resize that sidebar to a width of 200 pixels. By toggling again, it's going to shrink again. So you don't need jQuery, animate, or whatever to do this. I believe it's clear to just do this in your CSS. A browser is smart about using the use of transforms, whether it should activate hardware acceleration. So it can offload some computing to the GPU. In some cases, complicated cases, you may find yourself that a browser does not go into a hardware accelerated mode, but you still want to trigger it manually. This is a hack, basically, to do so. So you do this transform by a value of zero. So nothing happens visually. But this is enough for a browser to say, okay, I'm running in hardware accelerated mode now. Be careful about that. It's not by definition so that using hardware acceleration is better, faster, or less memory-consuming, or less battery-draining on a mobile device than not using hardware acceleration. So in general, it's best to just leave this to the browser itself. Now, JavaScript libraries are becoming smart about this. So if you use jQuery, animate, for instance, it will see if your browser supports CSS3 animations. If so, it will offload it to CSS. And otherwise, it's just going to use JavaScript. Fluidity. To me, fluidity is a step between fixed design and responsive design. So fixed design is this fixed size, and you'll just have to scroll. Responsive design is using media queries to change layout based on device characteristics. Fluidity is something in between, which is pretty basic, and this is just a quick win. So say you want to center your app. You want to have a min-width of 320 pixels and a max-width of 1280, because you don't want people on their 4K display to have your immensely wide website and use margin zero auto for the centering. This case, it's a fluid layout. It will shrink and grow with a browser window, but it will never go below a width of 320 pixels and will never be wider than 1280 pixels. If you have a wider viewport, it will just be centered. Improves readability, especially on text for people using wide screens or large screens. And let's just add those two lines on some wrapping element, some diff that's around all your content. It's a small fix and will improve people's lives. So this is just low-hanging fruit. You can just put in those three lines of code and it works. I want to briefly touch on SAS. If you use Rails, you're most likely using SAS as well. So there are some new features introduced in SAS 3.3, like placeholders. If you find yourselves using mixins a lot without using parameters to actually change the output of a mixin, it's probably better to use a placeholder and extend those. So placeholder starts with the % sign, underline on hover, how descriptive. You have some link on the bottom. You extend that placeholder, and then the starting on top will be applied to that link. The difference with using mixins is if you do this in a mixin and called 100 times, then this piece of CSS will be added to your output CSS 100 times. But using extent, it's added only once and SAS will be smart about just adding more selectors. But the CSS properties will only be added once. And then there are SAS lists. Well, SAS used to only have simple arrays. You can now actually have key value pairs. So you have this SAS list of a key with locked and error which are states for something and icons that go with them. You can iterate over them in each loop, guess those values on the key and value variables, which are just named like this. You can use any other variable name you want to. And then the output is going to be dot locked on the first iteration and dot error on the second one and set the background image URL to that image. So then in your HTML, you can put a class, locked or error class name to an element and use this background image. This is only two, but if you find yourself implementing 60 different social sharing icons, this saves a lot of work. So SAS has matured. It's like programming in your CSS. And this is just a tip of the iceberg. You can do way more with SAS now if you're interested in the sort of thing. And I am because it makes my life easier, less typing. Hey, I love, like, who likes working, right? I want to briefly touch on SVG. I will just immediately jump to the key takeaways here. SVG is a vector image format which is retina-friendly because it's vector, so you can resize it without loss of quality. And it compresses well because it's just lines. It's just coordinates of draw a line between these two points and fill them with this color. So it compresses really well. And this is supported by IE9 and UP. So this was just a random bunch of things that you may or may not have known already that will make your life easier in working with front-end code. We'll have a few minutes for questions. I want to thank you for listening. My name is Roy Dumay. I'm with a company called AppSignal, which is the most awesome error-tracking and performance monitoring tool for Rails out there. I know they all say it, but for me it's true. And if you have any questions, I'll be happy to take them. Ask them now or find me later. Ask them on Twitter at Roy. Shoot me an email. And you can download these slides at www.roydio.com. RailsConf. Thanks.