 Let's see here. Sorry, it took me a couple minutes. My computer was freaking me out right before this session. It was telling me that it couldn't save my keynote presentation every time I tried to set save. Restarted, we connected up here, and it was being very, very, very slow. But now we have it just perfect so that it will go on to the next slide when I press the Next button. I think we're good. Sorry about the delay. I'm going to talk first about the sprints. Get the side of the way. How many people have not seen this slide yet in any presentation? Joseph, jeez. OK, they're awesome, really do come, they're fun, that's enough. My name is John Albin Wilkins. Most people don't know my last name is Wilkins. They just call me John Albin, which is totally fine. It's like Beyonce or Oprah. Anybody who just calls me John Albin, thanks to my ego wonders. On Twitter and theDruble.org, I am also John Albin, and I work for AMAZY Labs out of the Zurich office. I've worked there for about a year, and it's been a lot of fun. And in fact, we're hiring. So you can go to that URL, or even better yet, there's an AMAZY Labs lounge right next to the AMAZY IO booth. You'll see a lounge with lockers and stuff, and you can come talk to somebody there. I got to start this session with a couple of disclaimers, right? So the first is that there are lots of JavaScript examples, but don't panic. I'm not going to be teaching you JavaScript. You don't have to understand all the syntax. We're just concerned about the concepts behind the JavaScript, right? And the second disclaimer is, and I can see there's lots of people who are here, this is a beginner session. I've seen a lot of you at a lot of Dribble Cons. Really, this is intro to theming, but with a CSS and JS twist to it. And lastly, if you really are a beginner, I'm going to be going fast, but there's going to be lots of URL. Typically, when you come to a Dribble Con, you just get hit with this wave of information. There will be lots of URLs. You can come back, look at the slides, and go, oh, okay, and then find the documentation for the stuff that we talked about today. And unfortunately, there are no funny Morton slides, so if you're here for that, not today. So this session is essentially building components in Dribble. I've given this session a few times before, but I decided to do it from a different angle. Usually, I talk about the problem, so we encounter us doing Dribble Themes, and that necessitates that we're sort of talking about an intermediate level, right? Because you have to have done a lot of Dribble Theming before you understand the pains of Dribble Theming. So today, I'm going to be talking about the CSS in JS world that the JavaScript community is using a lot. And that will be our sort of touch point for problems doing any sort of front-end development. And then we'll be talking about those concepts inside Dribble, and then how to do them in a better, more official way inside Dribble 8. So CSS in JS, this is a sort of unique term. You might ask why CSS inside the JavaScript? It turns out that this was a concept that they came up with because they were already doing HTML inside JavaScript, react, popularize this thing called JSX, which is sort of pseudo HTML, which they stick directly inside their JS files. And it was so very natural for them to basically do CSS and HTML inside JavaScript. So the very simple basic way that you could extend this idea into Drupal is CSS and HTML and JavaScript in PHP. We're not going to be doing that. This is a really bad idea. But if you feel like trolling anyone on Twitter, especially front-end developers, use the CSS, HTML, JS and PHP hashtag, now, since I'm going to be talking about JavaScript and a lot of us are CSS developers, I wanted to get sort of a persona for the typical JavaScript developer and the typical CSS developer so you sort of understand their mindset. So here's the typical JavaScript developer, evenly planning to get rid of all of your CSS and put it inside his JavaScript. And then the typical CSS developer. Yeah, anyway, I've tweeted a couple of these before. But first generation of CSS and JS. So the very first generation of CSS and JS that I saw was definitely one of these sort of things that developed by a very evil JS person and in my opinion, they did this. So this is some JavaScript syntax here that basically creates a JavaScript object. And instead of using regular CSS keywords, they have to create these camel case keywords because when you're creating a JavaScript object, you can't use background dash color. So now it's camel case and all the values have to be inside strings so they're quoted. And then you take that JavaScript object and you stuff it into this HTML which is also inside the same JS file. And this is JSX. This is a very big part of JSX here, the return statement. You have an HTML tag, any sort of attributes that you have. You can add different JavaScript values inside these curly brackets and then your contents are very tag. That's what's called JSX and that's the HTML-ish stuff that's inside React components. And when I first saw this, I had a lot of questions and they were all, why? Why, why, why, why, why, why would you do this? This generates inline CSS as a styles attribute and it's just a really bad idea. I would talk to JavaScript developers and be like, you can't do media queries, right? And they were like, oh, well, it's just JavaScript, we'll just check the window width inside JavaScript and then change the CSS, no problem. You can't use before and after attributes and then we'll just add real DOM elements inside our components. And yet, despite how crazy this seems to be, we can actually learn something. So, first lesson learned. Let's look at separations of concerns. This is a concept in computer science and one that we've been implying to the web for probably like 20 years almost. And the idea here traditionally is that you keep, you separate the concerns in order to make sure that these things are independent and are easier to maintain and to build. And we've traditionally thought of it as having our behavior inside JavaScript files, our design inside CSS files and our content structure inside HTML. But this separation is quite flimsy because the HTML has classes in it, right, for the CSS. So, if you ever want to change the design, you have to change the classes, which means you need to change the HTML. And same with the JavaScript. There's IDs and data attributes and those things also need to be changed in the HTML whenever you need to change how the JavaScript works, right? So, back when we were first sort of considering these in 2003, a very famous website was created called the CSS Zen Garden. And it tried to solve this separation of concerns idea by using what I call content semantics for the CSS class names. And what do I mean by that? Class name semantics. So, semantics just means some sort of meaning, right? And if we compare a content semantics versus a design semantics, what I really mean is that I'm creating a class name that is article-link for content semantics and a green button for design semantics and that is literally describing what it is versus what it looks like, right? So, you can create any class name that you want. I mean, semantics just means some sort of meaning and the CSS Zen Garden decided that it was going to use content semantics and describe what each chunk of HTML was. And that would allow you to change the design without having to change any of the class names because the class names were tied to what kind of HTML it was, essentially, what kind of content was inside that HTML. So, you would look at a typical CSS... Sorry. The CSS Zen Garden site had one set of HTML and then it had, like, 218 variations, different CSS files that you could apply to this one set of HTML. And it was very influential because it got people to actually start using CSS and thinking about it in a new way compared to the super old table-based background colors in line way that we used to build websites. And you see all these classes are using... The class names describe the content, the structure of the HTML, and not the design, which meant that you could change the design from this to this to this just by changing the CSS file that was actually attached to it. And it was highly influential. And the reason why I'm talking about it, of course, is that the Drupal code base was sort of based off this idea and the Zen theme was actually named in honor of the CSS Zen Garden. I'm going to grab some water because... Whoo! So, understanding what problems the CSS garden fixed and what problems it created is important for understanding Drupal 8 today. So, the CSS garden, just like the code base of Drupal, has its CSS separate from the HTML. But our JavaScript is not really fixed at all, and we've created some new problems. So, let's look at Drupal's content semantics problem. We have some classes like title, which you can style and add any CSS you want to. But if you want to have slightly different styling for a title, if it's a block title, that means that you have to add context or add additional selectors to your rule set in order to do new CSS. A lot of times you're turning off CSS properties in this new rule set, and then because title is used in a lot of different places, you may end up adding more rules, and so this would be styling the node titles. And if you wanted to have one change on one particular page, that means you had to add more and more CSS selectors to your rule sets. And there's a very specific term for this in the front-end developer community, and it is called CSS specificity wars, where you have to continually add more and more or higher and higher specificity to your rule sets in order to make CSS changes. And this leads to just longer and longer rule sets and more brittle style sheets, and it becomes really hard to maintain. So, let's jump back to this first lesson learned. By the way, I've stole the content of this slide from Cristiano Rostelli, who came up with this original content. It's fantastic. That's the URL for his slide presentation. So, compared to the traditional way of thinking about separation concerns, what are the CSS and JavaScript, like even that inline CSS, what is it trying to accomplish? It's still trying to think about separation concerns, but it's thinking about it in a completely different way. Now, we have a component, a button. The concern is I want to style this button. I want it to have a certain interaction. I want it to do something. I want it to have this content. This is a button. That is my concern. And it can have HTML and CSS and JavaScript in it. It doesn't matter that there are separate technologies. The concern isn't the technologies. The concern is the thing you're trying to accomplish. And for a component like button, it's like I want to press a button. Same thing with modals, medias, putting an image with a caption on it. This is how that very first CSS and JavaScript project was trying to solve the separations of concerns. And this was very influential, even though most people, most CSS developers who looked at that original CSS and JS, hated it. They couldn't figure this out. I didn't either. But this was the idea behind what they were doing. So those are a few who are new to component-based design. Let's go through a couple concrete examples of what I mean by components. So on this website, we can draw a box around like this and say, this is a component. This is my header. It has some navigation in there. I'm only concerned about styling the header. I'm concerned about styling the links. Maybe doing JavaScript reactions for the menu that pops out. That is a single component. This also can be a component. It's the main article. It has image. It has some taxonomy terms here. A little teaser text. We create a chunk of design that includes some HTML and any JavaScript that's needed. Here's some more components. This component is actually used twice on the page. You can see here just to the right of it. So the component can be reused. It can also be nested. You can see here that we've used this little red circle inside two different components. And so we can nest different components and they work just fine. And then the last one here is this is actually just, its concern is layout. It's doing the layout for three columns and it doesn't actually care what's inside each of these columns. These two columns have some nested component and this first column has a completely different nested component. The layout component does not care what its children are. It's just concerned about three columns. Done. Let's go over that again. What is a component? A single component is a chunk of HTML, CSS, JavaScript and maybe some images as well. Basically any assets that you can add to web page that can be encapsulated inside a component. It has a unique and separate responsibility. It's repeatable. It's nestable. And lastly, it can have design variations. So for example, if you had a red button and then you also wanted a gray button, you wouldn't put those in separate components. It would be one component and you would have a way to tell the component, please, you know, show me the design for the primary button, red, or like show me the design for the secondary component, which is like gray. So each component can have some different variations but they have very specific purposes, right? So let's go on to the second generation of CSS and JavaScript. They created a CSS file. This made a lot of CSS developers go, hey, this is a very normal CSS file. Button class, normal properties, great. Then they had a button.js file. And they would import from the button.css file into this variable named styles right here. And there are some really interesting technologies, Webpack, and a lot of other stuff that does some magic. Basically what it does is it takes this style sheet and creates a JavaScript object with like a list of all of the class names that are defined inside that CSS file. And so here, we're again returning JSX. JavaScript can't have a keyword that's called class because that's a reserved word in JavaScript. So they have to say class name when React actually prints this out. It converts the class name back to class when it actually exports the HTML. But class name equals styles.button. So we're referencing a particular rule set inside our CSS file and using that class name inside this HTML chunk. And this brings us to our second lesson that we've learned from CSS in JavaScript, which is that you can organize your theme by components. So the old way of organizing our theme was very much in line with that old way of thinking about separation of concerns. We would have a CSS directory, maybe just like one CSS file, a whole bunch of images inside an images folder, a whole bunch of JavaScript, or maybe just one JavaScript file with like Drupal behaviors if you're familiar with that, all in one file. And then our HTML in a completely different folder, the templates folder. But there's no reason we have to do this. We can actually reorganize it so that we have a components folder. And inside our components folder, each component gets its own directory with which holds all of the stuff that it needs, like the HTML, in this case with twig file, the CSS, the JavaScript, any images that it needs, it's all together in one place. This makes it very easy to maintain the website because if you know what design you're looking at, you can find all of the stuff that's about that component right in one folder. We will get into exactly how this works if you're a new person to Drupal, to Drupal theming in later slides, but just recognize that we've consolidated everything about a chunk of HTML, a chunk of a component into one folder. Third generation of CSS and JavaScript. This is the latest one. This one's going to be a lot harder to describe. Okay. So this is called styled components. And you can see that it still has regular CSS properties here, but then there's these weird back ticks around it. And in JavaScript, that basically means it's a string. So we've got a string that has the CSS properties, no class name at all. And then we have this thing that says styled.a and down here we have the styled.img. So what this is actually doing is it's creating a JavaScript object that knows when it is used on the page, it's going to be an IMG tag. It knows it's going to be an ATAC. That's what that syntax means. So we're creating two different elements here. One's a link and one is an image. And then we're going to use it. Remember, we're going to return JSX. Here's the JSX that we're going to use. Now, instead of using HTML, just like that normal-ish HTML like we were doing last time, we're now using the name that we created, the variable name that we created here. This link was assigned to the uppercase button JavaScript variable name. So now in our HTML element, we're using the name button instead of a. And all it has is an href attribute because you have to point it somewhere, right? It's a link. But it doesn't specify the style at all. The button variable actually knows what it is, but you don't have to specify it in this part of the JavaScript file. And the same thing with our image. Remember, we assigned it to the icon variable? We are inside our JSX. We are outputting an icon element. And we give it a source, right? And when React goes and renders this with style components, it transforms it... I'm going to do it in two parts here. First into this. So you can see here that it's created a real chunk of CSS. This is a... What I'm going to show you is all going to be HTML. So this is a real chunk of CSS inside a style tag. And those properties that were assigned to the button variable are now inside this class. And the icon has been assigned to this other class here. And it also will output the HTML. So we've got our link A class, and it's using those really funky-looking class names there. Inside our image, inside our link element. So what's going on here? What has decided is that... If you've ever seen sort of CSS naming conventions, like BEM or SMACS, this is basically saying, I don't care what the class name is. That stuff is too hard for me. I'm just a JavaScript developer. So it's going to create all the class names for the JavaScript developer. This is actually kind of nice. I would like to not have to think about BEM naming conventions. That's what they did. They enforced the BEM structure of having a class for each HTML element inside your component, like the image and the link elements, each get their own class name. But it doesn't care at all about the naming conventions. It just cares that they are unique CSS class names. So this is the third lesson here. We're scoping locally and not globally. And what I mean by that is we look back at that title class that we had. This class name is just a little bit too generic. It's a content semantic class name, but it's used in a lot of different places, and CSS class names are always global. There currently isn't a way to make CSS local. Maybe some dev feature inside Chrome or something like that, but not available to production uses of web browsers. So CSS is always globally, and we're going to create a very specific class name that essentially only applies locally. It only gets applied to that chunk of HTML that you created. So even though technically it's still a global CSS class name, you're never going to get the same class name in all your other components that you use on the page. Okay, let's look at the fourth lesson that we learned here. And that is that we prevent unused CSS. Now, this is really simple. When you add a component, a JavaScript component to a page, it adds the HTML, CSS, JavaScript, whatever images to the page because you added that component to it. And when you do not add a component to a page, you do not add the CSS and JavaScript to the page. This is really, really simple. If we look at how Drupal 7 traditionally does a theme, we usually have like one giant CSS file and one JS file. And if you like to break your CSS files into smaller chunks, it still will do CSS aggregation and make it into one giant chunk for you. But we would like to improve front-end performance, right? We don't want all the CSS for the entire site loaded on every single page. Ideally for front-end performance, we would like just the CSS that's actually on the page load. And it turns out we can do that in Drupal 8. I'm going to go over these in details in later slides, but let me briefly describe how that happens. We're going to add a component CSS and JavaScript into what's called a library that's only used by that component. And then we will add that library from the twig file, which contains our HTML. And that means that when Drupal builds a particular page, it's going to be grabbing these components, which are twig files. And obviously, when it outputs the page, it's only going to have the HTML from the twig files that it grabbed. And those twig files will say, hey, I would like to add a library for my little chunk of HTML. It includes this CSS and this JavaScript. And that means that Drupal 8 will be able to only give you CSS you actually need for the page. Ricky Bakau. And I really hope that I'm pronouncing her last name properly. I used to work with her, but I always said, hi, Ricky. Anyway, she tried this out. There's a blog post here on this website. And she found that it halved the CSS that was actually loaded on a page. This is a great result. Now, let's get into some details. Let's actually build a Drupal 8 component. And we're going to start with creating a theme using a .info.yml file. See, I told you this was a beginner session. So inside our themes folder, we'll create a oida folder. Yes? Okay. oida.info.yml. In the .yml file, we specify what the name of our theme is, what kind of Drupal thing this is, which is a theme. Give it a quick description. Tell Drupal that it's compatible with Drupal 8, which is the core line there. Based theme regions, you can read all about that information inside this website. And then let's look at the libraries there. So we're adding one library, which I called oida slash HTML element styles. And this is essentially just like your reset rule or your normalize. You're just trying to add some CSS that styles that the CSS rule sets in this library will just, the selectors will just be HTML elements. So like you'll have a P as a selector, and then you'll describe how you want to style paragraphs. This is, this library is specified inside the .info.yml file says load this library on every single page, because we're probably going to need most of it. This is the only thing that I recommend that you load on every single page. All the other components will be, have different libraries, which we'll show in the next slide here. But this is the one global library that I will add for every single page, and you add it by using the .info.yml file. So now let's create a components library. This is in the themes oida, oida.libraries.yml, and we just tell Drupal what the name of the library is. We're going to create a button component, so let's just call this library button, right? So button colon, and then it creates, it has some CSS and JavaScript, and the syntax here is that you specify component, this is a little bit of boilerplate, and then you specify the path to your CSS file, templates.buttons.styles.css, and our JavaScript, again, templates.buttons.behavior.js, and this will create a library that Drupal will recognize, the full name of it will be oida slash button. And talk about why these files are inside a template slash button in a second here, because next slide is created components directory. This is inside Drupal 8's themes directory, we've created an oida directory. Drupal 8 has a rule that it says that all of your HTML.twig files have to go inside a templates folder. There are ways to change that default behavior with extra modules, but I'm just going to talk about what Korg does for right now. So you have to create a templates folder, because otherwise Drupal won't find any of your twig files. So once we have a templates folder, we'll just start putting our components in there. Hit a button folder at our JavaScript, at our CSS, and in this case, we're going to use field dash dash field dot dash link dot HTML.twig. I will come back to this naming convention here in a second of the name of the twig file, I should say. The CSS file and the behavior file, you can name it whatever, right? It just has to match what you specify in the library scenario. In the library style file, right? So this path template slash button dot style dot CSS matches this path inside our OIDAs. Templates slash button slash styles dot CSS. So that's what you're doing inside the library's file. We're specifying the path, we're creating the same structure when we're actually creating files. So let's go and create a twig file now. I wish that I had more time to talk about how you pick a particular twig file name. That's, I just don't have time to talk about it. But there, because I could talk for like half an hour on it. But there is a URL here on twig template naming conventions. It will, inside the drivelay documentation, it will tell you that you should enable twig debugging. This means that you can look at the page source when you have your Drupal site open and it will print out some HTML comments inside the source that says, by the way, this chunk of HTML is coming from this file. And it will show you field dot HTML dot twig and then all these other different options you can choose from. We've chosen one of those options. In this case, field dash dash field link. This means as a type, the field that we've added to this particular entity is a link field. And we're adding some HTML to this file. These last three lines are straight out of the default field dot HTML dot twig file. And the important one here is the very first one here. It says attach library and then parentheses oida slash button. Now, attach library is a special Drupal 8 function that it is added to twig that says when we actually grab this twig file and render it, we also want to attach all the assets that are specified in this library. So remember, we created the library to say add this template slash buttons slash styles dot CSS file and also the template slash buttons slash behavior dot JS. So when Drupal sees this line as it's rendering the twig file, it will also go ahead and add that CSS and that JavaScript file to that particular page that it is creating. And there's more documentation about attached library here and that's it. We don't have to get any more complicated than this. This is a very simple way to do components inside Drupal 8. Last year at DrupalCon in New Orleans, I talked about a more advanced way and it turns out to be really advanced. It's really hard. I can do it, but I have a ninja level Drupal theming experience because I've written part of the system. But this is very basic. This is easy for beginners to get a hold of and I think it's very doable for everybody in the Drupal community. I would love to talk more again about how to name the twig files, but I'm going to give you some hints here about what comes next as far as once you've done this basic version of components inside Drupal 8, learn about libraries override in the info.yaml file. Sometimes Drupal adds more CSS than you actually want on a page and this comes because the classy base theme comes with lots of CSS to be useful. But sometimes when we're trying to create our component, we discover that classy is adding some extra CSS, which we're having to override and anytime we're trying to override a rule set that Drupal adds by default, it's probably better to just tell Drupal not to add that CSS and that will make your component CSS much cleaner. So you can learn about that here, override extend. I'm going to give you one more tip for intermediate level Drupal theming. There was a session yesterday on UI patterns. It has an RC1 release. It is not quite fully baked, but it looks very, very promising and I am definitely going to be keeping an eye on it. It will solve the weird HTML naming convention thing that I didn't get to talk about like field-dash-field-link.html.twig. With this module, you would be able to create a button.html.twig file and then through the UI, tell Drupal, by the way, when you render the link field, please use the button.html.twig file. I like this concept a lot. So definitely when you're ready for it, check it out. Hopefully by then it will have a 1.0 official release instead of just an RC1. So what did you think? So last time I gave a talk, I got one person to fill out the questionnaire and all they did was complain about my jokes. So can you please at least have two people complain about my jokes this time. So, thank you. Thank you. And if you have questions, please come up to the front here. So my question is, in the examples that you showed us, we saw those funky class names that were generated and you showed us some simple styles of how you make a link look like a button and so on. But my question is, how does it work for styling, having dynamic styles? I mean things that will be based either on pseudo classes and pseudo elements or also on HTML attributes. A good example would be like, can you package up the focus style for a button or if you wanted to style a details and summary element and give it a really cool open-close icon based on the open attribute. That is a great question and makes me realize that I should have added one more slide to this slide deck about the naming conventions that you can use since we can't use... I gave a presentation... It was Drupalcon Los Angeles where I gave a presentation about BEM CSS naming conventions. If you're interested in that, that will tell you exactly how to name it. But I would also give the advice if you don't want to go with BEM that all you need to do... You don't need to stress about it. The important thing is that when you're writing your CSS file for your component, give it a unique class name. It doesn't matter what it is. If your component has multiple HTML elements inside it, each of those HTML elements will likely need its own unique class name. Just make sure it's a unique class name not used by any other Drupal thing or any other component. And it would be fine. Naming conventions... The CSS and JavaScript... Those naming conventions are... blood-curdling. So it doesn't matter what it actually is just as long as they're unique. So when you're creating... when you're creating your CSS file, you can use SAS or you can use just vanilla CSS and just, you know, like button... colon, colon after for, you know, after. And if you had like an image in your button, you could have button underscore underscore icon or something like that. The thing that will be generated will look like generated funky class name. Sorry, are you talking about in JavaScript or when you're creating it for Drupal? So say you wanted the focus styles for a button to be packaged up in the component. Would you, in your style sheet, you have button-focus like you normally would... No, button just colon-focus, right? This is a normal CSS. If we're talking about Drupal 8. What does it do? Is it generates a CSS and generates two styles? So in Drupal 8... not the JavaScript, right? Right. So in Drupal 8, that CSS file that you point to inside your libraries.yml file, that path should be a generic... sorry, a vanilla CSS file. So if you use CSS, you have to point it at the generated CSS, right? So if you're using SAS, for example, you would need a separate SAS file and it would need to actually create a real CSS file for that little chunk of SAS, right? So that little chunk of CSS can have as many rulesets as you want inside it, right? So button, colon, brackets, whatever those styles, button, colon, hover, comma, button, cover, focus, and then brackets. Yeah. Okay. Usually the selling point for aggregation is that you have, instead of multiple files, you have just one CSS file because everything's bigger and then, of course, this one is bigger because it contains a lot of stuff that you don't need at this moment. Otherwise you would have to get the files on each page. So is it worth it to have this... Is there a problem having more separate CSS files if they're smaller? So by creating components in this way, you have maximum flexibility on how the aggregated CSS file for a particular page gets generated, right? The default way that Drupal will do it is just whatever happens to be on this page, that's the CSS that will go into it. And you're absolutely right. Then on a different page, it'll have a slightly different aggregate. Drupal will try to, a little bit, try to have a couple different aggregate files and sometimes they will match across different files and it'll just be like two of the aggregate files may match on two different pages and then one of them will be different. But there is something called advanced CSS aggregator or something like that that can give you more control over how do you want to compile... Yeah, how do you want to aggregate your CSS files? Because sometimes certain components will naturally be on the same pages together. So you can create like a grouping of components, like when this one component comes, just give all the CSS and JavaScript for the rest of them too because they're likely to be on the same page. So you can tell the module create these groupings of components to make the aggregates more efficient when you're traveling across the website, right? Now a lot of websites, you'll have like one page hit, right? They'll read a page and then they'll leave. So in that case, you want the least amount of CSS for that one page hit. But it totally depends on what kind of user you have on the site. There's no like easy solution for this problem. But definitely this method of specifying little chunks of CSS will give you the flexibility to do more advanced things. Yeah, I was somehow assuming from your session that you are giving up on the aggregation No, no, no, I'm not giving up on it. It's just like... It's quite complicated to configure, I think. Yeah, it's hard to configure and it's hard to strategize these things but this will give you the flexibility that's required to do those kind of that kind of work. Anything else? I'm going to stick around for another 10, 15 minutes so if you have more questions that you don't want to be recorded, I'll be right here. Thank you very much.