Thank you @AJ-vy4yu! Curious what did you do differently?

@@dmtrmrv I created elements of elements and blocks with too many elements, to name a few. I had really long-ass class names😆

Thank you! Yeah, once it "clicks" you don't have to think about it!

Yeah, those outside margins can really mess up reusability!

Thank you, glad you liked the explanation!

Happy to hear that! Yeah, BEM can be a bit tricky and definitely has its downsides (might be a good topic for another video). But I'm still picking it for every new project.

You are welcome! Glad you found it helpful. I agree, fundamentals are super important!

I'm glad you liked the explanation! I believe there's nothing inherently wrong with nesting; in fact, some methodologies even encourage it. Based on my experience though, both reading and writing styles become easier when nesting is limited and done purposefully and specificity is maintained at the lowest possible level. Feel free to reach out if you have further questions!

Thank you! Glad it was helpful!

Thank you for the kind words, happy that the video was helpful!

@bls512, thanks! I'm glad you found the CodePen useful. Good question! I honestly think Utopia is just a tool (a great one though). What's important when using it on larger projects is ensuring the team is on the same page about how to use it. And generally, for large projects, clear communication with your team is crucial. This includes having straightforward guidelines, clear commit messages, PR descriptions, good documentation, and keeping everyone updated.

Thank you for the kind words! Are there any specific topics or concepts within CSS you'd like to see covered?

@anneyo5627 That's a great question. Ideally the spacing is created with properties like "gap" or by using the "lobotomized owl" technique. Check out the CodePen: codepen.io/dmtrmrv/pen/vYMEGpx?editors=1100 You can find examples of both: .grid { gap: var(--step-1); } .content-flow > * + * { margin-block-start: var(--step-1); } If that's not enough, we can always use margins on elements, because they aren't reused on their own. ".button" in the same CodePen is a good example. Look at the ".button__icon" element: .button__icon { margin-inline-start: var(--step--5); } All this allows us to reuse components in different contexts without any spacing overrides. Let me know if this answers the question!

Thank you so much! This was helpfull. First time i've heard of the 'lobotomized owl', interesting!

@@anneyo5627 You are welcome! You can read more about it here: alistapart.com/article/axiomatic-css-and-lobotomized-owls/ The article is 10 years old, but it's still relevant. "gap" was not around at the time, but it's still not a full replacement.

Thank you. Glad it was helpful!

Hey Paresh, thank you! Are there any specific aspects of CSS you find challenging to grasp? I'm developing a content plan for the upcoming months, and your feedback would be really helpful.

@@dmtrmrv There are good tutorials available on KZfaq, but it's important to understand how much CSS is sufficient and how it's applied in the industry. Essentially, create something that is beginner-friendly yet meets industry-level standards, which puts us a step ahead of others.

@@pareshkamaliya2493 Thank you for these ideas. I'll def address this in future videos.

Thank you, glad it was helpful!

Hey Juan, thank for the kind words! Welcome aboard!

You are welcome!

@EyeIn_The_Sky Thanks for the question! You are actually not the first one to ask. I see how this part of the video can be a bit confusing. In short, it depends, but you are right. Gap is one of the tools, another is setting the margins using rules like .container > * + * { margin-block-start: Xrem; } which adds margin to all children except the first one. I have a video about exactly that coming in the next few days, so stay tuned!

@GameOver-db7wg Thank you for the question! I'd be happy to look at your code to provide more specific guidance, but here are my thoughts on creating a block vs. an element. If an element has a distinct role in your interface, it's a candidate for a block. Even if you're unsure about reuse, it's better, in my opinion, to have more blocks than fewer. This approach helps avoid the issue of complex blocks that we discussed towards the end of the video (14:22). Regarding utility classes, .visually-hidden is a great example. In my projects, I also use utility classes like h1, h2, h3 to style other text elements to visually resemble these headings. The key is consistency. Consider how consistent you can be with these classes. Are they truly atomic? Can you keep reusing them effectively? Again, I'm happy to look at your code to give a more detailed answer.

You are welcome! Thank you for asking about BEM in the first place!

Glad you enjoyed it

Hey @gaming_with_raza7867, thanks for your question! Honestly, there’s no easy answer to this, but I’ll try to respond to the best of my knowledge. In short, it’s a journey-there’s always something new to learn, especially in Front-end development. I also struggle with responsiveness sometimes, particularly with complex components or unclear guidelines. What usually helps is working your way from mobile up. Build your projects as if desktop doesn’t exist, then add layers of styles for larger viewports. Use implicit grids and clamp to avoid relying too heavily on media queries. In general, learn typography. The web is mostly text, and knowing how to represent textual information well can help a lot. Try to approach every project as a system rather than a one-off thing, and you’ll improve over time. Trust the process. Hope this helps!

*Well kinda. within the competing layers anyway.

Yeah, I am very curious about using @layers and @container. Didn't have a chance to use them on a real project yet. Layers do help resolve some specificity issues for sure!

That's a great question. I tend to use :where() for setting up the default, most common look of elements. And I actually find it quite handy that blocks and elements get this slight increase in specificity-it helps them stand out against the defaults. Sort of sit on top. I'm curious to know how you'd use :where() with/instead of BEM.

​@@dmtrmrvFirst a little disclaimer: I am not a designer, I mainly work on web applications and the styling takes less than 5% of my time. I want the markup to be as simple as possible, so BEM implementation is annoying because I have to set classes everywhere. But I understood that this makes it easy to style a "breadcrumb-item". I am stil experimenting but now I tend to create parametrizable styles. Say I want to build a breadcrumb and the markup I want to have is the one from ARIA APG breadcrumb example. I would set up custom properties on the .breadcrumb "block" class, use :where to rely on the DOM to find the "elements" without increasing the specificity, and apply the styles on them using the custom properties. .breadcrumb > :where(ol) > :where(li + li)::before { padding-inline: var(--breadcrumb-item-padding-x); ... }

I see; that's more of a CUBE flavor (cube.fyi/). Another methodology I really like. The downside to writing styles like this is if anything in the DOM moves, the styles will break. However, in the case of components like Breadcrumbs, which have a super standard structure and rarely change, it's perfectly fine to write it even simpler: .breadcrumb li + li::before {}. This is because the likelihood of the breadcrumb component having two lists with two different types of elements is very low. It's also a matter of consistency. If the rest of the project is written in BEM, it's still advisable to add classes; otherwise, it's a perfectly acceptable approach. Glad you brought it up! I like conversations like this!

Like you said, there's a time and place for everything. Both BEM and the utility-first approach have their drawbacks and advantages. I'm curious if you've come across this article: nuejs.org/blog/tailwind-vs-semantic-css/?