Author: Jerry Jones

On iOS devices running Safari on version 10+, when focusing a non-native focusable element (ie – a div that is focusable via JavaScript or with a tabindex value) inside an embedded iframe on a page, the parent page will jump down the page and you have to scroll back up to return to the focused element.

To reproduce, it,

1. Use your iOS device on version 10+ and click the slider handle in the embedded quiz.
2. When you click the handle to give it focus, the page will jump down and you’ll have to scroll back up to return to the slider.

This is just a post to explain my bug report to Apple developers and any other devs who may be experiencing a similar issue. For more details, read this Stack Overflow question on this bug.

In WordPress 4.4 they added a big feature: responsive images using srcset and sizes for all content images.

This is amazing. Since WordPress is a hugely popular framework, the amount of bandwidth saved is astronomical. I’m really proud of the WordPress team for implementing this.

But… there are some blurry images. It’s not a perfect one-size fits all solution for every site.

If your images are full screen width, you’ll get a blurry image on wide screens because WordPress is telling your browser to use an image smaller than your browser width. It’s a simple fix, and if you don’t want to read my mini-rant, you can skip to the fix.

The Backwards Way To Fix It

When I was googling to see what others have done to fix this, the only answer I was coming across was to entirely remove the srcset responsive image approach. Go back to a plain ol’ img tag, thank you very much.

I get it. Images are much easier that way. But I don’t think the importance of what srcset accomplishes was understood.

When you use srcset with your image, you provide your browser with a bunch of different versions of your image from small ones to giganto ones. When you go to your site, your browser quickly scans the list of images and picks out the one it needs. That way you don’t download a 2000px wide desktop image onto your phone. You download the 400px one. When you’re paying for your data usage, that’s a big deal.

So, if you’re getting blurry images in WordPress, don’t throw the baby out with the bath water.

The Fix

Here’s a snippet to drop into your functions.php file that will keep the benefits of srcset responsive images and never give you a blurry image. It won’t be a fine-tuned, Italian leather, srcset machine, but it’s far better than axing it entirely.

function osteo_img_sizes($sizes) {
	return '100vw';
}
add_filter( 'wp_calculate_image_sizes', 'osteo_img_sizes');

This filter overrides WordPress’s default sizes attribute to tell your browser, “Don’t serve images larger than the screen width.” VW here stands for viewport width (your browser width).

That’s it. It’s not perfect, but it serves the people that need it most: people on mobile devices with a slow and/or costly connection.

BEM can get out of control if you’re not careful. On the first project I used BEM, I handcrafted this artisanal class name: .progress__bar__question-count__current-number.

Yup. That’s four levels deep. I’m not proud of this.

The goal of this article is to make sure another .progress__bar__question-count__current-number never gets written. Before we dive in, if you’re not familiar with the BEM naming convention, head over to B is for Block: An Intro to the BEM Naming Convention. Don’t worry, I’ll wait until you’re done.

Ready? Good. Here we go!

It’s BEM, not BEEEEM

Be as descriptive as you need to be with your BEM class names to avoid duplication and confusion. Sure, my .progress__bar__question-count__current-number class lets me know that current-number is nested 4 levels deep in the HTML, but is that worth the verbosity?

Nope.

It means more changes to make in your CSS when you modify the HTML. Rather than duplicate your HTML structure, be descriptive and unique.

When I refactor, .progress__bar__question-count__current-number will become .progress-bar__current-number.

Ah. Much better.

“The best is the enemy of the good.” – Voltaire

I can get stuck in a pattern of trying to find the perfect solution rather than an easy one that accomplishes the task. As the saying goes, “Don’t let perfect be the enemy of good.” That’s when .progress__bar__question-count__current-number rears its ugly head.

Remember, BEM is a convention to make your code easier to maintain. If it’s not making your code easier to maintain, modify it. BEM is a tool for you to use, not vice-versa.

If a Block is Within Another Block, Mix It

One of the great things about BEM is the flat class structure. You don’t have to nest anything in SASS or use multiple class names to win a specificity battle.

That’s great… until a block is nested inside another block. Let’s say you have a .card block that has a .list and a .button inside it. What do you do? Do you duplicate the entire block again with the block name prefixed? That’s the only way to keep it 100% perfect and flat. So, should we do this?

<article class='card'>
  <div class='card__header'>
    <h2 class='card__title'>B is for Block: How to BEM</h2>
  </div>
  <div class='card__content'>
    <ol class='list card__list'>
      <li class='list__item card__list__item'>
        Describe the Main Block with a word or two.
      </li>
    </ol>
    <a class='button button--with-icon card__button card__button--button-with-icon'>
      <span class='button__text card__button__text'>
        Read More
      </span>
    </a>
  </div>
</article>

No! Don’t put BEM in your BEM. That’s what leads you down the crooked path to .progress__bar__question-count__current-number! Heed my warning. Don’t do it. Nest the components, but mix the class names, and let your specificity win out with the nested class names. Like this:

<article class='card'>
  <div class='card__header'>
    <h2 class='card__title'>B is for Block: How to BEM</h2>
  </div>
  <div class='card__content'>
    <ol class='list card__list'>
      <li class='list__item'>
        Describe the Main Block with a word or two.
      <li>
    </ol>
    <a class='button button--with-icon card__button'>
      <span class='button__text'>
        Read More
      </span>
    </a>
  </div>
</article>

Here’s the above example in a CodePen that highlights the components and displays the class names that go with it:

See the Pen BEM Syntax Visualized by Jerry Jones (@jeryj) on CodePen.

//assets.codepen.io/assets/embed/ei.js

You might encounter a time where it’s helpful to put your BEM in your BEM a little bit, but be careful with it. Remember, BEM is supposed to be helpful to you and your team. Feel free to “modify” it.

See what I did there?

Blocks Don’t Care About Other Blocks… Until They Move In

You have a .friend. They’re a good .friend, but sometimes they do things you don’t agree with. Nothing wrong with that.

You have .your-house. You like your .friend and .your-house doesn’t care about what your .friend does. They can go wherever they want. Do what they want to do.

Until your .friend gets kicked out. They need a place to stay.

Enter, .your-house. But when your .friend is living with you, they’re going to need to follow your rules. .friend has to realize that now, they’re also .your-house__friend.

// home sweet home!
.your-house {
    laundry: clean;
    dishes: clean;
}

// do what you want! be you!
.friend {
    laundry: dirty;
    dishes: dirty;
    goes-out: tons;
    pays-rent: nope;
    demeanor: nice;
    fun: yes;
}

// Uh oh. Gotta set some rules while
// they're living in your house
.your-house__friend {
    laundry: clean;
    dishes: clean;
    pays-rent: yes;
}

Blocks don’t care about other blocks. That’s what makes them maintainable and predictable. When you put a block inside another block, the parent block is the one that cares. .friend doesn’t care that it’s in .your-house. .your-house is the one that cares, so it sets the rules on .your-house__friend.

Be a good .friend and keep .your-house class names tidy.

The BEM Cheatsheet

Here’s the cheatsheet of the tips for actually using BEM.

1. Formatting: .block__element--modifier
2. Describe the block with a word or two. If it’s two words, separate them with just one dash or do camelCase or whatever. Doesn’t really matter. Just be consistent and document it.
3. Describe the __element with a word or two.
4. Add --modifiers if necessary.
5. Avoid lots of __elements unless you can’t avoid it. For example, .card__title__link__progress__icon is a little excessive.
6. You can mix classnames that are parts of two blocks. For example, if it’s a .button block, but it’s also a .card__button element, you can use both in the HTML.

That’s it. You should know enough to confidently use BEM and avoid common traps. You’ll still come across scenarios that you’re not sure what to do. We all do. If you have any questions or think I made a mistake, let me know at @juryjowns.

What’s the big deal, just name it the first thing that makes sense, right? It makes sense now, so it will probably always make sense! .btn--small, .btn--tiny, .btn--really-tiny, umm… .btn--really-super-duper-tiny!

Considering your class names avoids headaches and confusion down the road. But that’s easier said than done. Before we figure that out, let’s get some basics down.

Formatting Your Class Names

There’s lots of different naming conventions out there. I use BEM. If you’re not familiar with BEM naming, you’ll still get the gist of this article. If you want to learn about BEM, read this intro to BEM.

I tend to use dashes to separate words in my class names. Use one or two words when you’re naming each component. It’s better to be long-winded and understood than terse and confusing.

If you’re using BEM, as long as you reserve __ for separating blocks from elements and -- for modifiers, you’ll probably be OK. Whatever you do, be consistent and make sure you document it so other people know what convention to follow.

// examples for naming classes
// This is using BEM: Crash course!
// .main-nav is the main block
// .main-nav__link is an element inside of .main-nav
// .main-nav__link--current-page is modifying .main-nav__link

// Dashes to separate words
.main-nav__link--current-page {
  color: blue;
}
// or camelCase
.mainNav__link--currentPage {
  color: blue;
}
// or Capitalize the first word of each element
.Main-nav__Link--Current-page {
  color: blue;
}
// or...  sure... FART separators... 
// I guess... as long as it's consistent...
.mainFARTnav__link--currentFARTpage {
  color: blue;
}

Avoid Using Visual Descriptors in Your Class Names

Avoid using visual descriptions, because they may not always look that way. The designer might change the size of the h2 of the component, and all of a sudden that .small-header class doesn’t make sense. Or, it can change sizes across media queries or colors across states.

For example:

.big-blue-button {
  background: blue;
  color: white;
  font-size: 40px;
  padding: 20px 40px;
}

// a screen less than or equal to 640px wide
@media (max-width: 640px) {
  // not so big anymore...
  .big-blue-button {
    font-size: 14px;
    padding: 8px 12px;
  }
}

// not so blue anymore...
.footer .big-blue-button {
  background: red;
}

It’s better to name it as generically as you can for the component, while still communicating something specific. Using generic names means when the design team changes the color of the .big-blue-button to red, you don’t have to rename your HTML too.

Like, What is Your Component at Its Core, Dude?

Here’s how you can rework the same component using BEM, and thinking through it a little.

What’s our main component, at its core. Like, who is it, really, like, really meant to be, duuude?

.big-blue-button, after climbing to the top of Mount Everest on an intense soul-searching journey, realized it was really a .button in its heart.

“But, you’re not just any .button,” we cry out! “You’re a big one! And a blue one!”

For now at least. How can we signify that?

Well, why is it big and blue? Because we want people using the website to see it, right? It needs to stand out.

When would we be using it? When we really want people to click it, probably. Don’t focus on its looks. Like, stop being so vain and stuff. Instead, let’s focus on when and why we use it.

The .button formerly known as .big-blue-button, I now knight you .button--call-to-action!

By focusing on the reason and meaning of the button, we’ve found a class name that can stand up to design changes. And, as a bonus, if you can’t figure out a good name for it based on its meaning and purpose, there’s a good chance you don’t need it at all.

Without further ado, let’s see some reworked CSS using our new class names.

// main block
.button {
  background: blue;
  color: white;
  font-size: 16px;
  padding: 8px 16px;
}

// modify your block
.button--call-to-action {
  font-size: 40px;
  padding: 20px 40px;
}

@media (max-width: 640px) {
  // it's still a call to action,
  // even if it's small
  .button--call-to-action {
    font-size: 14px;
  }
}

// it all still makes sense!
.footer .button--call-to-action {
  background: red;
}

Things just make sense now, ya dig?

By staying consistent and considering the purpose of our components instead of how they look, we have modular class names that will stand the test of time.

Do you have any tips or something I overlooked? Let me know on Twitter or in the comments.

BEM (Block, Element, Modifier) is a great way to keep class naming consistent and meaningful. If you’ve never used BEM before but want to understand how it works, or if you’re thinking about using it for an upcoming site or component, this article is meant for you.

If you’re already familiar with how BEM works, I’m writing another article focused on more use cases and examples. Follow me on Twitter and you’ll know when it’s out.

Intro to BEM

BEM is extremely helpful for building maintainable components that communicate the relationship between elements. Let’s learn by example and build a fake button component first.

B is for Block: This is the name of our main component. In our case, it’s a .button.

// Our Block!
.button {
  padding: .6rem 1.2rem;
  color: white;
  background: black;
}

E is for Element: This is something that’s dependent upon being inside of the main block and is indicated that it’s an element by using two underscores (__) to separate it from the main Block name.

// an icon element
.button__icon {
  fill: white;
}

// the text of the button
.button__text {
  margin-right: 5px;
}

Just from the CSS, if you’re familiar with BEM, you can tell what CSS depends on each other and what the HTML will look like. The .button__text and .button__icon elements will both be nested inside the .button block.

Here’s what our HTML would look like:

<button class="button">
    <span class="button__text">Read More</span>
    <svg class="button__icon">
        <use xlink:href="#icon-chevron--right" />
    </svg>
</button>

We have our main .button block and the elements inside of it (.button__text and .button__icon). BEM has given us some structure to see how the CSS is related, as well as how the HTML might be structured. Pretty helpful stuff.

M is for Modifier: What if you want your button to be blue instead of black? No need to build a whole new component! Just add a modifier.

<button class="button button--blue">
    ...
</button>

// Our Block!
.button {
  padding: .6rem 1.2rem;
  color: white;
  background: black;
}

// our modifier!
.button--blue {
  background: blue;
}

Because we’re using BEM naming conventions, we know that .button--blue depends upon (inherits) the styles from .button. When we make an edit to .button, we know it will affect .button--blue. Conversely, when we make an edit to .button--blue, we know it won’t affect .button.

That’s the basics on how to use BEM. Really, that’s it. It’s helpful to use in any size project.

Applying it in an actual site is a whole different beast though. That’s why I’m working on another article about how I’ve used BEM in complex cases to keep it helpful instead of a hinderance.

The BEM Cheatsheet

Here’s a quick cheatsheet of the tips for actually using BEM.

1. Formatting: .block__element--modifier
2. Describe the block with a word or two. If it’s two words, separate them with just one dash or do camelCase or whatever. Doesn’t really matter. Just be consistent and document it.
3. Describe the __element with a word or two.
4. Add --modifiers if necessary.
5. Discussed in the upcoming article: Avoid lots of __elements unless you can’t avoid it. For example, .card__title__link__progress__icon is a little excessive.
6. Discussed in the upcoming article: You can mix classnames that are parts of two blocks. For example, if it’s a .button block, but it’s also a .card__button element, you can use both in the HTML.

That’s the Basics: Next Steps

There’s plenty more to class names than using BEM though. I have some tips on how to create class names that are descriptive, useful, and modular, and why that’s so important.

Connect with me on Twitter to get alerted when the next article is posted. Until then, if you want to take a deep dive into BEM, @StuRobson has a big ol’ list of BEM Resources.