Sass Fundamentals

Challenge 9: Solution

Sass Fundamentals

Check out a free preview of the full Sass Fundamentals course

The "Challenge 9: Solution" Lesson is part of the full, Sass Fundamentals course featured in this preview video. Here's what you'd learn in this lesson:

Mike walks through the solution to Challenge 9 and takes questions from students.


Transcript from the "Challenge 9: Solution" Lesson

>> Mike North: We're going to go through the solution here, to a building our buttons BEM style. So switching over to my code here. Let me just get rid of the last solution.
>> Mike North: That was an interesting literary strat there.
>> Mike North: All right, killall -9 node. So if you get an error that a ports already running, I saw a couple of people with that it could be that one of the exercises is running in the background.

And here we're gonna run an exercise called Bem.
>> Mike North: So what we have are basically the buttons. They're sort of structured correctly, they're just not styled the way we want them to be styled yet.
>> Mike North: So we'll open up our project here.
>> Mike North: My editor's throwing some curve balls to me today.

>> Mike North: Here we go, BEM, and here's our Sass, and now we can get rid of our sidebar here. So I do actually wanna see one thing.
>> Mike North: Let's look at our HTML. So I'd like to draw attention to what's going on here. This is our component and what we have is the button has a modifier on it called button --mode-primary, right?

This is the equivalent of our button-primary thing that we've been using in several exercises today, and inside, we've got an element and that is this BTN underscore price. Right, sorry BTN double underscore price. This is the convention for element that we have two underscores between the block and sort of the name of this element.

So let's get started here. We've already got some basic styling here and part of the instructions involved following the color schemes from Exercise 1. So let's get started. So we're gonna do btn--primary, and this, sorry it's not btn--primary, it's btn-mode-primary. You'll see modifiers often come in the form of collections of modifiers that all are grouped by a certain theme, like button size big, or size medium, or size small.

And often times, you'll see families grouped together in this way. Families of modifiers.
>> Mike North: And here we'll go button mode secondary.
>> Mike North: And here we're gonna have background of c, I think it's c49 or c69, let me just look at Exercise 1 here real quick, which was nesting.

>> Mike North: c46, close.
>> Mike North: So that should make the primary button happy. I see that the button primary also needs to have a good heading value, padding left is 10 pixel and 14 we said instead, so we can just fix that.
>> Mike North: What we've got now,
>> Mike North: Is we're looking for changes in colors.

So now, we've got text color popping up as the next failing task the primary button should have a text color of white.
>> Mike North: And I know this one is gonna want black.
>> Mike North: And the background should be the same as what we used in exercise one so just grab it from here.

>> Mike North: Okay, and now opacity, it looks like when the button is disabled, we need the opacity to be 0.5.
>> Mike North: And then finally, we have a test that relates to the element, the price that is inside our button. So I'll define a selector for that. Just a reminder that we can just use __price, here take advantage of the fact that the .btn comes along for the ride.

It is important to note that elements will almost always begin like this. Modifiers will often begin with like a& so this will have a padding three pixels, I think it was one pixel and I have that flipped. All right, now, finally button price should have a background color of,

>> Mike North: 080. But let's see and 08 was found instead. This is really interesting because I have what it's looking for. I think that some of the color can version stuffs in my test is
>> Audience 1: What is words looking for?
>> Mike North: 0008-
>> Audience 2: And three zeros.
>> Mike North: 000.
>> Mike North: Interesting.

And now, finally, we've got like when our buttons disabled we want the price to no longer be green, right? We want that to fade out as well. So important to know that we're gonna have to break, we're gonna have to express some style about our element in here.

The reason I gave you this little exercise is so that you could discover that we can't simply put our ampersand in here again. That would refer to disabled, like we're already another selector deep, and you can't just double down on, you can use that ampersand once your another scope down the line.

So here we would have to deal btn_price and then the background would be again the same one I'm guessing.
>> Mike North: No, it's aaa, there we go, and all tests are passing so we could not do this I believe. Yep, see it doe not apply.
>> Mike North: In fact, I'm intrerested to see what CSS this is gonna generate for us.

What is that gonna look like. Yeah, see not good. Not good. [LAUGH] So,
>> Mike North: It's one of the limitations. We don't quite have enough tools to make that a really elegant thing, but here you go. This is a totally valid BEM component. Low on the complexity side but hopefully, you start to see some of the best practices you already kind of align with.

There's the formalized in this methodology.
>> Audience 3: You're asking why did you use BTN. --mode primary instead of &-- mode primary?
>> Mike North: Here &-- mode primary like this. Good question. So let me fire up the exercise again. So you'd find that this would work. You'd find that this would work.

Here's the difference and the out part of the CSS. If we look up here, so I've actually got two different ways of doing it. This is perfect. I've got one secondary. It's using the wave that I initially solved the problem. I've set primary equal to the way the person asking the question online.

Express it and the resultant CSS looks like this. So you see what I've done is I've popped out of the scope of BTN now my modifier is potentially floating around and it's applying its styles even outside the context of the block element. And although in this particular case it couldn't cause trouble.

This is less specifically scoped than the rule should probably be. If we were to kind of adhere to the best practices that would, it'll protect us from tripping over our shoelaces as our app scales. Good question though. I wish there was an elegant way of expressing modifiers that matches how nice these end up looking for elements.

But I would sooner write these out than like have those things floating around in the open outside the context of the BTM class.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now