Scott's Recipes Logo

Working the hotrails.dev tutorial - Chapter 2 CSS

As noted in part 1 of this blog series, I am working thru the HotRails.dev tutorial and building a set of personal notes.

Note: Don’t read this; this is my learning notes. Go read HotRails.dev which is an ASTONISHINGLY GOOD, FANTASTIC, WONDERFUL tutorial. Seriously. Go there NOW and stop reading this.

Note: There’s going to be more verbatim copying from the tutorial here because I’m particularly weak on CSS and I’ve been hugely corrupted by Tailwind.

Notes on Chapter 2 — CSS Stuff

BEM Methodology - BEM is a front-end naming method for organizing and naming CSS classes. The Block, Element, Modifier methodology is a popular naming convention for class names in HTML and CSS. It helps to write clean CSS by following some simple rules.

From the tutorial:

  1. Each component (or block) should have a unique name. Let’s imagine a card component in our application. The .card CSS class should be defined in the card.scss file and its name should be unique. That’s the letter B in “BEM”, and it stands for block.
  2. Each block can have many elements. If we take back our card example, each card may have a title and a body. In BEM we will name the corresponding CSS classes .card__title and .card__body. We ensure that naming conflicts are not possible by prefixing the element’s name with the block’s name. If we have another block .box with a title and a body, .box__title and .box__body won’t conflict with .card__title and .card__body thus making sure there won’t be any conflicts between those classes. That’s the letter E in “BEM”, and it stands for element.
  3. Each block may have modifiers. If we take back our card example, maybe they can have different colors. The names of the modifiers could be .card–primary and .card–secondary. That’s the letter M in “BEM”, and it stands for modifiers.

This solves CSS naming conflicts.

CSS Organization

Our app/assets/stylesheets/ folder will contain four elements:

Components are independent pieces of the web page. They should not be concerned about how they are laid out on the page but only their style. An excellent example of a component is a button. Buttons don’t know where they will be placed on the page.

A layout, on the contrary, does not add style. It is only concerned about margins, centering, or anything that helps us position components relative to one another. A good example of a layout is a container that will center the content on the page.

Components are ONLY concerned about themselves so they don’t have outer margins.

Layouts provide the context where individual components will be used.

But … in this tutorial, we will break this rule. We will add margins directly on the components themselves. For example, the .quote CSS class will have a bottom margin. In real life, we might want to delegate this responsibility to a margin utility or a .stack layout to make it easier to reuse the .quote component in other contexts.

Note that with Sass, the & sign corresponds to the selector in which the & is directly nested. In our case &:hover, will be translated by Sass to .btn:hover in CSS. (see _btn.scss for a specific example of this).

Commands

mkdir app/assets/stylesheets/mixins

mkdir app/assets/stylesheets/config

mkdir app/assets/stylesheets/components

mkdir app/assets/stylesheets/layouts

touch app/assets/stylesheets/mixins/_media.scss

touch app/assets/stylesheets/config/_variables.scss

touch app/assets/stylesheets/config/_reset.scss

touch app/assets/stylesheets/components/_btn.scss

touch app/assets/stylesheets/components/_meal.scss

touch app/assets/stylesheets/components/_form.scss

touch app/assets/stylesheets/components/_visually_hidden.scss

touch app/assets/stylesheets/components/_error_message.scss

touch app/assets/stylesheets/layouts/_container.scss

touch app/assets/stylesheets/layouts/_header.scss