Now that we’ve nailed down our basic units, we’ll get started on our basic blog post page. It’s a fairly standard holy grail style layout.

Let’s write out the markup and CSS while following some conventions:

All component-level styling should use class name selectors.

Page layout-styling should only use IDs. This means that unique entities on a page will also be given specific IDs that our CSS will use to define their sizing and positioning (and in some cases their visibility).

Follow a naming convention. I prefer BEM. BEMIT is too lengthy for my taste, and the use of IDs and class names described above reduces the need for prefixes. In reality, any naming convention will do as long as you stick with one.

Alphabetical order is better than non-alphabetical order.

Avoid deeply nesting elements for the sake of convenience when positioning elements with CSS.

No “master” stylesheets. Every CSS file is dedicated to a limited scope.

Semantic HTML is a good thing.

Look what we’ve ended up with:

NOTE: Go here to view the page in full so you can properly test its responsiveness.

It’s not the prettiest thing in the world, but it’ll do for this example. In only a few hundred lines of CSS and HTML, we have workable blog page in front of us.

As you can see, I’ve kept layout and component styling separated from each other. ID selectors in app/styles/article.css only define positioning and visibility. This stylesheet for the page has no knowledge of the internals of the components being used.

The components of the page “snap” to each distinct screen width that we’ve defined. The breakpoints used to determine where this sizing happens includes our screen width variables as well as two margins (15px), one for each side of the screen, which prevents the content from touching the edge of the screen and leaves enough room for the scrollbar.

There is a potential problem, however…

What do you do when the children of a component need to be responsive?

It’s trickier to get right than it first seems. Components can certainly use their own breakpoints to react to screen width, but screen width alone is often not enough because the size of a parent container/element often matters.

Sadly, CSS is crippled in that there’s no way to query the size of a parent element. Such a feature would solve a lot of problems in page design. We might not always want a component to respond to screen width the same way on different pages, but we also don’t want the inner workings of a component to get tangled in the page layout styling. In my opinion.

Fortunately, it’s 2018, and we have tools we can use to work around such issues without needing JavaScript shims. I’m talking about CSS preprocessors such as Sass, LESS, and Stylus. In essence, these are alternative stylesheet languages that introduce helpful features such as variables, mixins, functions, and many other features of general purpose programming languages. A preprocessor will compile to CSS and allow you to build more complicated styling with fewer lines of code.

To get around the problem of component-child responsiveness, I prefer to use Sass to give each component a standard set of mixins that the page layout can include where needed.

Say, for example, we want our body component to place the headline underneath the lead image on mobile screen sizes; how might we do this without the layout styles requiring specific knowledge of the child elements of the body component?

Let’s revise our blog page styling using the “SCSS” flavor of Sass:

Link to CodePen: https://codepen.io/Ravenstine/pen/xpYoWv

You’ll notice that to change how the body component displays its children on mobile screens, I’ve created a Sass mixin called prose — sm, which defines how our prose element should be styled on small screens. That mixin can then be selectively included in #article__body media queries through our layout styling. This is how we are able to move the headline below the lead image at a certain breakpoint. Writing mixins for components with a standard naming convention (in this case <component name> — <screen size> allows us to define different component states and use them selectively in the page layout without entangling the layout and component styling. To a programmer, the mixins become your public API to each component.

Yes, we could certainly have achieved the same thing without Sass by making the assumption that we’ll always use the same media breakpoints throughout our site, and using media queries with those breakpoints directly in our component style sheets. It’s viable to do this and there’s nothing wrong with it.

But relying solely on your media queries can become a headache when you need your component to have unique behaviors on different pages at the same screen sizes. There are creative ways around this, but I consider the approach of using Sass mixins to be the most feasible because it not only allows component styling and behavior to be easily altered wherever and whenever we want, but it means we only have to write one set of media queries per page layout; there’s no need to define the same media query in various places, which can cause unexpected page resizing glitches if you’re not careful enough. A component can have an indefinite amount of states, and they have complete ownership of their internal layout at all times.