We expect a line to break when the text on that line reaches the parent box boundaries. We see this every time we create a paragraph, just like this one. When the parent box doesn’t have enough room for the next word in a line, it breaks it and moves down to the next line and repeats that process.

Well, that’s how it works when words are separated by spaces or other whitespace. As far as CSS goes, there are five (!) properties that can possibly affect how and when a line breaks. Let’s not get into all that again though. Let’s instead look at a situation where it seems like a line is going to break but it doesn’t as an excuse to learn a little something about line breaking.

What happens in a situation where there is no way for the browser to know when it’s OK to make a break?

Let’s get ourselves into a bad situation with a “tag list” and then get ourselves out of it. Here’s our markup:

<ul>
  <li>PHP</li>
  <li>JavaScript</li>
  <li>Rust</li>
  <!-- etc. -->
</ul>

Next, we’ll apply CSS that overwrites the default list style from its default vertical orientation to horizontal by making the list items display inline.

ul {
  margin: 0;
  padding: 0;
  list-style: none;
}


li {
  display: inline;
  padding-right: 5px;
}

The list looks just like we want it. I added a little bit of space between one list item and another, so it doesn’t look too crowded.

Now let’s introduce a wrapper element to the mix. That’s essentially a div around the unordered list. We can give it a class, say, .tags.

<div class="tags">
  <ul>
    <li>PHP</li>
    <li>JavaScript</li>
    <li>Rust</li>
  </ul>
</div>

Let’s say we want to give the wrapper a fixed width of 200px. That’s where we should expect to see line breaks happen as the unordered list bumps into wrapper’s boundaries.

.tags {
  width: 200px;
}

Here comes the interesting part. Many people use minifiers in their build process to reduce file sizes by getting rid of unnecessary values. Some of these values are whitespaces, which includes spaces, tabs, and line breaks (such as carriage return and line feed) characters that are use for formatting purposes but considered by minifies to be irrelevant to the final result.

If we “minify” our HTML by removing new lines, then this is what we get:

<div class="tags"><ul><li>PHP</li><li>JavaScript</li><li>Rust</li></ul></div>

UH OH. As you can see, the list is not breaking at the 200px boundary anymore. Why? What is different now? Personally, I thought HTML didn’t care about whitespaces. What is so different about the minified version from the original markup?

The browser does actually care about whitespaces… but only sometimes. And this just so happens to be one of those instances. When the page is being parsed, the parser sees this list as one long word because, from its perspective, there are no characters that differentiate one from the other.

One might think having the padding is affecting things. But if we remove the padding from our list items we still get the same result… only with no spacing between items.

The browser sees the entire list as a single word.

We can get natural line breaks from special characters

Besides spaces, excluding non-breaking spaces (&nbsp;), there are some other characters that will force a line break, including:

• After hyphen (-)
• After en dash (–)
• Before and after em dash (—)
• After question mark (?)
• Zero-width white space (U+200B or ​)

These line breaks happen at rendering time which means the browser still sees this as one long word. Adding a new list item to the tag list with any of these characters will force a line break. Let’s add “Objective-C” to the list. Its name contains a hyphen, which we can use to see how it affects things.

For better readability purpose the code code will have indentation and new line.

<div class="tags">
  <ul>
    <li>PHP</li>
    <li>JavaScript</li>
    <li>Rust</li>
    <li>Objective-C</li>
  </ul>
</div>

That’s good. Let’s look at three solutions to our non-line-breaking list along these lines.

Solution 1: Add one of the breaking characters

We can keep forcing line breaks with those breaking characters like we just did. But remember, if you are using a minifier, adding the spaces in or after the closing tag won’t guaranteed it won’t be removed, as not all minifiers work the same way.

<div class="tags">
  <ul>
    <li>PHP </li>
    <li>JavaScript </li>
    <li>Rust </li>
    <li>Objective-C </li>
  </ul>
</div>

Solution 2: Use pseudo-elements

The breaking character can also be added using the ::before and ::after pseudo-elements in CSS. What makes this solution effective is that it’s not affected by an HTML minifier because the whitespace is added when the CSS is applied.

But, before we move on, let’s talk a moment about collapsing whitespaces.

The browser collapses whitespace before and after a character that forces a line break inside inline elements. With this in mind, there’s a little trick to using ::after and the content property with whitespacing and display: inline-block. The inline-block element adds a breaking character at the end of the text. Then the content property space comes after the breaking character created by the inline-block element, which results in the space being removed at rendering time. That is, unless the white-space property is set to pre.

Solution 3: Use inline-block instead

Perhaps you have bumped into a fight with space between inline-block elements in CSS before. We can use the inline-block value on the display  property to force a line break because the inline-block element already has the extra whitespace we need. This works similar to adding a zero-width space character, but the list items will have no visual separation.

Solution 4: Use flex or inline-flex

Another solution is to define the unordered list as a flex container, which allows us to use flex-flow to set the direction of the list and to make sure it to multiple lines when needed.

We can also turn to the display: inline-flex instead of inline-block solution. The idea here is that the entire flexible container display inline.

---

So, we started this post with a situation that might come up when using a minifier. That said, minifiers — and many libraries for that matter — are smart and will try to prevent this line-breaking issue from happening.

Sure, it’s not an extremely common situation to bump into. It’s really one of those things that can fly under the radar if we’re not paying attention but, if it does happen, at least we know there are ways to work around it.