Build Your First: HTML & CSS

Loading the player…


Transcript

Introduction to moving away full page layouts:

Welcome to Lesson 1. This lesson is all about exploring new methodologies. The first thing we’re going to look at is a trend of moving away from pages. A few years ago, many front end developers approached websites and web applications as a series of pages. Now these pages were often designed and built as complete entities. Now this meant that the page components were often closely tied to their relevant pages. More recently, the focus has shifted from full page layouts to re-usable modules. And a reusable module could be a layout grid structure, a button, an input, or even something like a pull-quote. HTML/CSS pattern libraries are used to define commonly used interface modules. Now these modules are created as HTML and CSS code and then documented, so they can easily be re-used as needed. We’re going to use this reasonable modules principal to create our own minipattern library. And the process involves first of all, looking for modules that may be repeated within the layout. And then two, define their characteristics. Three, define class names for them. And then four, create the HTML and CSS patterns for those particular modules.

Introduction to CSS class naming conventions:

A critical component of this is class names. Now ideally, we want to use a naming convention that will make our class names easier to write during development as well as easy to understand when maintaining the site in the future. In the following example, we have a challenge. How can we let other team members know that all of the other classes relate to the primary callout-box class? See here’s our marker. And as you can see we have a class called callout-box. Now, we could use a name and convention that was originally defined as part of BEM, or block, element, module. This was then extended by Nicolas Gallagher, and then modified slightly again by Harry Roberts. The core principles are that class name should be. First of all, it should be consistent. Is there a consistent methodology? Can we se how they relate? And are they recognizable? Do we understand the purpose of those classes? Well let’s take a look at modules.

CSS class patterns – Modules:

The primary class for any pattern is called a module. When creating CSS class names, I try to avoid CamelCase, to make class names as easy to read as possible. Multiple words are joined with a single hyphen. So here we have an example of calloutBox written in CamelCase, or callout-box written with a hyphen. So there would be our first class callout dash box. Now let’s look at module modifiers.

CSS class patterns – Module Modifiers:

If a module needs to be modified or extended, a module modifier would be used. Now because we’re using single hyphens for our module class names, we’re going to differentiate our modifier class names by using two hyphens. So our module would be module dash name, and our modifier would be module dash name, dash dash modifier dash name. Now you don’t have to use this naming convention, but I found it much easier to be able to distinguish different types of classes. And so here we’d have callout-box. And down below you’ll see another one which is modified call-out-box, — help.

CSS class patterns – Module Descendants:

Next up let’s look at module descendants. If a module has child elements that need to be styled, a module descendant could be used. We could use two underscores to make it clear that this is a descendant class. And so we have module-name, module-name-, dash modifier-name, and then our descendant would be module-name, __descendant-name. And you can see here it becomes very quick and easy to see that these are descendants of the callout-box. But why use class names for descendant elements when we could use descendant selectors instead? So we could do something like module-name and then h3, which we’ll style in the h3 inside the module of module-name. However if we use descendant selectors, we’re relying on the HTML remaining the same, which may not be the case. Using class names gives us greater stability and flexibility. Now Jonathan Snook calls this decoupling the HTML and CSS. What about going further?

Extending CSS naming conventions:

Now this basic naming convention can be extended to descendant modifiers as well, though these types of class names would rarely be needed. So you could end up having something like module-name, and then descendant name and then modifier name. Now again, very rarely I need to use these types of class names. Now you could also create class names that are descendants of descendants, but I find this becomes too complex and too confusing. So you might end up with something like callout-box_content and then callout-box_content_heading. For really complex modules, it may be much easier to break them down into smaller modules so that naming conventions can remain simple. So that’s our quick review. We now have a clear hierarchy of class names that should allow developers to quickly understand their relationship. We have our module, in this case callout-box. We our modifier with –help, and we have descendants with __heading and __content.

Introduction class names used in the course website:

Let’s have a quick look at the class that we’re actually going to be using in our lessons. First of all, we have a header module. And as you can see,we have a range of descendants, which are the logo, nav, nav-about, and nav-contact. Then we have our banner-content module, and you can see we have __heading. We have a features module, and this one has row, padding, heading, text, bike, phone, and safe. We have testimonials, and we have heading, quote, and source. Now here’s an example under our facts, where because it’s so complicated we could have written descendant descendants, but it’s much easier to break them up a bit. So I’ve broken them up into facts-intro, and facts-list. Next up is press and you can see we have descendence of headings and logo. And then you see, we have some extensions or modifiers for the logos. So we have bevel, nc, solvable and waratah. Next up footer and we have a range of descendants including copyright, cta, info and logo. Now for rows we have the row, our primary module. And then we have some color modifiers. So instead of descendants, these are modifiers, so we have -. So white, blue, dark grey and grey. We also have some padding modifiers. So we’ve got –padding-medium and –padding-wide. And then we have a special modifier which is –banner. Now there are a couple of places where there is no primary modules, just a series of options. And a classic example of this is container. There is no default container to modify. So we’re just going for container-narrow, container-medium and container-wide. Similarly with our columns, we have col narrow, medium and wide. But we do have two modifiers. We have col-narrow–right and col-wide–right. Now there are also a few small areas where I have broken my own rule and used some descendant selectors. And you can see here, we have header__nav. And then, instead of going deeper, I’ve just then included a descendant selector for ul, li, and a. Now these could be done as their own classes, but because they’re pretty unique, I didn’t find that I really needed to do that. Similarly, for footer, we’ve got footer__info. And we have two descendent selectors, ul and a. And then finally, footer__copyright. And then, li. Now despite these examples, almost all of our CSS contains class name selectors without descendant selectors. Now, this makes it more efficient for browsers, and easier for maintenance.

GitHub Repo

  • Aswin Koliyot

    Thanks for the excellent tutorial, Russ. I just finished the whole thing and I have a doubt.

    You named the class for the navigation buttons under header__nav as follows:
    header__nav-about
    header__nav-contact

    and under press__logos you have
    press__logos–bevel
    press__logos–nc
    press__logos–solvable
    press__logos–waratah

    I’m confused about the usage of single hyphen in the first case and double in the second.