Or if you don't like semicolons, you can remove them. When it comes to creating a function or a variable, it's just much more natural, in my opinion, and it works great. So take a look. You create a function, borderRadius, and then you add your stylings. And then when you want to reference it, you don't say @include or some other thing that's hard to remember. You just call it like a normal function. I really like that. Okay, so let's pull that in.

I really like that. Okay, so let's pull that in. But of course, we're using Laravel. So how do we use Stylus with Elixir? And as you may know, right now, Elixir just includes support for Sass and Less out-of-the-box. We can't do every single preprocessor, or it would get incredibly bloated. So I created a little package that you can pull in. It's only a single file, but it'll get you up and running very quickly. So let's do that now.

It's only a single file, but it'll get you up and running very quickly. So let's do that now. The first step is, let's pull that in. Great. So now, if we switch back, you can see, whenever you pull in a custom Elixir extension, it's pretty easy. You just require it, and then you call it. So now we have access to a Stylus method, where we pass in our root file, typically. And if you ever want to see what else you can pass,

So it just passes those through. Okay, so let's do this. Let's go back to Sublime, into my gulpfile.js. Let's require that. And now say minks.stylus app.stylus. Okay, let's create that. Now, remember, by default with these, it will always look within your resources/assets directory. So let's do that. resources/assets/stylus/app.stylus.

So let's do that. Resources assets stylus app.stylus. And let's just say body color is red. Notice I can leave off the braces. I can leave off the semicolons. I can do whatever feels most natural to me. Okay, so let's see if that worked. We run gulp. And there we go. So within public css app, it has now been compiled.

And there we go. So within public/css/app, it has now been compiled. Great. So for example, primaryColor equals green. And now anywhere within here, I can reference that. Really clean, right? So if I run this again, or of course, we can do gulp watch. If we take a look at this now, we're using green. And also the same would be true for mixins. So for example, a mixin I often do is something like nakedLink.

And also the same would be true for mixins. So for example, a mixin I often do is something like naked link. So that's when you have a link, but you don't want it to appear like a typical default link where the text is blue and it's underlined, right? You maybe have a heading and you just want the anchor to adopt the styling of the heading. So in those cases, I might do something like color is inherit. Text decoration is none. But then maybe when you hover over it, you do want to apply some text decoration. Whatever, you get the idea. Now I have this general purpose mixin that I can reference anywhere within my style sheets.

I just wanted to show you the basics. Of course, in real life, you really do just use about 30% of the features. But there's iteration. There's mixins like you've seen here. There's full functions that return values. There's all of this convenience. But in my experiences, you'll stick with kind of the basics, like variables and mixins and things of that nature. Okay, so now how would I reference this? Well, maybe you have a resources/views/layout file, like so.

Okay, so now how would I reference this? Well, maybe you have a resources/views/layout.blade.php file, like so. And I would just reference it here. Link. Now a lot of people use like the asset function. I honestly don't. I just reference it directly here. Or if I'm using versioning, then in that case alone, I would use Laravel's elixir helper function, like so. And then, of course, down here, I would yield my section or wrap it up however I need to.

I would use Laravel's elixir helper function, like so. And then, of course, down here, I would yield my section or wrap it up however I need to. Okay, but next, what about structure? This is something I always had trouble with. So we hear about things like BIM and object-oriented CSS and components. But you know what? At least in my experiences, it was very hard to apply some of that stuff, especially when I would start a project. Because it's just me and I'm not necessarily a designer, I don't have something to work off of.

So yeah, it was difficult for me to identify components when I didn't really know how things were going to look in the end. But what I found is when I did start working with a dedicated designer and I would have a complete understanding of the visuals before writing the CSS, suddenly everything made perfect sense to me. That's definitely interesting. So for example, I would, within my css directory, create a handful of subdirectories. So for example, I would have a components directory. I would have a pages directory.

So for example, I would have a components directory. I would have a pages directory. This is one that people never talk about, but I found that you end up needing. So you just learn, well, everything should be a component. So you have a Button component and then you have a Box component or a Media component. And then you just collect and combine those components to build your site. And that works, definitely. But then you'll find, well, on this page, it displays a little bit differently. And no, you don't want to create another different state because it really only applies to this one section in the entire project.

And no, you don't want to create another different state because it really only applies to this one section in the entire project. So in those situations, well, for example, one that I had recently on the new join page for Layercast that I'm working on, there's a bit of styling that just deviates from the component. And that's the only place that's done. So I don't update the component styling itself because then it would be applied everywhere. This is a unique situation that is only applicable to that page. So I would create a join.style page.

This is a unique situation that is only applicable to that page. So I would create a join.style page. And then I would say, for whatever the component was, I would apply my override here. However, we do have to make sure that this is only applicable on that page. So in those situations, you could either apply an ID to like your body or your HTML element, or even a class would be fine. And it has less weight too. So in that case, I might do something like this.

And it has less weight too. So in that case, I might do something like this. On the join page alone for this little component, I need it to look a little different. So now how would we dynamically apply that class? And you could do something like this. If I go back to my layout file, if you want to do this to the body, then you could always say something like this, yield and some naming convention, body class.

then you could always say something like this, yield and some naming convention, body class. Now in any of our subviews, if we need to apply a class, then we just create a section and take care of that. That's one way we could tackle this. And in fact, there's actually a few different ways we could go about this, but that's kind of quick and it does the job. So for example, I know we have that welcome view out of the box. Let's just make sure we extend our layout file.

So for example, I know we have that welcome view out of the box. Let's just make sure we extend our layout file. And then we'll say for the content, hello world. And then up here, I could say section body class will be maybe that join page that we were talking about. So yeah, now within our layout file, we will yield the body class. We will yield, I'm sorry, the content section. And then we pick those up within our main view so that if I switch over to the browser

And then we pick those up within our main view so that if I switch over to the browser and visit that page and view the source, now we can see the body has a class of join. And that will be unique to this specific page. So that's unique. Remember, you don't want to just immediately defer to page-specific styling because it is brittle. You would only do that in situations where you absolutely need to override.

So this isn't something that could be applied to something else. It's very unique to that. So it's appropriate to give it that specific of a name. So I might say something like foreach $testimonials as $testimony or $testimonial. I'm not sure about that one. But anyways, I would do something like that and then import a partial. So I would say something like include.

and then import a partial. So I would say something like include. And remember, by the way, this is in your Blade file. This isn't in your stylus file. But yeah, I would include something like testimonials/testimony. And then within that partial is the specific markup for a single testimony. And that way anywhere in my project, if I want to display a testimonial,

And that way anywhere in my project, if I want to display a testimonial, I don't repeat the HTML. I just extract it just like php. You extract it to its own partial and then you include it where you need to. Now back to CSS, I found that this is often a good indication of your components. So in this case,

of your components. So in this case, it would make sense to have a Testimonial component. So maybe that can be our first one. Components, Testimonial. Now we can create that Testimonial. And now as far as naming convention, I think this is considered the BEM syntax. You know, honestly, there's so many different inversions.

Trust me, I've gone all over the place on this. What I currently do, I've kind of come around to the traditional syntax. So a component begins with a capital letter, almost like a class in PHP. So for example, every testimonial, well, maybe that has a border of 10 pixels, solid white or something. That's fine.

and then you style it and then the author here and then you style it. But then the author has a span here and then the span has an icon here and you can see how quickly it just gets kind of loaded and overwhelming. I've written this kind of code so much. The original Laracasts CSS that I'm currently rewriting.

So for example, if I want to style the testimonial__body, I could say testimonial__body. That's just a somewhat arbitrary naming convention that people have used and it works actually pretty well. When you name the element like this, you do two things. One, you're following a convention,

you do two things. One, you're following a convention, which is always good. Two, in your markup, you make an immediate connection that there is a link between this element and the Testimonial component. Because sometimes, for example, let's create this div class is testimonial.

They, once again, from my experiences, they blow up in your face if you're not careful. So when in doubt, just defer to a class name. But anyways, what you'll find is that you often have lots of class names so you could have something else.

where exactly do I look for this? I'm just going to have to do like a find all in my editor to figure out where I declared that. So yeah, definitely from personal experience, that has a tendency to break down and get very complicated for large projects. So instead, we follow this convention. For a sub element,

we follow this convention. For a sub element, we would say testimonialBody. And now it's explicit that this is a child of this and the two are connected. Second, because we're no longer indenting or we're not doing something like testimonialBody,

once again, testimonialName, well, we don't have to hardcode the element. We don't care what type of element it is. So I can say testimonialName. And now that will be color red. And if I switch this to an h3, it doesn't matter.

And if I switch this to an H3, it doesn't matter. It's still going to apply. And by the way, this is specifically why a lot of people recommend class names that correspond to headings. So a class name of like H2. This rubs a lot of people the wrong way, but it's kind of rooted in this idea.

This rubs a lot of people the wrong way, but it's kind of rooted in this idea where yes, semantically, this is an H3, but in terms of presentation, you want it to look like your typical H1 does. So in a typography partial, you might have something like this where you apply your styling.

that's where little utility classes can be pretty useful. So for example, if it made sense, some note here, let's say <div class="note"> is some note here, whatever would be appropriate there. Well, you could do something like u-center or u-align,

for every possible piece of styling. Many times it's just better to put it in here if it's relevant. However, for the one offs where you do it all the time, even things like float left and float right. I think it makes sense to have utility classes and it will clean up your code.

testimonial is very unique, so it's OK in that situation. But other times it's better to be a little more generic like box. If you have general styling for a box, then you could represent them within a class. And that might be as simple

within a class. And that might be as simple as 20 pixels of padding and a border of one pixel solid gray. The key is to make this as generic and reusable as possible, so not too many specifics here. You would add additional classes to make it more specific.

You would add additional classes to make it more specific. OK, so let's see what this would look like. I'm going to get rid of all of that now. And we have a component for a Testimonial. However, at the very top, we'll also have some bootstrapping type stuff.

we'll also have some bootstrapping type stuff. So, for example, this could be a good place to import maybe something like normalize.css. So that could go within maybe a vendor directory. vendor normalize. And then next we have,

Vendor normalize. And then next we have, well, maybe a section for our typography. Next, I like to store all of my coloring within a colors file. So in that case, I would have colors.style. And then I would do things

I would have colors.style. And then I would do things like primaryColor, the main key color in my project is blue or whatever. And now I can define that in one place. And because I imported at the top here

And because I imported at the top here in any of these other partials, I can reference that variable. And by the way, if you prefer to use the $ sign, sometimes I find it just kind of works with my brain more.

just kind of works with my brain more because I do so much php. I immediately identify that as a variable and maybe not that instantly. If that's the case, then just do the $ sign, however you want to do it. Or in fact,

And it's like, well, then you would do a search and replace. Look for this variable and replace it with your new one. So now it's green and that will be referenced everywhere. It's up to you. You can make up your own mind, but I can tell you that

something like green. And then again, if I need to change that out for the new color in my styling, then a quick search and replace within this directory will do the trick. Now let's go back to components. We have this Testimonial component. And now, well,

We have this Testimonial component. And now, well, I'll show you a couple examples. I have general styling for a Testimonial, but there's also a scenario where I want a Testimonial to be featured. And in that case, it takes up the full width.

needs to be featured. Well, you would just say testimonial is featured. And that's it. And then in terms of your php, you know, you might have something like if the testimonial is featured, then you would apply that custom class. And that's it.

And actually, let me show you this real quick. Let's come back. We don't have that. So I will comment those out. But you get the basic idea. And if I were to run gulp again, there we go. Let's visit app.css. And yeah, we can see

Let's visit app.css. And yeah, we can see that represented here. So yeah, that's kind of a neat trick to use. You can use the & symbol to represent the current name of the class. So I'm just saying substitute basically this where the & symbol is.

And that is not correct. We still want it to be the testimonial that has a class of isFeatured. So in those cases, again, you could do it like this. testimonial isFeatured ampersand. This is a cool trick that not enough people know about. So if you ever have

that not enough people know about. So if you ever have styling for an element and you want to say, well, just as long as it's a child of this unique class, only on that condition do I want to style it. Otherwise, I want the text aligned to be center.