Is my use of BEM naming correct?
BEM stands for Block-Element-Modifier.
A Block is a reusable component.
An Element is a constituent part of said component.
A Modifier is a state of either the component (the Block) or a part of the component (the Element).
Your challenge execution only defines a Block (card
) and Elements (card__img
and card__description
). It does not need Modifiers.
Neither the card__img
nor the card__description
styles can be reused. These styles only make sense within a card
. Hence, they are, correctly, Elements.
Your use of BEM is correct.
I'm unsure on best practices for naming CSS variables. Are there recommended naming conventions?
It depends on the size of the project. In general, I start by grouping colors by hue. Perhaps you may have three different shades of blue and two different shades of green. Instead of naming them --clr-lighter-blue
, --clr-blue
and --clr-darker-blue
, I prefer to give them weights: --clr-blue-300
, --clr-blue-400
, --clr-blue-600
. A higher weight means it is darker, whereas a lower weight means it is lighter. You do not have to use hundreds (you could go for tens) but this is common in the industry, and allows you to come back later and add colors in-between two shades without having to shift and replace all occurrences of a shade (say you come later and then want to add a variant that is between --clr-blue-300
and --clr-blue-400
; it's a breeze. Simply add --clr-blue-350
. If you're using --clr-lighter-blue
and --clr-blue
, you may get away with --clr-light-blue
, but you'll quickly run out of names and eventually get confused about how light or how dark a color is, whereas by numbering, you can match colors better.
What about --clr-primary
, --clr-secondary
, --clr-accent
, etc? These are a little more abstract, since they don't give away what color they actually are. But you can get away with them if your code editor highlights them (VSCode does if you have the colorize
or color highlight
extension). It's ok to have them, but I generally don't find that very useful.
Another approach that I tend to appreciate more is to have the colors grouped by weight as I just showed you and then have them set at component level. In this case, I find that it's ok to use more abstract names, such as -primary
or -secondary
:
.card {
--card-clr-primary: var(--blue-400);
--card-clr-secondary: var(--blue-100);
color: var(--card-clr-primary);
background-color: var(--card-clr-secondary);
}
.card__button--main {
color: var(--card-clr-secondary); /* Invert for high contrast on the main button */
background: var(--card-clr-primary);
}
Is using a CSS reset a best practice regardless of the size of the project?
The advantages generally outweigh the drawbacks. Unless you're aiming for a super compressed CSS for people with limited connectivity (mobile data), using a reset won't harm. It's important that you understand what your reset is doing, though. Most resets set *, *::before, *::after { box-sizing: border-box; }
, for example, which changes how widths are measured for every element.