An inline-block intervention

Tell me the last time you used a <b> element in your markup. How about a <blink> tag?

If you answered ‘today’, then this post will hopefully be eye opening for you. However, if you answered, “pffft, I don’t. I write semantic markup”, then this post is geared towards you.

So, the reason why we don’t use the <b> tag for bolded text is because we’re interested in the separation of content and style. A <b> element describes our content as bold, but in accessibility and semantic terms, bold is a presentational term. A better candidate is the <strong> element, and font-weight to achieve the stylistic look we want.

Cool? We write HTML with the semantic content in mind. Any presentational, or visual look, is achieved via CSS. HTML simply describes our content.

So let’s talk about inline-block

inline-block entered the web dev scene around 2008 as part of CSS2.1 and everyone loved it. Heck, I love it. I just don’t use it for layout. I’ve been doing web-dev for almost 15 years now, and when inline-block rolled around as a new display value, I was stoked.

What inline-block does is provide inline positioning of an element, much like a span, em, strong or a element, but also allows widths and dimensions to be applied to it. Great for transforming <a> elements into buttons.

So somewhere along the way, someone decided, “hey, I don’t need floats, I can just set my elements to display:inline-block”, and the web-dev community shouted, “Yes”.

Except one little problem exists. Inline-block is whitespace dependent.

What that means is that it acts just like a span, em, strong or a element would and reacts to whitespace next to it.

Removing whitespace next to an inline-block element

So here’s where inline-block bothers me. The markup is defining the presentation. Sure, there are tricks with CSS to remove the whitespace, but they are just tricks like the clearfix trick on floats (more about that later).

Thinking about semantic markup, by removing the whitespace next to the inline-block element above, the content is now “I’minline blocktext”. Not exactly semantic.

Let’s review some inline-block fixes

For these examples, I’ll use five divs on a page to achieve an example of layout.

Our basic layout for the next few examples

Fix #1 — Font Size: 0 on the parent.

Since inline-block is whitespace dependent, the line breaks in our code act as whitespace and push our elements apart. One of the fixes is to set a font-size of zero on the parent, and reset the font-size on the element itself. This removes the surrounding whitespace.

The font-size trick

So first things first, this is very destructive as we are not keeping our code DRY, as well, we are accepting that our content has defined our style.

Fix #2 — Remove whitespace from our code.

Another trick is to change our markup. By simply removing the whitespace and linebreaks in our markup, we can remove the spacing between the elements.

Removing whitespace in markup fix

Really though?! You would rather have shitty looking code just to solve an issue that you shouldn’t have in the first place? Also, can you guarantee that the server you render the site on isn’t going to add the line breaks in? What if you like the spacing, and the server minifies it? Not really a viable solution. Our content is defining the presentation.

Fix #3 — Removing the closing element.

Ugh. I can’t believe this is actually a thing. While HTML5 doesn’t care and will do it’s best to close elements for you, PLEASE DON’T DO THIS.

Removing the closing tag because we hate writing nice code.

By removing the closing tag of each element, the whitespace is removed. But holy shit this is bad. We want to write correct markup, not hacky stuff.

I do love inline-block though

This is not me ripping on inline-block in general though. I just don’t believe it’s a ‘better’ way to do layout. In fact, the most promising way to do layout is with flexbox.

Inline-block is useful, but more likely for making an a element look more like a button. I use it often for typographical element styling, as what it’s purpose is.

The computed output of an inline-block element is a block-level element in the end. However, it takes into account the surrounding content.

However for layout, I’m still using floats. Why? Float’s are not affected as content as drastically as inline-block elements are. Sure, they weren’t designed for structural layout, but neither was inline-block. However, the power of floats and their native characteristics far outweigh inline-block.

Floats are used together with block-level elements and widths to create structural elements. Think of these floated elements like bricks in a wall.

A wall can’t be built upwards without a foundation. By floating elements next to each other, we are building a foundation for the rest of our content. Floating elements simply provides us the tools to move our content blocks around in regards to other structural elements.

I wholeheartedly endorse the use of inline-block AND floats though for layout.

Inline-block is fantastic for creating block-level elements that don’t require defined widths. Once we have a block-level element, using floats to bring them together is simple. No whitespace whatsoever. No silly hacks.

But, clearfix!

Ya, the clearfix. The class we apply to the parent container of our floated elements to stop it from ‘collapsing’.

This thing.

.clearfix:after {
  visibility: hidden;
  display: block;
  content: " ";
  height: 0;
  font-size: 0;
  clear: both
}

So let’s break this down.

1. The class name: clearfix. Nothing. It’s a name.
2. :after. A pseudo element. The virtual last child of an element
3. visibility:hidden and display: block. Put a block element on the page and hide it.
4. content: “ “. Fill our :after element with no content. Necessary.
5. height: 0 and font-size: 0. Our after element has no computed dimensions.
6. clear: both. The magic.

The clear property defines whether or not, elements that succeed floated elements, are floated, or moved underneath.

Applying a clear both to the :after element, something that is visually not on the page, and not treated as content is non-damaging to our markup.

If floats and clearfix are the reason why display:inline-block is your method of layout, I hope that simply knowing that the your content is affecting the presentational style is enough to have you reconsider.

Five inline-blocks set to 20% each does not equal 100%. It equals 100% plus the whitespace between. Simply float the elements left and the whitespace is removed, and dimensions make sense again.

In line with teaching my students about the separation of content and style, inline-block can be detrimental to the understanding of content-flow and organization. Using floats displays an understanding of organization and design.

“Yeah, yeah, but your scientists were so preoccupied with whether or not they could that they didn’t stop to think if they should.”

Dr Ian Malcolm, Jurassic Park

Thank you mr @wesbos for this quote

Just because something doesn’t make as much sense as another option, doesn’t negate it’s value. We tend to take for granted the tools available to us in web dev, and introduce trivial concepts such as negative margins, repeated code and poor markup in an effort to justify an easier method.

Personally, if everything was super easy, I’d be pretty bored. I mean, have you looked at the flexbox spec? Floats and clearing have got nothing on that monster.