 I'm John Albin Wilkins. I'm a longtime Drupal contributor. I've been doing web development since 1993, so over 20 years, and Drupal development for almost 11. Been around a bit. I am a senior front-end developer for previous Next. They're pretty awesome. I live in Taiwan, but they flew me out here just for this conference. So thank you for that. And I've got a lot of free gifts, open-source software that I work on. ZenGrid is a SaaS-encompass library that allows you to easily create layouts, normalized SCSS for SaaS-encompass. KSS Node, I'll be talking a lot more about this one later in the presentation that does automated style guides. Get SVN Migrate, which if you have any subversion repositories running around, this can automate the process of getting rid of all of them. And then, of course, the Zen thing for Drupal. And today, I wanted to talk about where we headed in front-end development. I'd like to start with actually a quote here from Nicholas Gallagher. Yeah, it just doesn't sit up there very well. Is there a way to angle it so it doesn't, my laptop isn't? I don't have it. It's got that nice Mac bevel on the bottom that just goes, whew. I think it's going to make it worse isn't my long end. Oh, you mean from, oh, that's tricky. Angle it more, even make it, or yeah, gaffer tape. Thank you. Excitement. I'd like to start with a quote from Nicholas Gallagher. He said, are you new to front-end development? Here's a secret. No one really knows what they're doing either. This is completely understandable, because we have tons of front-end blog posts that are talking about all these different things. Vagrant web components, the Twig Handler is Jenkins, CSS, JS Minting. And we're sort of expected to know about all of these different things. And it's really, really overwhelming. And you can't really make any sense of it all. Frank Chamarro said, everyone is describing the one little piece they've created, but they don't explain or even reference the larger concepts of how all of these elements link together. And this is sort of understandable. We're at a tech conference right now. People like to focus on the technology and what they're in world, mostly geeks here. And so, yeah, we tend to focus really intensely on that technology. And it's sort of like getting up really, really close to a painting and sticking your eyeball and seeing all these wonderful brushstrokes. You can see the paint palettes that they're using. And it's great. But you can't tell what painting is. You can't tell the bigger pressure until you start looking at the process. And then all of those, the technology details make much more sense in the context of what's actually going on. So when we step back and try to figure out what's going on in the front end and trying to make sense of the front end technology, basically, I'm going to describe any project, any front end project on GitHub, I'm going to describe one of these three things or combination. Front end performance, components, or continuous integration. Front end performance, I'm sure everybody's heard of that. And you're trying to make things faster. The components, continuous integration, these are getting a bit jargony. So to simplify that, I just want to say that it's making shit faster, making shit modular, and then automating the shit. OK, that's it. Those three things, that's the entire spectrum of all front end technology, OK? So I've given this talk a few times. It keeps improving upon it. And I gave a talk very similar to this at the last Drupal South in Wellington. But one of the things that happened right after that was that previous NXX was sent me to a scrum training. And I learned about agile development. And I want to talk about that was a really profound experience for me. And I want to talk about the problems that we're having doing CSS is directly related to some of the ways that we're doing projects. Here's a traditional waterfall project. You have planning, designing, and developing and theming. Usually it works in this direction. Maybe there's some overlapped development and theming. But you have all of your designs done ahead of time. And then you do the theming bit. And the problem is that if this starts to slip and take longer, then you get to this spot and you realize, I don't have enough time to finish all the theming. And then you have to negotiate with the clients. Oh, we're not going to do that bit of the design or that bit of the design. And effectively, what you end up with is half of the stuff is done. And that means you've wasted this time and this time. And you basically could have completed the entire project in half the time if you'd known that you were going to miss the date. That's not so good. So people, they start to get better at it. Maybe they'll reevaluate things here at the end of the design. They're like, oh, we're not going to hit the deadline. We can already tell. And then they're like, OK, we're going to design or over-designed it because we can't implement all these designs. And we'll take off those bits. And then give them a style guide. And then bend the project. They're reviewing it like, well, what on this is missing? Oh, remember, we talked about that. It's not going in like, oh, yeah. But there's a lot of conflict then between clients and the team that is actually developing it. And agile development really tries to solve these problems. And the sort of core concept in any agile development is reducing your risk by controlling and minimizing your risk. So here's what an agile project would look like. You have these same start and end deadline. But instead of just starting and doing all of your steps until you get to the deadline, you divide that time into a series of sprints. Typically, they're two or three or four week sprints. They have a very defined start and end time. And then you work with your client and you come up with a feature backlog, which basically is a list of all the features that they want to have in their project, on their websites. And you prioritize it. You say, these are the most high priority features that the client wants. I should say, when I say you prioritize it, the client should be prioritizing. The owner of this project should be prioritizing these things. And then you start with the first sprint. And basically, you guys say, we're going to work on these first couple of things. And we're going to complete them inside this sprint and then show the client what we've finished so far. And then you go into the next sprint and you pull in some more features like that. And at the end of each sprint, you're reprioritizing what's going on with left on the list. So the clients are always aware of what's the most high priority stuff. And you really do need to reprioritize at the end of each sprint because they're understanding the project will change as the project continues. You always have these problems where you're like, oh, we asked for this. Well, actually, I know you asked for this other thing. You didn't explain yourself well. This can get rid of those problems because the worst case scenario is at the beginning of the sprint, they tell you something bad. At the end of the sprint, you discover there was miscommunication. And that just means that in the next sprint, you iterate over that feature and get it right the next time. And then it really reduces the risk because they're not going to wait until the very end to discover that the client didn't communicate with the client very well. So each two sprint, prior trades, project goals, completes a set of features, and then creates sort of a minimally-releasable product. I won't get into a lot of these agile specifics, but I just want to talk about how what does it mean for agile and the web to work together? When I got hired by previous NEXT, my boss, Kim Pepper, was like, OK, I know you've been doing a lot of stuff with CSS, trying to make that very modular. How do we get designers into this agile process? And I hadn't yet trained on agile. And I said, no, I have no idea. We'll figure that together. And then once I did the training, it became really, really obvious. It became simple. And basically, agile to the web plus the web means style guide-driven development. And the only two requirements of style guide-driven development are component-based design and automated style guides. Now, if you remember from the earlier slide, components that means modular, automated style guides, that's the automation part. So we're talking about making our designs modular and then automatically documenting those designs inside a style guide. That's the core of what style guide-driven development is. And I want to talk super briefly about what we're doing wrong with our CSS currently to help you understand why making component-based design is so compelling. I used to have four or five slides here that talked about specifics of how you're doing stuff wrong. But I want to make this fast. And maybe we can spend some more time at the end discussing things and go ahead and go over some demos. So let's do a quick survey instead to talk about what we're doing. Drupal 7 CSS. How many people here really like Drupal 7's core CSS? Yes, nobody has raised their hand. Yeah, so I was heavily involved in the Drupal 7 development. You know, I'm sorry. It seemed like a good idea at the time. When you work with it day in and day out, you start to see some of the issues that you have. You have super high specificity on some of the CSS selectors, overly generic class names, like title and content, just bad CSS class names and general node. It's not particularly good CSS. And design components are basically a way to give us a framework for writing better CSS. And when I say design components, the front end development community is starting to get together and consolidate and understand this concept. But for some reason, we can't decide on what to call it. So component is the same thing as object and OO CSS, which is object-oriented CSS, module in SMACs, which is scalable and modular architecture for CSS. And it's the block and BEMs, block element modifier. And also sometimes called a UI pattern. Pattern library is full of components, basically. So I'm trying to like, it's a component. It's a design. But anyway, that's what I'm talking about. I'm talking about all these things. They're all the same thing. So CSS design components is basically it's applied to a loose collection of HTML. I'm not trying to enforce any particular DOM structure in the HTML. It's repeatable, which means that you can apply that design multiple times on a page, even if it's never repeated. So your header should be a component. It should write it in a component way so that it's modular, compact. It applies exactly that header design. And theoretically, you could apply it multiple times. But if you just write everything as a component, it's going to make your life easier. And it's also specific. Like I said, it applies that design specifically to the elements that you apply that class to. And self-contained. The style shouldn't bleed off into other things. And finally, nestable. So you can have a component inside like the HTML DOM of another component. That's perfectly fine. And let me show you an example. This is a PRI website, which I helped to do the CSS for this, is one of the first sites that I tried out these ideas of component design. And you can see here, there's this little, it's hard to see on the screen, but there's a little circle there with a number in there, which is like the share count or something that can predict what it does. But that is a repeated design element. Actually, I'll show you at the bottom here. You can see that it's also, that share count is also over here. So I made that a very simple as basically, I think there's a span or a div or something wrapped around that number that says that it is the share count design component, right? And then we also have here at the top with this, the main picture, the main title and the teaser text here. This is the feature components. So like showing off the feature story on this page and then includes different pieces. We have the sort of taxonomy, politics and society, the feature image, the feature title, feature dates, feature text. Those are different parts of a more complex design components. It has multiple laced amount elements. It's gonna have a couple of different classes on there and you can see there that the, that other share count component is nested inside it and basically went through the entire site and tried to find these repeatable patterns and made those into components. And how many people have heard about SMACS? Fair for you. How many people have actually read the, you know, even the free book or the paid book, few of you. So Jonathan Snook tries to categorize different CSS using SMACS, base layout, modules, date and theme. It's like he looked at Drupal and said, how can I troll them as much as possible? So when we, in the Drupal community started looking at this, we were like, oh, this is awesome, but we kind of need to use different terminology or we're gonna get really confused. So we usually use base layout, component, state and skin, but they're the same categorizing ideas. And so when I started working on PRA and other websites, I thought this was pretty good, but I was having a little bit of hard time actually implementing it on my CSS. And I realized that it was, that really the state and skin are describing, they're describing components themselves, they're not really, they're not equal to components, they're parts of components. So that was why I was having a little bit of trouble understanding SMACS. And then there was also some missing bits here, which BEM helped out understanding as well. So we have like the component wrapper, elements, modifiers, states and skin. And so let me go over all of these different pieces here. Base. So in SMACS, base is basically, all of your rules that are using HTML elements as the selector, that's your base styles, okay? You're describing what the default look and feel of an HTML element is on your website. I use the base styling as, I try to target that styling to be the styling that you would see in the main part of your site, in the main content area of your site. So like, WissyWig editors are famous for having, making it difficult to get the right HTML that you really want. So I usually let the WissyWig editors do whatever they want for HTML and that base styling then is trying to apply the design that I want to those elements in the main part of the content page. And then everything else is overriding that those base element stylings. And I should say that as I started thinking about this more and more, base and layouts, they're not separate from components. They actually are components too. They're just a specialized kind of component. So layout components are basically, the only thing that they do, they're specialized in that instead of applying colors and background colors and all that stuff, all they do is move large sections of your page route. That's all they're concerned with. They want to put the left side bar over there on the left. They want to put the footer down at the bottom below the other stuff. That's what they're concerned about. And that's the only thing they do. Whether you consider padding part of the layout or not, it doesn't really matter to me. I usually put padding inside my layouts because my content goes inside the layouts and therefore I need gutters between my content. And that's the only thing they do. They shouldn't add any other kind of styling. And then next, these are the different sections, different parts of a component, components, element modifier, statements, again, I'm going to go through several different slides here that really help you to visualize what these different parts here. I used to ramble on and point at the slide or if this is an element and it was, I decided to go with a visual metaphor. So I got this idea from this quote. This is, I tried to describe, explain radio to people who have never heard radio. This is back in the early 1930s, 1920s. I said, you see, radio is a kind of very, very long cat. You pull his tail in Los Angeles and it's meowing in New York. The only difference between radio and this is that there is no cat. That's Albert Einstein, brilliant quote. So I'm going to try to describe these things using the flower component. So the component itself oftentimes has some sort of wrapper elements. The class that you would apply to that is just flower, dot flower, that's our selector, right? And then if we start breaking these down into elements or different parts, we will have the flower petals. This double underscore thing here is a BEM methodology of separating these different concepts of, our component is the first part of it and the element is the second part and we need some sort of thing to go in between them so you can easily tell which is which. You can use other things if you don't like double underscores. The double underscores and the double dashes that I'm going to show you in a second here are the Drupal 8 standards that we decided to adopt. So these are petals. We also have flower underscore underscore face, flower stem, flower leaves. These are all different pieces that require specific styling within the component. But I want to point out that we are not talking about a DOM structure when we're defining this name. This does not mean that leaves has to be a child element of the flower parent element. This is a loose collection of HTML elements, as I was saying before, because you can also have flower bed. And obviously, a flower bed is surrounding the flower. It's not inside the flower and yet it's completely related to the flower. You're not gonna have this flower bed styling anywhere else except with the flower. Next we're gonna go on to modifier here. This is a variant of our components, our flower component. It now looks like a tulip because we're applying this flower dash dash tulip class to the element. And so you can see that we've changed the way that the petals look, but everything else is the same. The face, the leaves, the stem, everything else the same. Now a lot of times when people see this double underscore and double dash and they start writing their own components for the first time, they get a bit a little bit crazy. Don't make it complicated. It should be very, very simple. I pulled this next selector from an actual website. I'm not gonna tell you which websites. But you can see here, they went crazy with their double underscores. Channel dash, tab underscore, underscore, guide underscore, underscore, upcoming dash, video underscore, underscore, info underscore, it's your time. I was really happy to learn yesterday that we were gonna display our slides in widescreen format because this is the first time I've been able to show the entire class on screen. Make them simple, please. I'm gonna go a little derail here off a second for two. On the meaning of semantics, right? Content semantics, like what your actual content is, like articles, blog posts, news, events, that sort of stuff, that's handled by HTML5 semantics really. So let's make our class names be design semantics, right? You're trying to describe the design that you're applying, right? I mean, this makes sense. You're adding styling with these CSS rule sets. The name of the selector should also be the name of the design, right? So those class names should be meaningful to the developers and designers. And they don't need to be meaningful for anybody else. And also, don't stress out, I mean, I know that naming things is really hard in CSS in computer science. Don't stress out about too much. You can name it whatever, as long as you convey some meaning to the group of people that you're working with. You can always rename it later, that's easy. So let's jump back over to our component again. So here's a state. This is what happens when you hover over the flower component. I have a nice little v-styling on there, colon hover. In addition to these pseudo classes state, you can also have like a JavaScript state. So you had some sort of form or something that you filled out and then suddenly it's, you're adding a new class with JavaScript so that is pollinating, right? That's another kind of state. There is also a media queries, right? A media query is a state of this component. For example, this is the desktop version of our flower component, right? So at medium and with the 48Ms, that's what it looks like. And of course, print styles, those are also media types. That's another kind of state. So here's our print styling. And then lastly, skin. I didn't used to have a slide for this, but then I gave these slides, I presented them, the last time I was in Australia, at a meetup and somebody says, do an is Knights skin, right? So, new slide. A skin is basically, let's see here, there we go. It's a global modifier. So it creates a new variation of how this looks, but it's applied to every component on your site, right? So the actual CSS rules for this will be next to all the other CSS rules for this component, but the selector itself, that is night, you know, and that class name is gonna be on like the body tag or something, or some sort of div that's apparent of a lot of different components. So this skin is basically just a global modifier. If you wanna take a look at these, there's actually a copy of all of these in CSS form and automated style guide of this is available here, johnelman.github.io slash flower dash power. And here's an overview of all the selectors in one go here. So we have the components. Sometimes you can't name a component except with two words, just can't figure it out. You can either use camel case and people in Google are like, oh, we don't wanna use camel case. So we ended up with this dash in between each of the words. This is why of course in the modifier has to be double dash, right? So then our modifier is creating a variant of the components. Our component has lots of pieces. So we have multiple elements. And again, an element might require two words to describe them. Sometimes that element will have a variant styling depending on the global modifier. So there are two ways you can do that. You can either write this more complex CSS class name with the modifier here, or you could actually create a selector that use that first one there and then this third one, right? As your selector, that would be fine too. The same selector. But my point is that this is the most complex class name you should ever write. There shouldn't be anything more complex than that. JavaScript state, pseudo class states, media query states, and then our global modifier skins. So that's it. It's not really that complicated. If you write all of your CSS using these as the selectors of your rule sets, you're gonna end up with much better CSS. Here it is again. Sign components, they're applying to a loose collection of HTML. You should be able to apply the same design to a different kind of HTML. There's no reason why you couldn't apply that share count to a different HTML element. Repeatable, specific, self-contained, nestable. One last time here. Base components, layout components. Again, those are just specialized kinds of components, and then components are these different things. Elements, modifier, states, and skin. I have a, there we go. What I just described is basically the jubilate coding standards. We have, these are completely new. We had like draft CSS standards for like three years. And then finally I was like, this is enough, enough. Let's actually decide on something. So last year we finally have official CSS coding standards and they are there. And they will also describe a really great documentation about all of these classes and modifiers and stuff are all up there too. And also the pitfalls. They go into detail about what we're doing wrong so that as you're writing CSS, you can go back and like, oops, I shouldn't be doing that because this is why it's a pitfall. Really great documentation. So when I'm writing CSS, where do I put it? I'm using the SAS. I hope that most of you are. This is my organization. It's very simple. I have an init partial that has defines, or sorry, it actually loads the variables at the top. Then it loads all of the third party libraries that I use like the breakpoint module which is awesome for control night v decrees. And then some sort of layout module. Singularity or Zen grids or whatever you want, or Susie. Those are all good ones. Then inside the base folder, I'll have all of my base components, the styles that are designing the HTML elements themselves going there. Then I'll have layout with all of my individual layouts that are completely repeatable. They go in there, and then everything else is inside components. And I mean everything. Each component, oh yeah. Each component goes in a separate file. I'll open up that in a second. Sometimes I have custom mixins or custom functions. I'll put this into the library folder. But that's the entire structure. Styles.scss, that's the actual main style sheet that gets generated in the styles.scss. That's the only bit that goes inside my .info file of my theme. And then everything else is loaded by styles. See, imports the init, imports the base, imports layouts, components. How many people here use Magda? What's the name of the, globbing, sask globbing? That was an old deal. Yeah. Go ahead and use that, it's fine. You don't have to do, spell it out like this. We use sask globbing as well, but if you don't use sask globbing, that syntax can be confusing. This is how you load it. So here I've opened up the components folder, and you can see that every single component is a separate file. When I tried this out the first time, I had been working on a project and then it was like it was crunch time because we weren't yet doing Agile. And so they brought in another friend and developer to help me finish. And he took a look at this folder, showed up and he was like, oh my God. And he was freaked out for a good five minutes. I wasn't next to him, so I didn't know about this until later. But he was like, okay, breathe. And he had this ticket, he was like, okay, I need to, there's a bug in this one, styling. So he did this, he inspected the Dom. He saw that there was this class name on that thing and then he went and looked on the components folder and lo and behold, there was a file name that had that exact same class name. He was like, open it up, and there it was. It's ridiculously easy to find your components when you're doing development. If you use this, it looks crazy because I'm only got to down to the Ds on this list. But it's incredibly simple organization. Some people like to have subfolders. The subfolders confuse me. I can't figure out where anything is. I have to look at all the different subfolders then. Anyway, but this is less of an issue now that we have source maps where it can like show, in the inspector can show you exactly the file name of the SAS part. Oh, that's pretty awesome. So then you can use a subfolder to use source maps. So now, I know that some of you are thinking, this sounds great, this is awesome, but I'm a Drupal developer. And there's no way in hell I can insert that exact class name into my markup because I have no frigging clue which render API slash theme function slash template file, this piece of slash content slash database, where this piece of HTML is coming from. But there's good news. There's the fugly selector hack. What I do, this requires SAS. You can't do this with CSS. I mean, you can, but you'll get messed up. Basically, I write the selector in the DOM that I couldn't change because I could not figure out how to like insert the class I wanted into that link inside this piece of content. And then I write the class name. I wish I could use in the DOM as the thing that I'm extending, right? So this goes in the bottom of each of my component files. So I've written a design at the top using these amazing, wonderful class names that I can actually get into the source. And they have this percent sign at the beginning, which means it's a silent selector inside the selector. So like I'll have, at the top of this file, I actually have dotfeature underscore title dash link under the assumption that it could eventually get into the DOM and then comma and then percent sign feature underscore title dash link. And then I'll write this at the bottom, which is the ugly Drupal selector that I am forced to use. And then I just extend into the actual thing. And I wasn't sure this would work. And it works great. It's amazing. You don't end up with bleeding. As long as you use the right specific Drupal cluster, it's not gonna bleed. Next question? Oh, five minutes. Five minutes, okay. Thank goodness I'm on slide 52 of 55. So automated style guides. This is a thing that pulls it all together. Okay. Because understanding the concepts of the CSS component design is great, but it's still, it's hard to do when you have Drupal as the thing that you're trying to compare it against. And I found that by automatically generating a style guide from the SAS files that I'm working on, it made it much easier to visualize. What do I mean by automating the style guide? So basically I've got a component library here, which means like I have a Drupal theme and inside the Drupal theme, I wrote all these different design components, individual design components. And CSS source that goes from the preprocessor or it's SAS source actually, goes through the preprocessor, it becomes CSS files. Sometimes you can also have HTML stuff if you're using what's the JavaScript preprocessor. Coffee scripts, yes, I don't use it, but yeah, coffee scripts. KSS, it stands for Nile Style Sheets. Some guy named KNYLE Nile. And he wrote this spec that describes automated, describes a comment syntax. Basically you write a comment in a very specific way and this script then can go through and read and parse all of your SAS files and then generate a set of HTML static files that become your style guide. And now we're gonna jump over to the demo part of the presentation, let me pull up. So this is a, whoops, I think I can fix this real fast. I need it, because this is local to my own machine. I'm working the other day, if I reload now. So this is a style guide that is automatically generated from the source and let me show you here, this is the spec that describes how you write these comments and this one's better. So this is a comment that you can put inside your SAS and it'll work with CSS as well. You can use the standard CSS comments, one at the top, one at the very bottom and none of the slashtuff of raw CSS. But the only thing that's required here inside this documentation for your component is the name of the component and then where in the style guide you want it to be. CSS requires you to define sort of the hierarchy of what you wanted to have for your style guide. And then you decide your own hierarchy and then you just have to tell CSS where each of your components in the hierarchy goes. So that and this are the only bits that are required. The second part there is a description about it. If you've got modifiers, you put them here. So we have an or states. So this is a hover state, disabled states. This is a primary and smaller modifier for it. This doesn't use the Drupal 8 standards as documentation here because it's not a Drupal thing. This is just a CSS thing. And if you run CSS node, it will go and generate a style guide from these documentation and you'll end up with something that looks like this. So here we have like all of our colors documented, base styling here, heading levels. We'll jump over the components here. And you can see, this is the style guide that I'm right now adding to Zen 7.x, 6.x. So out of the box here, as soon as I tag release here, it will have all of its CSS documented with KSS comments so that you get a style guide for everything. You know, auto complete styling, the highlight mark like new and updated comments, message styling, breadcrumb navigation, tabs. It's all gonna be in here. Responsive video, we should resize this. You can see it's shrinking and getting bigger. This is amazing when you're developing. You write something, you have like a gulp or a grunt task that's automatically watching out of your code. It generates the CSS, it generates the style guide. You go and look at it. It's wonderful. I set up a buff for the last slot of the day where we can actually go over and I can show you like how to get KSS node running and stuff. But this really, really ties everything together. It makes writing your components much easier because you can actually see it as you develop it. And it also helps tremendously with the agile process because you don't wanna do all the designs ahead of time. For every feature that you start at the beginning of a sprint, you have your designer and front-end developer work together to create a design. And as you write it, it goes in the style guide. The next feature that comes, you look at your style guide and go, hmm, is there an existing design I can reuse? And if not, then you create a new one. If you see one that's designed that's almost right, you can make a variation, a modifier of that. That's your process then. Each new feature, look at the style guide. Yes, no, something new. Those are your designs, it becomes really easy. I love this process. I know that everybody is gonna be doing agile development in 10 years, but we're just not there yet. This is gonna be the road ahead, I promise you. Thank you.