 Oh. Hello. Hello. Just seeing how close I need to stand to the microphone. So my name is, I guess I'll just get started. My name is Robert Caracus. I work in Australia at a web agency called Previous Next. And yeah, I'm here to talk about Drupal generated markup, not being your friend. How you should use a style guide. We've been using a style guide for the past, I don't know, two years now at Previous Next and it's been, you know, it's really up to my theming skills, I guess. I guess I would say it's just, it's been interesting using it. I want to talk a little bit. I heard Dries talk, my last session I did in Drupal Con, Austin I talked about Angular and all the stuff that Dries is talking about in his keynote about how you know, like how these front end frameworks are kind of happening and stuff. So I talked about creating a Drupal theme in Angular and I thought it was really cool. And I still think a lot of these client side frameworks are really cool, but Drupal 8's coming out and there's going to be some tools that, you know, we can use in Drupal 8 on the front end and I thought it would be good to put forward a presentation that talked, went into a little bit how we're doing theming now how, you know, what, how we've done theming in the past, how we're doing theming now and how in the future, you know, front end might change a little bit, especially relating to the release of Drupal 8. The last speakers slides were really nice. Mine are kind of figuring, me figuring out, reveal JS and some code examples and stuff. So I'm a front end developer, not a designer. But yeah. So let me get started. First, how many, I don't like putting ourselves into a box, but how many people here would call themselves like a front end developer, front end, so most people are front end. That's good. I don't have to explain things too much then. The last one, everybody was back end developer. So SAS, templating engines, may handle bars, things people are familiar with or semi familiar with. So that's good. I'm going to have some of that in my presentation. How many people here work in like an agency? Say an agency versus internal, a lot of people. So I'll have a lot in common with people. This is like a common design that you might get. I don't know if people are doing design in different ways. A lot of times we get a Photoshop file with something that looks like this. Really common, something common that you might put into Drupal. You know, you have an image, you have a title, might have a link. And a back end developer might think, okay, or anybody, if you're familiar with Drupal site building, you might think, this is a perfect case for something like views. A list of nodes that link off to a detail page, classic case for something like views as your site building choice. And the quickest way to style something from views, say a back end developer is in charge of configuring some advanced configuration for that view and hands it off to you, being the front end developer of the theme or maybe you have to do it yourself. And you look at the markup and the markup looks something like this. And I made it small because it really doesn't matter what is there, just you can't read it and it's kind of terrible. But somewhere in there, you're going to find these classes that you can grab on to and theme and make what is given to you kind of look pretty. Yeah, they're in there somewhere. I've kind of mocked it up a little bit using position absolute. This is the class you're going to find. And I just, I don't even know if that's the right one I looked at it. I think so. It doesn't really matter. But basically Drupal classes, they give you this prefix that you have to, that's usually the name of the particular site building module of choice and then followed by some sort of ID that you might identify by. And that would be the container, right? So views, view, home page grid, say that they wanted the view on the home page. And then you might have an item. These are the things that are important to you. You want the item because you're going to do some sort of grid setup and you want the container to do maybe a max width or something like that. So this might be the, if depending on the views plugin that's being used, depending on a couple of different things, this might be the class that you choose to attach your grid base styling to. Yeah. So this is, I guess, the code that you might use. I mean this is SAS, so it's kind of nested. Yeah. You might start off by just putting some code into styles.scss. You might just have one file for all of your different components around the site. So you have a max width and you have a width 33%. Kind of makes sense with what we've shown. Obviously there's going to be a whole other set of slew of properties, CSS properties that you're going to have to attach there. But yeah, I'm not going to put those in for example sake. This is just as an example. Yeah. So you're able to pretty quickly get that view up and theme the way that design looks just by attaching some styling to some Drupal classes spit out by views. But then say further down the line, you have to add other implementations of this grid in different sections of the site. You might have one on the home page that we discussed, but there also might be another instance on a landing page where you need to do some promotional items. And there might be some related content on the bottom of a node page like an article page that shows a list of articles in a very similar fashion, in a grid fashion as the design I showed before. And the site builders and product owner and client might have special requirements. So the views is fine for the home page, but there's going to be all sorts of other site build. I mean, on every Drupal site to me it seems like people are using a million different site building tools. We don't just settle on one based on what you need, based on the content editing experience. For instance, the promo might be done in paragraphs. That way you can give the client or the site builder a way to add images and things curate content on a per node basis. The related content might need to use entity reference because you might want to have database relationships between the articles and other articles and show them on the bottom of the page. And then the promo might need to be purple or something. Anyway, the specifics around this is not important. Just kind of say that we're using a lot of different site building and there might be different sections of the same design on other parts of the website. So using paragraphs just to go through it quickly, you might have a container, whatever paragraphs gives you, paragraphs container and a paragraph item. And you're going to do a very similar thing that you did in the view. You're going to style the view and the paragraphs in a very similar way to the view. Obviously there's a little bit of variation here. But the point here I'm trying to make is that even though these are using very simple properties and two different implementations of this grid using different site building tools. But this CSS, even though it's listed together on the same page here for demonstrations purpose, could quite probably be in very different parts of your style sheet. I'm not sure how you're structuring your partials or how you're structuring your CSS, your SAS or whatever preprocessor you're using. But oftentimes, you don't even know. You'll style these things again, depending maybe a project manager a week later says, style this bit. You'll go and style it all over, even though you've already done the styling, something very similar in the past. So, yeah, I mean this stuff might happen, might be in a lot of different places, let's see if I can zoom down here. And here's your entity reference. You might have another thing. And this happens, I've looked at some old projects and you've had this very same thing. This is what was happening two years ago, three years ago. And here's an example. Excuse, I'm not pointing out that he just made the last commit, but well, for will. This is just an example of a project. This is when we, but maybe two or three years ago when we were putting all the styles in the same style sheet, basically everything in styles.scss. Because that was the easiest way to kind of do it. With this sort of classes and this sort of markup, how are you going to organize it in any other way? How are you going to make partials? What are you going to make partials based on paragraphs or based on views? They really have nothing to do with what the actual design looks like and the different components that the design might look like. The different patterns that make up the design. This is hard to see, but it really doesn't matter. I just noticed this, but this is on another project a couple years later where we decided that we wanted, because the one style sheet's very hard to maintain, so we decided we wanted to break things up in a more organized way. But in my opinion, it kind of just made things harder. I can't really see this, but it says node article. This is the article featured and the classes inside of bottom lines, the classes inside of the particular partial have nothing to do with the actual name of the partial itself. So by looking at the partial tells you nothing about what's inside of it, which to me makes things hard to organize. So with these problems, and there's more problems to do with default triple markup, but I have to move through this. Industry as a whole, front end as a whole, I have come up with a kind of a better solution. And there's all solutions, but I think the settle on a solution in the last couple years has been what's called design components, where you use, and it's very similar to Drupal modules, if you think, where you come up with a name, any name for a component, and pretty great. It really doesn't matter. There are some rules that have to do with the naming, but in the end of the day, as long as it's a unique name that describes the pattern, it doesn't matter. You describe, it's kind of like a Drupal module, you know? You have a name space, and then you have subcomponents that go along things. You're grouping things together, like in a Drupal module, you might have the name of the module in the beginning, and then as a hook or something, and then you might have some sub, some functions or methods inside of there. So, and that's what, you can follow the same pattern in, when you create what industries call design components. It's important that the naming of these components don't relate to Drupal configuration. So you don't want anything, any naming in your, I mean, this is all opinion, by the way, so don't take anything the harder, you can come talk to me after, but this is how I kind of do things. The naming of your design components, or your name space, to kind of conflict with Drupal and confuse you. You also probably don't want it to have anything to do with the actual content, because you might have different content flowing in and out of these design components. For example, if you call this article grid and you wanted to have pages or some other content type flow through here, then that could totally cramp your style when it comes to, you know, styling it in the future. Yeah, and you know, sub, you can have the item, but you all, you can have some components, tiny sub components too, like maybe the title is slightly different than something else. So what does the CSS for this looks like? In my opinion, a lot cleaner. You have some namespace classes. I'm using the actual name of the component itself, pretty grid, just made it up, by the way. And you're actually putting it into a partial case, so you can see this partial is named the same as the class. So all of a sudden it becomes a lot easier when you're looking around your markup and you're looking around your website. If you see a component named pretty grid, then you know that you can go and find a pretty grid in a nice partial somewhere, and everything to do with pretty grid is inside of that partial. And you can see it, I'm using the name of the component as a container, but you can also just as easily say underscore, underscore container. And these underscores and dashes and stuff, this is using a methodology called BEM, and I'm not going to get into the rules. It's a little bit complex to understand. John Albin, my co-worker, has gone in through over the last couple of his sessions and gone into kind of the nitty gritty of BEM and talking about a lot of the syntax, but I wanted to bring this kind of methodology up again, because I think has to do with some more stuff I want to get into. Anyway, so here's pretty grid item. You have your width, your grid item widths, and you might add a larger font size for the title, just example. But with your CSS, you really, in my opinion, you really want to have example markup. First off, for two reasons. First off, prototyping. I mean, in Drupal, maybe five, six years ago, when I was seven, eight years ago, when I was first beginning, I didn't even know how to write markup. Drupal did everything for me. I made views and it sped up the markup. And I was theming. I was doing a lot of CSS and I was working for companies and stuff, but I didn't know how to create markup. I just knew that Drupal sped up divs. So when you're creating the CSS, you have to actually write the markup by hand, which is good because you have more control over it. So for prototyping, you need to write that markup. But also for documentations, I mean, this is a simple component right here. But imagine if it was more complex and you had grid systems in there and you had responsive media queries in there, it can start to get quite complex. So you need to understand the source order and actually what's going on inside of each component, especially in a responsive age, especially when you're dealing with accessibility attributes, ARIA attributes, all sorts of things that you need to be able to have a tab on. So documentation and for prototyping, you should have example markup. So basically in my opinion, the way that we do it anyway, every class that you write in Drupal, like when you're theming a site, every class should have markup documentation that shows what is happening with your CSS so people can understand coming in maintenance in the future. So Fuglies, this is a concept brought up by my co-worker John Albin, he's the author of the Zen theme Drupal's, you know, I guess largest or most used base theme and most downloaded. And yeah, this is how you might apply. So you apply these nice design component namespace classes to your Drupal selectors. This is his solution for that. And what you do basically, I mean Fugly can kind of a funny story is that I was working with him on a project and he named these things Fugly selectors, we all know what that means I guess. But he's I guess for a kind of more high profile client so he's changed the name to just Drupal selectors. I like the politically incorrect name. But anyway, yeah, so what you do here is you have your pretty grid, your nice namespace component base classes and then you come in and you extend these classes onto Drupal selectors or your Fugly selectors. And this lets you manage your different instances around the site in a good way. And what it also does is it allows you to cut these out. If you ever want to use your design components or if you ever want to use your design which is now translated into HTML and CSS you might want to use it in a non-Drupal setting you might want to use it for some splash page or some promo for another brochure site or something you want to use some of those components. You can just cut out these Fugly selectors and then you can go and use that. And one use case you might want to do is going from Drupal 7 to Drupal 8. I remember going from Drupal 6 to Drupal 7 a lot of times what we would have to do a full rebrand because our design was so embedded into whatever site building opinions we had which were the actual Fugly selectors, whatever the site building tools we were using at the time, those were embedded into our design because we were attaching our styles directly to Drupal selectors. So this is in my opinion a must have for, you know, be able to maintain your site and be able to re-theme your site or transport your site in the future or moving to Drupal 8. Anyway, I thought I'd put an example. I've talked about some of the different parts but I want to talk a little bit about a full example of what a complete component might look like, one of these partials. And this is not just something we're using at previous Next. I've had a look at some other frameworks and Ubuntu's vanilla framework has a very similar example to this particular example where you actually put the markup inside of your SCSS file as documentation, as some sort of to show people, okay, well this is what the CSS is actually doing. So you can click there and see their example there. Basically you go through and you might have some styling of your pretty grid and you might have some Fugly selectors. And you can see that these Fugly selectors start to get a little bit intense. You have to start mapping them. But they're mapped in a pattern. Oh, I didn't escape. Those are supposed to be underscore underscore. They're mapped in a pattern that is consistent. And it's abstracted. Your design is now abstracted from Drupal, which is really important moving into the future. So here's just another example of a little component. So in my opinion, no matter how small your CSS, no matter what the little tweak is, it should always live in a component. It's confusing at first when you first start getting into this kind of idea, but it ends up making a lot more sense as you work with them. So even something as small as like a read more link or something, obviously you would probably have more properties than that, just for example's purpose. Yeah, so that is another example of a component. And it has a little bit of markup. So extending design patterns. So when you start building your designs like this or building your themes like this or whatever you're doing, you can start amassing these components pretty quickly. You start having quite a few of them. And some of them might be, I don't know if anyone's heard of like pattern lab or atomic design. You might have smaller components that fit into larger components. And for example here, the way you kind of do that from the CSS perspective is, you know, you can, well, before I say that these components do something really important as well, the namespacing of them. They basically break CSS. They take the C out of CSS. They take the cascade out of CSS to where whatever happens inside of one of these components shouldn't affect what happens within the other components. Now you can write things and be totally sure that because they're namespaced and we do that all, you know, in computer programming, whatever, all over the place. But yeah, that's an important thing. So the cascade is basically broken. We don't care about it anymore. Unless you kind of do care about it though if you are wanting to use CSS from one component and a smaller component in a larger component. And here's a perfect example. In our pretty grid, title, remember the title with, let me just go back real quick. Here it is I guess with the title with a little arrow. You might want to extend. That arrow could be a complex. You might have an SVG. You might need to position the SVG over to the right. You might need some padding. You might need some CSS3 properties. You might need auto prefix or stuff. You might need some responsive things that happen. So you might have quite a few properties there. I mean, you might not want to write that over and over and over again. So you might, in the title you might want to say, well, this is pretty similar to Read More, but actually the font size is a little bit bigger and then maybe you have to move the arrow around or maybe the font, there's a different font family or something like that. So this is a way by importing, this is a kind of a SAS thing, but other preprocessors have a similar sort of setup, by importing the subcomponent in the head or not in the head, in the top of the page, you can ensure that that CSS based on, I mean, using Compass in this particular instance, you can ensure that the CSS will actually come, the Read More CSS will come before the pretty grid title CSS, which actually becomes important. In that case, the cascade is important. And by using dependencies, by listing out a hierarchy, you can start doing some pretty cool stuff and reuse code where you might not have been able to reuse it. And when you start doing this, you start seeing a lot more patterns in your design when you actually have the tools to do something like this. So this is just something we've been doing recently and it's, so I showed you an example of having the HTML documentation inside of the actual component itself. And putting all the different languages in the component is, I guess, if the component is complex, it might make the partial pretty big. I guess they do that in React components and some other components, they put everything into one file. But I like the idea of kind of splitting out your different language dependencies into different files. So pretty grid might have some CSS that it requires. It might have some HTML. It also might have some JavaScript that does something fancy, maybe equal height grids or some fallback or something that you need, particularly for that component. I'm not going to get into JavaScript dependencies and stuff. I think there's some other sessions that talk a little bit about that. But yeah, I like putting HTML long story short in a separate file because then with your IDE and if you ever want to do anything like linting, you can use your IDE won't bug out, freak out. That's the main reason for me. Yeah, and they do this. This is not just something I made up. They do this in Google Material Design Light, which is a really cool framework by Google. Google came out with their Material Design spec a year ago or something. They're hoping to implement it with web components, but I guess they're a little bit too complicated or not ready yet with Polymer and the like. So they've come out with well, Material Design Light is just a vanilla HTML, CSS, JavaScript implementation of all of their Material Paper Design components. Anyway, so yeah, like I said, you might have a lot of these components and you have a lot of this example to mark up and you have no word of prototype and you're creating static sites and boilerplate HTML files just to see your components because you want to create components in this way. Really, you need some tooling that's going to allow you to take this HTML and actually visualize it because just looking at the HTML at the top of a file, I mean it will give you some hint of how it's supposed to be used if you're familiar with HTML, but you really need to see it with the CSS actually applied to it in a setting that is referenceable in like a catalog sort of setting. And that is where a style guide might come in. So a style guide, when I first heard about style guides, I think all I thought immediately of the AP style guide, like of writing content and how to structure content, because I've done it in college, but MailChimp does something similar to where they talk about the voice and the tone that they might use. If you ever use MailChimp, they have the funny little jokes all around when you're trying to create email campaigns. Yeah, so this is a style guide for content, but this is not really what I'm getting at when I talk about like a tool that can help with our markup. What a lot of designers think when you tell them, you know, we need a style guide, we need a component-based design, they think, oh, like element collages or style tiles where you have some colors, they give you like a photo shot file with a couple of colors in it and some typography and it's like, here's your style guide. Well, it's a little bit more than that as well. And going back to material design light, they actually have a good component library, and I think that's more the word we're looking for. A component library, and I guess I call this a static component library because all the components are just HTML, CSS, and JavaScript. And this is really cool. You can actually click on, you know, these, you can't do it in here obviously, but you can click and do Chrome Inspector and actually see how these things are made and you can actually open them up in CodePen. I like this style guide a lot. Yeah, and you can see the markup here as well, which is really important and has a catalog of all the different components. So, the tool that I'm talking about is more of a style guide generator, and that's what we use. We use what's called a style guide generator, and we use a project called a KSS node. Now KSS stands for Nile Style Sheet, just something that some guy made probably a couple of years ago, and he made it in Ruby, and GitHub uses Nile Style Sheets, the Ruby version for their style guide, component library. Yeah, so why do we use KSS node instead of KSS Ruby? Well, front-end developers tend to know more JavaScript than they know Ruby. And so it's easy. If something goes wrong in the style guide, you can make a commit. The other reason, I guess we use KSS node at previous Next, is because John Albin, who's my co-worker, he's the maintainer. He's not only the maintainer of Zen, he's a maintainer of KSS node. Another reason that people in Drupal might want to consider KSS node is that now in the latest alpha version of Zen, a KSS node is included by default, and all of the components, CSS components inside of Zen's starter kit is basically built around the KSS node style guide, because John's the maintainer of Zen and of KSS node. Now just to note with KSS node, and this is a pretty big when people are coming and learning it, KSS node does not care about CSS or JavaScript. It only cares about markup. So it parses your CSS files and looks for markup basically, and a feature of KSS node that you can specify that we've added recently, what I mentioned in the past, and before in the previous slide is that you can add a separate markup file, and KSS node will know about it. KSS node is just an NPM package. You download it, and you can use it in the command line and feed it a few arguments. Yeah, so we need a way to get all of the CSS, all of the HTML out of all of our components and all of the CSS out of our components, all the JavaScript out of our components and get it into our style guide, or KSS node style guide and our Drupal site. And the way we do that is with some tooling. So we use Gulp to basically to watch our saves basically, and KSS node will parse out the HTML from each one of our components, and it allows us to follow this component-based workflow and parse it into these performant one HTTP request, CSS file, JavaScript file and HTML file. Now KSS node is just a blue. It just cares about HTML. We have other sessions that might talk about the CSS. I guess I talked a little bit with the imports and stuff, but then JavaScript is something else altogether. This component-based methodologies is going to be pretty prevalent when web components come out, or when they're supported in most browsers. And yeah, it's important that we start looking at building front end in this way. So this is what it looks like after your HTML and your CSS has been parsed. Your CSS has been parsed of all the markup documentation. KSS node will give you a catalog for you, your particular component. And look, it's just a very small component here. It's nothing big and it's not very pretty. It doesn't look like the Material Design Light Style Guide. But it serves an important purpose because now we can take a URL, a reference to this particular component, and we can send it around the company, send it around our client or our development team, and we can iterate on this particular component and talk about it and reuse it, and maybe even do testing on it. Maybe we can do some sort of screenshot rate testing or something. I mean, that's a little bit too much for this presentation. But having a URL for something is really important. And your markup's there as well. You can actually see the markup that's used. Obviously you can look at it in Chrome Inspector, but it's nice being able to look at it right next to the actual component. And you can find all of your components pretty easily. And this is a huge benefit when you're developing. It's a really important, in my opinion, for larger sites that have workflow, whether you're using KSS Node, there's all sorts of other style guides out there now. So a little bit more about a design component, but then KSS Node has some interesting things in it as well. First off it's, I mean, we have a CSS file in our normal static HTML, CSS, JavaScript components, but KSS Node doesn't necessarily need to use HTML. It can use HTML, but it can also use the templating language of your choice, like a template file. And using a template file means that you can have variables, just like, you know, think of any of our Drupal templates, or if anyone's played, everyone said their friend developer's played with, you know, templating engines or anything. You can actually, in our components, we can have data that moves in and out of our components, so it's really important if you want to start using your components in different places. You need the titles to say different things. You need to have different context. You might need it to be different colors. You might need to feed it different classes. You need to have variation in the heap of mark, you know, in the component that you're trying to edit. And it also lets you, so KSS also lets you specify a JSON file which has some default data, basically placeholder data for that component, because obviously in the style guide, it's not something that's dynamic. You just want to have something there that you can, you know, just see when it gets generated. So I'll show you an example. Some of this might have been confusing waiting for the video. I have a little video which I made on the plane. Let's see if this works. One second here. Can I do this? Ooh, okay. Huh. Okay, I have to do it over here, one second. So this is just an example just so you can get an idea of how this might work. You know, you have your component, maybe your read more component. That's what this one is. And it has, you know, little specs of data in it. And in a JSON file in the same component, you're going to have, you know, you're just going to specify in JSON the URL and the title. And then you can do gulp watch it will compile the style guide. You can start to see how the tooling comes into effect here. And if anyone has any questions about the logistics of that, I can walk you through how that works. And then obviously you can come down and you can see your component in the style guide. Here it is. And then you can see where the data, the placeholder data has been shown in the style guide. And this becomes really useful. It might look, you know, a little bit hodgepodge here, but it's very useful to be able to do this. I'll show you why, because like the CSS being able to reuse components from one CSS file, one partial, and reuse it into another and be able to import a whole list of properties into maybe a sub part of your component, you can also, with CSS, you can also do something like that with markup. And that's what these template engines are all about. It's taking pieces of markup and being able to mix and match and reuse them and place them within other pieces of markup. And with that you can start to build bigger and bigger components. And this is pattern lab. This is their idea of a page. You know, where you see you have all these components that are compiled together, not compiled but included. They're just including a bunch of different components on the page and those components have micro components, I guess they call them molecules and atoms, etc. And you can do a similar sort of thing with KSS node or whatever template language you're using. Now a question is like, how do you get some of this markup that and these classes into Drupal? So we've created these nice CSS component-based selectors and we have markup too that goes along with that. And we need to either get the classes in the Drupal or you need to get the markup into Drupal. Let's talk a little bit about these fugly selectors. So I have a little fragmented slide thing that I made here. On the left, on the left you have the pretty great cart partial that we talked about before and inside of it you have some extended fuglies. On the right you have your views view grid or whatever your views template file is or your view implementation that has Drupal markup in it. Now the problem with fugly selectors is that if you get rid of that Drupal implementation, you then need to go into your partial and you need to fish out all of your fugly selectors if you want to maintain your code. You could just leave it there. Nobody would know the wiser probably. I don't know. But you have to go and fish through your components and pull out the fugly selectors. If you actually use the markup though in your template file, you don't have that problem because you're able to get rid of your template file which has the nice markup in it and you don't need to worry about maintaining the component because the component doesn't have, the design component doesn't have any Drupalisms in it. It's just fresh and it's by itself and it's abstracted. So in my opinion using classes is a preferable solution. But we all know Drupal. Getting classes in Drupal is not easy. You have these theming functions which go on forever. Luckily they're gone in Drupal 8. If you have to use one of these, just use a fugly because you don't want to have to maintain all that PHP code, forked PHP code. Then you have markup UI. I can go on a long time about using panels. I know Drees said we need to make it easier for people to point and click. But maybe five years ago when you can add a few bootstrap classes and you can kind of make a desktop style site with a few classes. But in my opinion having to when you have more complex components that have responsive properties, you have to deal with performance, you have to test them, you have to do a lot of things. Getting all of those classes and all of that markup into Drupal using display suite extra or using panels classes is quite difficult. Now I worked on a development team where it was great. Because we had the style guide, we had all the classes listed, the devs were able to go into the style guide, rip all the classes out and get them into Drupal which is great. It really sped up development. But the problem is maintenance because on that site currently if somebody needs to go in and change anything, they do a command F for that particular class because you have the panels are all full of markup and you find C tools configuration because that's where all the classes are stored and C tools exports. So it's a little bit difficult and it's just very verbose filling these things out over and over again. I don't have a solution for that. I'm just complaining a little bit. Layout UI is a similar sort of thing. It seems to me whenever you drag a pane into the panel, you know, you have to re-style it again. It doesn't, just adding a class or something, it's not themed. You still need to get the theme or to iterate over it again. And maybe if you create it in a really good, in a perfect way, it works. I'm running out of time here, but yeah, so the, actually I think I'm doing all right. So benefits of Drupal templates. Let's just rehash some of this again. Preserve the components. Preserve the component source orders. If you're actually using Drupal templates versus, you know, fuglies or just attaching your classes directly, your styles directly to Drupal classes, you're able to see the markup and, you know, preserve that component source, sorry, markup source order, not component source, markup source order. That's so important. There's no configuration management. So you're not having to, if you're using template files, you're not having to actually go to features and refresh that configuration because it's just stored and get the configuration or the HTML is stored in version control. And then yeah, you can search in the ID. I find it a lot easier to search things in the ID. So disadvantage, managing template files in Drupal is hard. Like the naming convention, the naming conventions around Drupal templates like node, dash, dash, article, dash, dash, my special suggestion in template.php is not easy to deal with. And people come up with all sorts of nifty ideas on how to manage that. It can be difficult sometimes. So I'm not denying that. Duplicate templates. So I want to talk a little bit about this. This is a problem that bugs me in particular. It's probably more of a pet hate than a worldwide Drupal problem. But duplicate templates. So because we have the standard like previous, next, that whenever you write CSS, rather you write a component, you have to have example markup inside of that. You have to evidence your CSS with a working example, HTML example. We're writing markup no matter what. We have to write markup because it's part of the development process. Because we're writing markup, we're also writing markup twice. Or we're copy pasting markup. So what we end up doing, because KSS node is written in handlebars and Drupal is written in PHP, the only thing that's different here is the variables. So one's PHP template and one's like little brackets. We should be able to somehow reuse and duplicate, especially when you have a more complex component that has a lot more HTML inside of it. This is just a simple example. But remember we had views. We had paragraphs and we had entity reference. Imagine taking that example on the right and having a copy pasted in each one of those template files. You start to find yourself duplicating templates a fair bit there. So what if Drupal could actually use style guide templates? So what if the templates in Drupal could actually leverage what we have in the style guide? Because the style guide becomes such an important part of our development process. Drupal would have to be able to use handlebars. That's not happening. It's Drupal 7. That's not going to happen. I'm not dealing with that. KSS node could use PHP template but then you'd need a JavaScript implementation of PHP template. That's not going to work. Luckily the Drupal 8 got twig and that's where things start to get interesting. Because twig is written in PHP so Drupal could potentially use it. But it has a syntax that's more similar to handlebars. It uses the same brackets. But that's not really going to help us. Drupal 8 and twig is awesome for other reasons like it's more secure. We're not writing SQL queries in our template files but just because it's similar does not mean it's handlebars. And that's where it gets interesting again because there's something called twig.js. Twig.js is a JavaScript implementation of twig which means that node or KSS node which is written node, node is a service side implementation of JavaScript can leverage twig.js and use it in its templates. So instead of using handlebars KSS is currently written as a generator that uses handlebars it could potentially use twig. And Drupal is already using twig. Drupal 8 is already using twig. Yeah. So I wrote a pull request to John Alban's KSS node and it's passing now. It's like it wasn't passing then. But yeah. I basically wrote a generator that lets us use twig inside of KSS node which is interesting because now you're using the same templates as Drupal might use which gets you closer to making your style guide look like what is going to be in Drupal 8 and core. Now I have to write some tests and stuff. That's always the hard part when you have to learn JavaScript a lot better than I already know it. But yeah. I'm trying to get that in and I'm sure when Drupal 8 is released there's going to be a lot more momentum around getting something like that released. So let's talk a little bit about twig. Some of the syntax for twig when I'm particularly interested in it are the includes and in handlebars the includes I showed an example before the includes looks something like this where you have this little arrow and it just kind of includes things for you. And twig I've spaced it out weird but just so it can be used in the example. Yeah. You can just include in a very similar fashion and then you can start includes the first step into building these larger components. And we can do this in Drupal 8 core. This is not necessarily a style guide thing. So we can start mixing and matching our components hopefully whether you're using a style guide driven development or not. Extending is another interesting concept to where you can have this markup and this is actually extending is used in core as well I think in the classy theme or somebody will tell me after the after the session but it basically allows you to add markup to particular templates and yeah so you can have you know here's block.html.twig which is in Drupal core and this potential child template is extending it and then just adding a little bit of extra markup around the content to make it you know maybe make it match our design or what we need to do to have it better. So we're using KSS node Drupal template so you might want what you could potentially do and I've had a play with this and it's looking pretty good but it's not 100% is you might want to take something that is inside of your Drupal template and inside of your style guide sorry that's written in twig and extend it inside of a Drupal template and this would let you avoid having to have having to write you know having that duplicate markup and all these different template files you can just extend what's already in your style guide and then potentially if you change something in your style guide it's also going to be changed all throughout your Drupal site which some people might see as scary because who knows what's changing but we shouldn't as developers we shouldn't think that that's scary if you're you know you should have to be able to test for things like that and hopefully you know that sort of stuff evolves. These are just some ideas at the end of the presentation that I'm throwing out there. I just want to show you one quick thing that you know you might want to do here just one more video about reusing templates. So this is an example I put together you know I played with this is always the fun part of these presentations and this is the KSS style guide and this is a title of the grid item that we had seen before and this is a Drupal site so this is Drupal 8 site that I spun up and it's using that same template so I got them using the same template I was able to extend the template in here into the Drupal 8 site so it is using the same template here to do that now to kind of prove that I guess I'm going to put a inline SVG into my template which is being used by both the style guide and Drupal 8 and I'm going to compile my template or I guess generate that static HTML style guide and now you can see that obviously that inline SVG is there but because Drupal is also using that template and I have twig debug mode turned on obviously so it's not caching the twig file so any changes that I make it will automatically be seen and I go to my Drupal site and I refresh then obviously the inline SVG is there so there's an example of you can imagine having the views, home page, the promo landing page and then the entity reference and having all those template files just being automatically updated and there's no mistakes there, everything got made if it's using that component and extending it it got made but one interesting thing that can also happen and this is our style guide by the way is because we're using twig.js templates can not only be leverage like twig works in KSS node on the server side because it's in node but obviously javascript works in the browser as well so there's no reason why front end like the browser can't leverage these templates as well so what you can do is write a little bit of javascript that maybe lives in its namespace nice with your component lives with your component and without even having to do anything and Drupal or anything just write some javascript that includes twig.js in your browser and then you're just able to kind of pull in, leverage a template, feed data through it maybe using that graphql that Dries is talking about and leverage the same templates on your style guide and on your Drupal in the browser and yeah this is I'm not going to get into the javascript it's relatively simple and yeah and then your Drupal site remember we just did that in our HTML in our style guide but it should theoretically the same just work in your Drupal site as well no need for Ajax, views, plugins or anything like that and just yeah so just knowing that oops yeah so just knowing that that stuff exists that stuff's out there that using twig is going to be huge having a template engine in core is going to be a big tool for us as front end developers we're going to be able to mix and match and do a lot of things with HTML and with client-side development and you know we're going to be able to do a lot of stuff so just knowing that those tools exist understanding that with the benefits of a style guide being able to catalog all of your components being able to iterate on a development team being able to show the client and show the designers things so we're not rehashing all this work over and over again and writing all this stuff time in and time again time in and time out it's going to be really advantageous to us moving forward going in to Drupal 8 so I guess that's it from me you can find me on Twitter that's my name and yep thank you very much appreciate it does anybody have any questions yes ma'am yeah I use KSS for prototyping so whenever I get a new design in I go into the style guide and I make it all in the style guide first so I don't make a whole site in the style guide I would never do that because you know you don't want to waste time the client's time and stuff you want to do in like an agile sort of fashion so when the story comes in you just make the HTML and CSS that has to do with that particular component you build that component and and then you prototype it and then you worry I'd estimate them separately so I'll estimate the HTML and the CSS and then separate is the Drupal integration and then everybody can see the cost of Drupal what is Drupal cost what is the integration actually costing us because you shouldn't have to worry about Drupal when you're actually doing all the responsive stuff and performance and trying to figure out how the component should work and the browser is the best pattern labs written in PHP but I think yeah I'm sure I haven't used pattern labs so the question is whether KSS nodes similar to pattern lab I'm sure they have a lot of similarities and yeah I haven't used pattern lab extensively not yet but I don't see why not like once it's all set up it's really easy if you know just HTML and CSS you should be able to iterate on those doing presentation this presentation is as much for people in my company as it is for the outside world because I like people to understand that the style guide is not just some you know some things some like colors and stuff on a page it's actually a really important development tool that can allow other employees maybe people who don't have experience with Drupal to do half the work on the project yeah interesting yeah yes sir good question I would put the image if oh I'm sorry my bad so the question is whether or not I put the images that have to do with the component in the component folder and if it's like a background image that has something specifically to do with that component then I would do that or if it's a placeholder image that has to do with the demonstration and the testing and the documentation of that component I would put the images in the folder but then you're gonna have to reconcile that you're gonna have to reconcile the paths you're gonna have to deal with the tooling and how it's pulling the image out and whether the path is absolute or relative and there's still problems moving forward but hopefully the tooling will get better and standards will get better around things like this anyone else alright thank you very much appreciate it yeah sure where you have some plugins like right now you put the right abuse plugin and put your grid or something or a great HTML into the abuse plugin but it's still a bit annoying to write abuse plugin and then you cannot use it if you have for instance field items and just want to have field format with field items and you cannot use the same grid or whatever you have and so what I'm doing is writing a bunch of different plugin types even if my own plugin is the product but right now on this demo site you just have this list format and there's another one entity display plugin and for instance this is my article view and now I'm integrating this in just a list format and right now you just have this too and each one of these have different options but in the client side what I work on