as always so useful, but I have a question not entirely related. How could one get around having to get the back-end done yourself, and instead just have e.g. an email submission form made with an API? Could that be possible? If so how? Because I actually built a sort of fully-blown html and css project with different urls but my goal for this website is for it to get people submit their email to apply and stuff, but that would require some kind of back-end. Would it not? Hope I explained myself clear enough, sorry if not. Thanks again!
@@lucianoramirez6525 Yes it does require some backend if you want people to sign up to apply for something. If you just want a contact form that sends you a user message from your website, its very easy to do.
Came here after watching Kevin Powell's video on BEM. There he had said "specificicity", and here Gary says "specifity". Guess Kevin stole Gary's "ci".
@@DesignCourse "Specificness" -- much easier to say. It's even in the dictionary! Apparently it has a slightly different meaning, though... although *I* think it's more accurate (i.e. more specific to what we are using it for) ;D
One piece of advice is: don’t forget utility-classes just cause you use BEM! A ”hidden” class makes more senese than having a ton of modifier classes that do the same thing, like ”card-hidden” and ”article-hidden” Only use BEM for unique styles and not common ones. You can combine BEM and utility classes, no need to go 100% in a single direction. doing ”card card-large hidden” is fine
11:40 "__" is underscore underscore, double underscore or dunder, not hyphen hyphen you did it repeatedly, at some point everything just became hyphen hyphen.
Man you got such a unique vocabulary haha 1:02 "specifity" 3:14 "complexitness" I think you mean specificity and complexity lol I love your videos btw Im just playing around.
Too clunky, too verbose and (imo) just a solution for a problem created by people who have issues dealing with complex CSS layers. Understanding both HTML5 semantics, CSS pseudo classes and having a good grip on how stylesheets actually cascade (and the weighting of the rules) effectively negate the use of BEM. Maintenance you say? Ease of readability you say? For the former, who are you hiring? Devs who should know this stuff or people who can match up names to classes? As for the latter, it really doesn't make it any more readable. Any large project (and BEM is aimed at those) becomes a complete mess when facing repeated nested BEM css classes.
AFAIK BEM was invented to use for pages that builds from some json-like blocks [{"block":"card","elements":{"item":.........}}] HTML markup for this blocks was never writen by hand, so it was another one template builder based on file structure. CSS for each block could be separated. Main idea was to use any combination of blocks on the page. Which, of course, the big deal for large projects. Sadly, some of webdevs tries to use this convention in much simplier projects. Also, using BEM without BEM stack is pretty useless IMO. Here you can learn about BEM stack en.bem.info/technologies/classic/bemjson/ And, yes, cascade is the one letter from CSS abbreviature, but in the very large projects it can cause some glitches, so hard separated styles works.
I've used BEM for many years. Modifiers are great and truly provides a nice way of stating a clear intention that this element has a shared base style and a variant that overrides or adds a few things. But the block__element concept is less useful. It's fine in tiny flat components that you don't change a lot. But in larger things the double underscore often has to be moved deeper down and feels useless. You begin with footer__menu but as that menu gets more and more children you rename it to footer-menu so can have children like footer-menu__user and footer-menu__faq If this renaming happens multiple times, or the dom tree for the footer is quite deep then you end up just forgetting which nodes have the block__element thing and which just use dashes. At which point I usually go "screw it, let's use single dashes all the way" and I never end up regretting it. I still use BEM on small isolated components though.
It is Spe-ci-fi-ci-ty ;-) And why arent you using semantic elements in HTML? Like a section or an article for the card? It is supposed to be an element that can stand alone and therefore it should be an article or a section for each card? I know that there is not a title/heading in this example, but anyways? And why is the picture/img not a part of the content element?
Thank you for this tutorial. In the beginning, why do we need two underscores for Class name instead of one underscore, which is simpler and more efficient?
BEM in 2020? I thought everyone moved on to utility classes. BEM is too verbose and difficult to read. BEM is only good for eliminating CSS specificity. But if you have problems with CSS specificity you probably can't write CSS in the first place. TL;DR use Tailwind over BEM
if i wasnt already using React+Styled Components to deal with such issues, this looks like an amazing system to solve such problems in a practical and DX friendly way
I'm not a fan of BEM. I prefer using utility classes instead of --modifier. Most IDE don't have a problem selecting "card-header" on double click, but will struggle with "card__header". Having an arbitrary long class name will also increase file size. We're removing line breaks and spaces on minification, but 30 letters long classes are fine.
What do you mean by arbitrarily long? In BEM the idea is you can only have a single level: card__header is ok but card__header__title or card__header__title__icon is banned
@@BenRangel I'm talking about double click text selecting, not hotkey. Some don't see cohesion of a string like "abc--xyz". Having class="button button--state-success" creates a larger filesize in HTML than class="button success". In CSS it's the same. .button-state-success are more characters than .button.success and therefor results in a larger filesize.
Why not both? I’ve recently started using a combination of utility classes for shared styles and BEM for unique styling. It seams to be working well so far.
I really dislike this method because it's very redundant. I don't like this method much because it is overly verbose. I'm not really a fan because with BEM you say the same thing over and over again.
BEM Is trying to solve a problem that doesn't even exist Te solution is to use the CSS specificity BEM is like trying to replicate what already exists and works flawlessly
@@christianmartinez2179 I agree. It's not hard to target things specifically. You don't need extra identifiers for that. Using a single "active" class on various elements is, in every single way, superior, to BEM method of having "element" and "element__button" and "element__button.active". In most cases you don't need the element OR the element button class name, but even if you do, you don't need . You can do ALL the same things, the code is FAR more semantic, and you are saving SIGNIFICANT FILE SIZE by having shorter class names! People worry so much about image compression, then they go and make fatass CSS files that are the size of 20 images all in one request because they have 20 extra class names on every rule, they are using duplicated styles for 30 different objects that all have the exact same styles "because BEM" .... and 50,000 styles that aren't used anywhere on the site because of all the hideous frameworks they keep building on top of! Not to mention the extra size in the pages themselves! Everything adds up!
What's the point of doubling up on the underscores and the hyphens? Wouldn't card_button-active tell you the same information (what it's for) as card__button--active?
BEM is destroying a concept of the template, prohibiting usage of CSS functions and possibilities, shoving developer to hardcode. Source: hackernoon.com/bem-should-not-exist-6414005765d6
You should probably change the title to "You Probably need BEM CSS in Your Life (if you're using a preprocessor) (Tutorial)". None of this makes sense with vanilla CSS where the same can be accomplished with _a lot_ less verbose class names.
People always do such basic examples lol, the problem with BEM is when you have multiple components, when you got very large complex components and then people get confused as to what is and isn't an element, especially problematic when people use "wrapper" like "card__wrapper" and then underneath that ungodly things like "card__wrapper__image" or just define classes like "card__wrapper card-wrapper" and then underneath "card-wrapper__image"
Everybody forgetting about that BEM is for auto-generated markup that nobody code by hand. When i see BEM in simple website templates it cause only smile - this dude wasted a LOT of time to do that. Also, in my opinion, the BEM team are snobs who think they have some wonderful knowledge. Fun fact: it took several years to drop the b_ prefix for 'blocks' definition. Everybody can invent own css naming convention. Column width and color classes in Bootstrap (and every other css framework), for example, is modifiers too, so, there is no rocket science at all.
I cannot take the redundancies of BEM. CSS selectors make this possible without re-re-repeating the block name, and re-repeating the element name, just to add a modifier class. Ugh-ly.
I don't see why this is necessary. In your card example, you could use the class name "picture" and target that via CSS with .card > .picture. BEM is just a solution in search of a problem.
That was clear... but a little bit confusing if we want to use isolated component or block to another block. We can not override style from unrelated block. for example, we want to use .btn block inside .card block. Let say that the button inside .card block have different style. So how we deal with it?
BEM is great, but please stop using it in combination with CSS modules. Just leave the Block out and name it EM. I see a lot of juniors doing this and it really hurts readability
Andi Rady Kurniawan if you’re using scss, which will definitely help you a lot, this Bem makes it easier. You can type .menu and in scss the „&“ character selects it again but you can add something. So for example if you have a list in your menu which has the class „menu__list“ you can just type in the menu css: &__list (.menu__list). And that with several items. It just helps you a lot and organizes everything
Coming from a big project, one important lesson learnt: don't abuse Sass/SCSS, keep it to bare minimum. Reason? Trying to resolve a high priority production defect with a huge SPA codebase, it doesn't help to have .block { ...; &__element{... &--modifier{...}} rulsets: it very hard to find the original rule definition in source code, since in the browser you'll see generated version. The lesson learned, in order to be able to quickly find a rule, write entire selector by hand, don't leave it up to SCSS preprocessor. One thing is to write confusing Sass code to impress junior female developers on your team, and another thing to debug prod issue under pressure and a lot of stress. KISS.
if we use example .avatar in whole website with 'modifer' ex. .avatar.small how in BEM its looks like? Do I need create so much code for all blocks by separeted, example card__avatar, userslist__avatar, footer__avatar with same code, but in selfs code placed (i cant grab all and display by comma coz its destroy look of code design)? its nonsense in my opinion.
@@Arttyor That's right, but it removes the necessity for using a naming methodology, at least when you follow the similar process that Adam Wathan (Tailwind's author) does.
Why not .card ,, .card > img ,, .card > h2 ,, .card > p ,, .card > a .. ? i anser my own Q --> becose, card__* is unic for sepcial but the "card > img" is for overall styling
Design Course thank you so much for your amazing tutorials. Your Videos are really unique. I have a question, when a block gets very big(when I start a big project it gets really confusing for me how to break it to smaller blocks and elements. does anybody have any suggestions? Thank you all in advance :)
Awesome video as always! Quick question, could the ul be card__content__list? and the li card__content__list__item (modifier as card__content__list_item--active)? Would this make it work better with sass/less. Or could something like this be more oocss or smacss?
@@adm7282 yes this is better, because card__item is not so meaningful. Every thing in the card is a card item and is does not explain that it belongs to a list.
i dont really understand, how the selector in css works, when you reference the name just with the the __name, just because its named differently in the html...
oh wait i just scipped the last 20 sec so does that mean, that scss has a build in BEM selector in it, that puts the parent element in front when compiled back to css ?
Yesssss! Finally somebody who I trust covering a topic that seemed to me like a mystery.. I mean seriously.. When I was learning CSS, all that mattered in naming classes was something that was easy for me as a developer.. And then came along BEM, SMACSS, OOCSS and who knows what.. Like wtf.. 😵 Thanks for talking about BEM Gary.. Now how about SMACSS, OOCSS.. 😁
@@sugiono2801 Sup man! Well I'd taken a Udemy course by Jonas Schmedtmann named 'Advanced CSS and SASS' course. Within that he mentions of these methodologies for naming the various classes. But he uses the BEM method during the course. It would be worth noting these methods because recently when I was browsing through job postings on LinkedIn, there are postings where they ask you to have a fair amount of knowledge about a specific method such as BEM.
I once used it but never again. The problem is that you class names become longer and longer and can be simplified with .card.button.active for example.
no, you don't. if you use CSS modules (which is what you should be using to write scalable CSS), the scope is always local and specificity issues disappear. look it up!
@10:30 isn't the semantically tied to the card__content div just above it? It's nested inside that div so shouldn't it be card__content__ul? This is confusing
Here's the only reason I liked this video : He directly, simply, clearly explains what is BEM. That it's a methodology and what's its purpose. It seems all the other guys just start talking and talking as if it's gonna be a philosophical talk. And you don't even have a clue of what BEM is.
Thanks for a great intro to BEM. I used to do HTML/CSS years ago and need to pick it back up at work. These days my company uses BEM and SASS so this was perfect and very easy to follow.
One minor annoyance I have with BEM is that you often get into refactoring discussions in your team as your DOM depth grows. You start out with "card" and "card__header". Later you might need to add a title and an image to the header. But BEM (wisely) forbids nested element-classes like "card__header__title". So then you get into the refactoring debate. Do we do ".card__header .title" or ".card header__title"? And then you might get into asking yourself why you're even using BEM. You could just do ".card .header .title"
great stuff simon, can you please make a video that explain how to configure php for vsCode, so it can auto complete and other things like the atom built-in feature
I use BEM, but one of the things I find the most annoying with it is how absurdly long some class names can get. Especially if you want to toggle a class. Like in your instance if you had a "card__button" and then you wanted to add the "active" class, the two classes alone would be long "card__button card__button--active" now imagine that and pairing it with more classes like for example col-12 col-lg-4 etc. I think the classes just end up looking hella messy after a while.
I dislike classname concatenation like "&__item". I would write the full classname; "card__item". Many new Sass-users fall in love with the idea of concatenating all classnames. My team used to do that but we decided it makes your code messier in the long run. A) You can't copy-paste a full classname from your html and search for it in your codebase. You always have to remember that only one part of the classname is searchable. B) You create a lot of nesting in your code. So when you find "&__item" you always have to look up to see what the full classname actually is. People will argue that "the advantage is that if you rename 'card' to something else, you just have to change it in one place in your sass file" But I'd argue this is NOT a major concern. I don't rename stuff that often, and when I do - search-and-replace only takes seconds. I do however search through and read my code all the time. So anything that increases readability is a more worthwhile investment.
narkar: I like BEM as long as you’re not being needlessly strict about it and try to shoehorn it into every situation. We use utility-classes (like ”hidden”) in instances where the same behavior is reused often. I think it’s insane to use BEM classes for common features like that (for example using card-hidden and article-hidden if they both just set display:none) mostly use BEM mostly elements with many children. If an elem just has 1-2 children and no deep nesting I avoid BEM. ”article p” is fine. We use css preprocessor features where we think its most necessary. We avoid class name concatenation. But We use variables in cases where it make it more obvious how stuff relates to each other, especially for things like z-indexes. I hate seeing ”z-index: 95” , cause writing ”z:index: $popup-z-index + 1” is so much more understandable. We use variables to make sure we use standard measurements as often as possible like $padding-mobile and $padding-desktop but if something needs tweaking because of the font used we’re fine with doing an excepting and hard coding a pixel distance. We don’t use a grid-system for stuff like columns as we do a lot of different layouts for different pages and I think it’s much faster to write custom css for a rare case where we need 5 columns than to use bootstrap’s grid and hack some kind of 5-column-class. (But if we were building a more simple/cheap site that didn’t have time to do custom layouts we’d probably use more gris-systems)
BEMs weakness, if there’s one to be extracted from these comments, is its name. Blocks, elements; most of these people know what those are and that can make it confusing when there are more than 2 nest levels. What I take away from this is that it’s definitely useful if used thoughtfully, when considering the first slides: What blocks on are project are similar in HTML structure but unique in content nature or styling? Card, content, list, these terms are general but if I imagine a blog post preview, album preview, news article preview or rental listing, I can see how BEM would be beneficial. Thank you.
Enjoooy?? Subby subby!
I did.. Coursy? Coursy?
as always so useful, but I have a question not entirely related. How could one get around having to get the back-end done yourself, and instead just have e.g. an email submission form made with an API? Could that be possible? If so how? Because I actually built a sort of fully-blown html and css project with different urls but my goal for this website is for it to get people submit their email to apply and stuff, but that would require some kind of back-end. Would it not? Hope I explained myself clear enough, sorry if not. Thanks again!
@@lucianoramirez6525 Yes it does require some backend if you want people to sign up to apply for something. If you just want a contact form that sends you a user message from your website, its very easy to do.
It's live sass compiler, not compilation i guess 🤭
Had to subscribe. Thanks.
I want a Part 2 where you go more in depth with a bigger project!
I'm mad he never noticed that he added a class to the end of the list item tag
It's the Auto Rename Tag plugin that's doing that
@@1997matthew I know I'm just mad he didn't notice lol
You got mad at that... I got mad at calling Underscores (_) as Hyphens (-) and Hyphens as Dashes >.
I was about to raise my hand and tell him that, thought it was a real-life lecture .
@@1997matthew thanks
Came here after watching Kevin Powell's video on BEM. There he had said "specificicity", and here Gary says "specifity". Guess Kevin stole Gary's "ci".
lolol
😂
me reading your comment: specifi-kitty...dammit
wtf😂
Sorry to be that guy, but it's "specificity"
I can't even say that. And I want to punch whoever came up with the term.
@@DesignCourse Haha, no worries, mate! Great tutorial regardless. Thanks for taking the time to make it for us!
Haha was just about to post this
Actually it's speficitify, everyone knows that
@@DesignCourse "Specificness" -- much easier to say. It's even in the dictionary! Apparently it has a slightly different meaning, though... although *I* think it's more accurate (i.e. more specific to what we are using it for) ;D
One piece of advice is: don’t forget utility-classes just cause you use BEM! A ”hidden” class makes more senese than having a ton of modifier classes that do the same thing, like ”card-hidden” and ”article-hidden”
Only use BEM for unique styles and not common ones.
You can combine BEM and utility classes, no need to go 100% in a single direction.
doing ”card card-large hidden” is fine
Specificity... Pronounced: spes-ih-FISS-city (5 syllables)
:)
Good video. I don't use BEM currently, but I'm going to play with it.
11:40 "__" is underscore underscore, double underscore or dunder, not hyphen hyphen you did it repeatedly, at some point everything just became hyphen hyphen.
It ground my gears to much.
Man you got such a unique vocabulary haha
1:02 "specifity"
3:14 "complexitness"
I think you mean specificity and complexity lol I love your videos btw Im just playing around.
The second was was him saying "a little bit more complex than this".
Too clunky, too verbose and (imo) just a solution for a problem created by people who have issues dealing with complex CSS layers. Understanding both HTML5 semantics, CSS pseudo classes and having a good grip on how stylesheets actually cascade (and the weighting of the rules) effectively negate the use of BEM.
Maintenance you say? Ease of readability you say? For the former, who are you hiring? Devs who should know this stuff or people who can match up names to classes? As for the latter, it really doesn't make it any more readable. Any large project (and BEM is aimed at those) becomes a complete mess when facing repeated nested BEM css classes.
AFAIK BEM was invented to use for pages that builds from some json-like blocks [{"block":"card","elements":{"item":.........}}]
HTML markup for this blocks was never writen by hand, so it was another one template builder based on file structure. CSS for each block could be separated. Main idea was to use any combination of blocks on the page. Which, of course, the big deal for large projects. Sadly, some of webdevs tries to use this convention in much simplier projects. Also, using BEM without BEM stack is pretty useless IMO. Here you can learn about BEM stack en.bem.info/technologies/classic/bemjson/
And, yes, cascade is the one letter from CSS abbreviature, but in the very large projects it can cause some glitches, so hard separated styles works.
I've used BEM for many years.
Modifiers are great and truly provides a nice way of stating a clear intention that this element has a shared base style and a variant that overrides or adds a few things.
But the block__element concept is less useful. It's fine in tiny flat components that you don't change a lot.
But in larger things the double underscore often has to be moved deeper down and feels useless.
You begin with footer__menu but as that menu gets more and more children you rename it to footer-menu so can have children like footer-menu__user and footer-menu__faq
If this renaming happens multiple times, or the dom tree for the footer is quite deep then you end up just forgetting which nodes have the block__element thing and which just use dashes.
At which point I usually go "screw it, let's use single dashes all the way" and I never end up regretting it.
I still use BEM on small isolated components though.
It is Spe-ci-fi-ci-ty ;-) And why arent you using semantic elements in HTML? Like a section or an article for the card? It is supposed to be an element that can stand alone and therefore it should be an article or a section for each card? I know that there is not a title/heading in this example, but anyways? And why is the picture/img not a part of the content element?
Thank you for this tutorial. In the beginning, why do we need two underscores for Class name instead of one underscore, which is simpler and more efficient?
12:03 Was it necessary to add class="card__item" inside the closing tags as well? Or was it a typo?
Just a typo ^^
Definitely an error
BEM in 2020? I thought everyone moved on to utility classes.
BEM is too verbose and difficult to read.
BEM is only good for eliminating CSS specificity.
But if you have problems with CSS specificity you probably can't write CSS in the first place.
TL;DR use Tailwind over BEM
I am a CSS newbie. The way he showed BEM using the $ helped me understand the cascade in CSS. Thanks!
if i wasnt already using React+Styled Components to deal with such issues, this looks like an amazing system to solve such problems in a practical and DX friendly way
I'm not a fan of BEM. I prefer using utility classes instead of --modifier. Most IDE don't have a problem selecting "card-header" on double click, but will struggle with "card__header". Having an arbitrary long class name will also increase file size. We're removing line breaks and spaces on minification, but 30 letters long classes are fine.
Kazu: which IDE? i thought most had a hotkey to select by free text search.
I use vscode and I use cmd+d to select any string by free text search
What do you mean by arbitrarily long? In BEM the idea is you can only have a single level: card__header is ok but card__header__title or card__header__title__icon is banned
@@BenRangel I'm talking about double click text selecting, not hotkey. Some don't see cohesion of a string like "abc--xyz".
Having class="button button--state-success" creates a larger filesize in HTML than class="button success". In CSS it's the same. .button-state-success are more characters than .button.success and therefor results in a larger filesize.
@Angelo Stevens yeah file size is like the last reason i would worry when dealing with BEM and CSS
Why not both? I’ve recently started using a combination of utility classes for shared styles and BEM for unique styling. It seams to be working well so far.
Why can't we consider the list as an individual block and the items as it's element?
You can put the block into another block - it's allowed by convention
But, in this case, what is it? Block or element?
I think everyone pronounces specificity differently lol
I say spaghetti
I don't care if I'm doing large project or small, I always use BEM. (that's different thing I don't get large projects)
It's useless, using SASS is better.
I'm so happy Angular has styles isolation mechanism and I don't need to use BEM anymore :D
Vue has that too. It is so convenient
@Angelo Stevens overkill is a feature not a bug
@@diablo.the.cheater 😂😂
Do you guys mean “scoped”?
Card__content accidentally is not a block?
I really dislike this method because it's very redundant. I don't like this method much because it is overly verbose. I'm not really a fan because with BEM you say the same thing over and over again.
BEM Is trying to solve a problem that doesn't even exist
Te solution is to use the CSS specificity
BEM is like trying to replicate what already exists and works flawlessly
@@christianmartinez2179 I agree. It's not hard to target things specifically. You don't need extra identifiers for that. Using a single "active" class on various elements is, in every single way, superior, to BEM method of having "element" and "element__button" and "element__button.active". In most cases you don't need the element OR the element button class name, but even if you do, you don't need . You can do ALL the same things, the code is FAR more semantic, and you are saving SIGNIFICANT FILE SIZE by having shorter class names! People worry so much about image compression, then they go and make fatass CSS files that are the size of 20 images all in one request because they have 20 extra class names on every rule, they are using duplicated styles for 30 different objects that all have the exact same styles "because BEM" .... and 50,000 styles that aren't used anywhere on the site because of all the hideous frameworks they keep building on top of! Not to mention the extra size in the pages themselves! Everything adds up!
"specifity. I can never say it right. SPECIFITY! there we go!" DEAD xD great video though!!
What's the point of doubling up on the underscores and the hyphens?
Wouldn't card_button-active tell you the same information (what it's for) as card__button--active?
BEM is destroying a concept of the template, prohibiting usage of CSS functions and possibilities, shoving developer to hardcode. Source: hackernoon.com/bem-should-not-exist-6414005765d6
You should probably change the title to "You Probably need BEM CSS in Your Life (if you're using a preprocessor) (Tutorial)". None of this makes sense with vanilla CSS where the same can be accomplished with _a lot_ less verbose class names.
People always do such basic examples lol, the problem with BEM is when you have multiple components, when you got very large complex components and then people get confused as to what is and isn't an element, especially problematic when people use "wrapper" like "card__wrapper" and then underneath that ungodly things like "card__wrapper__image" or just define classes like
"card__wrapper card-wrapper" and then underneath "card-wrapper__image"
Everybody forgetting about that BEM is for auto-generated markup that nobody code by hand. When i see BEM in simple website templates it cause only smile - this dude wasted a LOT of time to do that. Also, in my opinion, the BEM team are snobs who think they have some wonderful knowledge. Fun fact: it took several years to drop the b_ prefix for 'blocks' definition. Everybody can invent own css naming convention. Column width and color classes in Bootstrap (and every other css framework), for example, is modifiers too, so, there is no rocket science at all.
I cannot take the redundancies of BEM. CSS selectors make this possible without re-re-repeating the block name, and re-repeating the element name, just to add a modifier class. Ugh-ly.
I don't see why this is necessary. In your card example, you could use the class name "picture" and target that via CSS with .card > .picture. BEM is just a solution in search of a problem.
i really hate BEM. but thank you, i needed this to pass a front-end coding test
I have used BEM in one previous company project, not a big fan of it. I like modular css/scss much better.
That was clear... but a little bit confusing if we want to use isolated component or block to another block. We can not override style from unrelated block.
for example, we want to use .btn block inside .card block. Let say that the button inside .card block have different style. So how we deal with it?
BEM is great, but please stop using it in combination with CSS modules. Just leave the Block out and name it EM. I see a lot of juniors doing this and it really hurts readability
If you dont know how to use the C in CSS, BEM really shines ;D No, srsly: Dont use BEM, unless you are writing plugins
This is my new favorite channel :-D Thanks for all the great knowledge
Important question. What is that green guitar in the background? Are these EMG pickups?
shouldn't card__item be card__list__item..? it's little confusing when it nested
It’s not so much semantics, it’s modularity of it that’s important.
but the UL could not be considered as a block itself? card-list and the the items, card-list__item?
My underscore is not displaying. When I type underscore it is not displayed instead multiple items get selected.
Anyone has solution?
I spy with my little eye a Kemper Toaster!
How do you name basic website sections with text and image on the right? Just curious
Very very good! was trying to understand this before but only now I understand :)
I’ve been using it just because I saw that JetBrains has it on the webpage. Now I see why I’m doing it
I like the fact that you follow JetBrains :)
Why is that? What's the benefit?
Andi Rady Kurniawan if you’re using scss, which will definitely help you a lot, this Bem makes it easier. You can type .menu and in scss the „&“ character selects it again but you can add something. So for example if you have a list in your menu which has the class „menu__list“ you can just type in the menu css: &__list (.menu__list). And that with several items. It just helps you a lot and organizes everything
Why not just nest in sass and leave out the duplicate text in classes?
Coming from a big project, one important lesson learnt: don't abuse Sass/SCSS, keep it to bare minimum. Reason? Trying to resolve a high priority production defect with a huge SPA codebase, it doesn't help to have .block { ...; &__element{... &--modifier{...}} rulsets: it very hard to find the original rule definition in source code, since in the browser you'll see generated version. The lesson learned, in order to be able to quickly find a rule, write entire selector by hand, don't leave it up to SCSS preprocessor. One thing is to write confusing Sass code to impress junior female developers on your team, and another thing to debug prod issue under pressure and a lot of stress. KISS.
🙏❤️ua-cam.com/video/lmIwYLFYZ9U/v-deo.html❤️🙏
thanks for BEM explanation=))
if we use example .avatar in whole website with 'modifer' ex. .avatar.small how in BEM its looks like? Do I need create so much code for all blocks by separeted, example card__avatar, userslist__avatar, footer__avatar with same code, but in selfs code placed (i cant grab all and display by comma coz its destroy look of code design)? its nonsense in my opinion.
Anyway great video :)
*specificity
ua-cam.com/video/er1JEDuPbZQ/v-deo.html
Great video. Subscribing now
Next episode. Why BEM suck..
Who want to see the studio tour?
I got into TailwindCSS before getting interested in BEM, so I never really ended up needing it. A useful video nonetheless for a quick overview!
@Library Content Yeah, me as well! The nesting of SASS makes it all look very clean and easy to modify.
Tailwind is framework tho, this is just methology
@@Arttyor That's right, but it removes the necessity for using a naming methodology, at least when you follow the similar process that Adam Wathan (Tailwind's author) does.
Why not .card ,, .card > img ,, .card > h2 ,, .card > p ,, .card > a .. ?
i anser my own Q --> becose, card__* is unic for sepcial but the "card > img" is for overall styling
When you will need additional style for particular image .card>img will not allow you to do that due to specifity codepen.io/sashabeep/pen/JjdGWJw
specifity ,there we go ! 9:20. :)
Can this be combined with bootstrap? How?
Thanks pal, what about general approach.
Design Course thank you so much for your amazing tutorials. Your Videos are really unique. I have a question, when a block gets very big(when I start a big project it gets really confusing for me how to break it to smaller blocks and elements. does anybody have any suggestions? Thank you all in advance :)
Thanks for such a helpful video
This video is very helpful especially for me.
Tutorial on time. Thank you Gery Teacher. :)
Terrible. This many underscores...
Thank you so much for this tutorial...
Awesome video as always! Quick question, could the ul be card__content__list? and the li card__content__list__item (modifier as card__content__list_item--active)? Would this make it work better with sass/less. Or could something like this be more oocss or smacss?
If you don't have too many classes I prefer to do "card__list" and "card__list-item". It's shorter and in my opinion it still works quite well.
@@adm7282 yes this is better, because card__item is not so meaningful. Every thing in the card is a card item and is does not explain that it belongs to a list.
9:17
"Spess Ah Fiss It eee"
Say it fast 3 times. ;-)
Be ware of BEM because this is a russian hackers thing from evelCorp YANDEX ! )
i dont really understand, how the selector in css works, when you reference the name just with the the __name, just because its named differently in the html...
oh wait i just scipped the last 20 sec so does that mean, that scss has a build in BEM selector in it, that puts the parent element in front when compiled back to css ?
Thank you for explaining BEM so clearly and succinctly. You got a new sub and I'm looking forward to watching some of the other videos you have.
Annoying intro as always, but very nicely done video after the intro :). Good job!
Yesssss! Finally somebody who I trust covering a topic that seemed to me like a mystery..
I mean seriously.. When I was learning CSS, all that mattered in naming classes was something that was easy for me as a developer.. And then came along BEM, SMACSS, OOCSS and who knows what.. Like wtf.. 😵
Thanks for talking about BEM Gary.. Now how about SMACSS, OOCSS.. 😁
how do you know that name? SMACSS, OOCSS or maybe something thats never exists but actually exists?
@@sugiono2801 Sup man! Well I'd taken a Udemy course by Jonas Schmedtmann named 'Advanced CSS and SASS' course. Within that he mentions of these methodologies for naming the various classes. But he uses the BEM method during the course.
It would be worth noting these methods because recently when I was browsing through job postings on LinkedIn, there are postings where they ask you to have a fair amount of knowledge about a specific method such as BEM.
I once used it but never again. The problem is that you class names become longer and longer and can be simplified with .card.button.active for example.
specificity graph becomes crazy with that
no, you don't. if you use CSS modules (which is what you should be using to write scalable CSS), the scope is always local and specificity issues disappear. look it up!
Solid clear explanation
@10:30 isn't the semantically tied to the card__content div just above it? It's nested inside that div so shouldn't it be card__content__ul? This is confusing
It's very confusing, I don't like BEM personally
Here's the only reason I liked this video :
He directly, simply, clearly explains what is BEM. That it's a methodology and what's its purpose.
It seems all the other guys just start talking and talking as if it's gonna be a philosophical talk. And you don't even have a clue of what BEM is.
There are only one elem of everything...
_ is an underscore. - is a hyphen.
Styled components are the bomb. Svelte and react have completely made BEM obsolete from my life and I love it
Thanks for a great intro to BEM. I used to do HTML/CSS years ago and need to pick it back up at work. These days my company uses BEM and SASS so this was perfect and very easy to follow.
One minor annoyance I have with BEM is that you often get into refactoring discussions in your team as your DOM depth grows. You start out with "card" and "card__header". Later you might need to add a title and an image to the header. But BEM (wisely) forbids nested element-classes like "card__header__title". So then you get into the refactoring debate. Do we do ".card__header .title" or ".card header__title"?
And then you might get into asking yourself why you're even using BEM. You could just do ".card .header .title"
does bem work without sass?
great stuff simon, can you please make a video that explain how to configure php for vsCode, so it can auto complete and other things like the atom built-in feature
Specifity you say? ;D
Great 💡, thanks
I still dont get the point of BEM
Don't do this. Do components.
I use BEM, but one of the things I find the most annoying with it is how absurdly long some class names can get. Especially if you want to toggle a class. Like in your instance if you had a "card__button" and then you wanted to add the "active" class, the two classes alone would be long "card__button card__button--active" now imagine that and pairing it with more classes like for example col-12 col-lg-4 etc. I think the classes just end up looking hella messy after a while.
Thank you so much. I feel like I have been given the secret handshake to the club :)
🙏❤️ua-cam.com/video/lmIwYLFYZ9U/v-deo.html❤️🙏
gonna follow that convention
I dislike classname concatenation like "&__item". I would write the full classname; "card__item". Many new Sass-users fall in love with the idea of concatenating all classnames.
My team used to do that but we decided it makes your code messier in the long run.
A) You can't copy-paste a full classname from your html and search for it in your codebase. You always have to remember that only one part of the classname is searchable.
B) You create a lot of nesting in your code. So when you find "&__item" you always have to look up to see what the full classname actually is.
People will argue that "the advantage is that if you rename 'card' to something else, you just have to change it in one place in your sass file"
But I'd argue this is NOT a major concern. I don't rename stuff that often, and when I do - search-and-replace only takes seconds.
I do however search through and read my code all the time. So anything that increases readability is a more worthwhile investment.
I agree, plus they still need to replace class name in HTML, so will end up using searc-and-replace anyway.
Which css methology do you prefer?
narkar:
I like BEM as long as you’re not being needlessly strict about it and try to shoehorn it into every situation.
We use utility-classes (like ”hidden”) in instances where the same behavior is reused often.
I think it’s insane to use BEM classes for common features like that (for example using card-hidden and article-hidden if they both just set display:none)
mostly use BEM mostly elements with many children. If an elem just has 1-2 children and no deep nesting I avoid BEM. ”article p” is fine.
We use css preprocessor features where we think its most necessary.
We avoid class name concatenation.
But We use variables in cases where it make it more obvious how stuff relates to each other, especially for things like z-indexes. I hate seeing ”z-index: 95” , cause writing ”z:index: $popup-z-index + 1” is so much more understandable.
We use variables to make sure we use standard measurements as often as possible like $padding-mobile and $padding-desktop but if something needs tweaking because of the font used we’re fine with doing an excepting and hard coding a pixel distance.
We don’t use a grid-system for stuff like columns as we do a lot of different layouts for different pages and I think it’s much faster to write custom css for a rare case where we need 5 columns than to use bootstrap’s grid and hack some kind of 5-column-class.
(But if we were building a more simple/cheap site that didn’t have time to do custom layouts we’d probably use more gris-systems)
@@BenRangel That is neat tip for z-index. Thanks.
I like using display: grid for it's autoplacement. I dont use bootstrap's grid at all.
wrong naming. very wrong.
Modify your Blocks and their accompanying Elements... Today!!!
BEMs weakness, if there’s one to be extracted from these comments, is its name. Blocks, elements; most of these people know what those are and that can make it confusing when there are more than 2 nest levels. What I take away from this is that it’s definitely useful if used thoughtfully, when considering the first slides: What blocks on are project are similar in HTML structure but unique in content nature or styling? Card, content, list, these terms are general but if I imagine a blog post preview, album preview, news article preview or rental listing, I can see how BEM would be beneficial. Thank you.
Isn't it SpeciFIcity
i think css is better than this
thank you for the video! will you cover CSS-in-JS sometime soon?