QR code component (CSS variables, BEM)

Community feedback

• 

  Daniel•100

  @dnoracPosted almost 2 years ago

  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.

  Marked as helpful

  1

  ---

  

  Aaron•110

  @ag7621Posted almost 2 years ago

  @niftydan

  Thank you for the feedback on my challenge, as well as the insights on the CSS reset and variables. I hadn't thought to use 2 layers of naming as is in your example. As a follow up question, would you have the component level grouping in the root section as well, or alongside the class in the css file?

  Thank you again for the feedback! I'll be looking into more how the reset works, as well as practicing new variable naming.

  0