Overflow reality check
Tags: css, cache, frontend, webdev
Published: 2020-01-09 06:59:59

---
title: Overflow reality check
published: true
date: 2020-01-09 04:09:35 UTC
tags: css, cache, frontend, webdev
canonical_url: https://rushlow.dev/blog/overflow-reality-check
---

## _The misadventures of a compound problem involving css, cache, and cross-browser support._

### TL;DR

* * *

Overcome overflow with long strings in a `pre` tag with:

```
pre {
  white-space: pre-wrap;
  white-space: -moz-pre-wrap;
  white-space: -o-pre-wrap;
  overflow-wrap: break-word;
  word-wrap: break-word;
  word-break: break-word;
}
```

### The Problem

* * *

After recording, editing, writing, and finally posting my article on [how to create a Docker container to initiate PHP projects](https://dev.to/jrushlow/php-workspace-container-part-1-14nf), I was pretty content with the result. I'm not a hollywood video producer or even an expert at creating tutorials of any kind. But I do just so happen to be pretty good at writing code, or so I thought...

Once I published the article to my site, [rushlow.dev](https://rushlow.dev), I had to make a few tweak's to the final result, mainly to the articles CSS properties. Woohoo, all looks good! WRONG, a week after publishing I just so happened to pull up the article on my phone and realized something was off.

A few code snippets that I had enclosed in `<pre>...</pre>` were overflowing their container. This in turn caused my responsive design to become un-responsive; scroll bars appeared out of no where and the entire article was hard to read on my iPhone. So, as any developer in my shoes would do, I fired up my IDE and began toying with the code base to fix the problem. After a few minutes I discovered I had forgot to set `white-space: pre-wrap;` on the `pre` CSS property. Phew... Problem solved!

Prior to pushing my code, I had fired up Firefox & Chrome on my dev machine to make sure everything looked right. So far so good, using the built in dev tools, I played around with the viewport size and all is well. I then ran my tests, inspected the code, and merged the fix into production. Fire up Firefox on my iPhone again, and the problem is still there. A few explitives later, I found myself fussing with CSS once again.

To shorten this up a bit, one would think the iPhone version and the desktop version of Firefox, Chrome, etc.. would produce the same result regardless of the device you are using the respective app on. Nope! When I did my final check of the article while in staging, both in Firefox and Chrome, the overflow had disappeared. However while viewing the same code base in the same staging environment with the same browsers but on my iOS device, the problem kept reappearing.

### The Fix

* * *

Part of the solution was to kick my self in the butt for breaking one of the golden rules while developing, especially anything related to CSS; disable any cache that may affect the desired result. Ahhhhhh, that's better. Now part of my problem has been solved. What I see on my iPhone is what I see on my desktop. GRRRR nope, nope, the result is improved but slightly different.

My `pre` tags are being wrapped accordingly but a few lines are still busting the container. It just so happens that the lines that are busting the container are long strings. `white-space: pre-wrap;` breaks a line at newline characters,`<br>`, and "as necessary to fill line boxes." What `white-space: pre-wrap;`doesn't do is break long strings to preserve width constraints. To do that you must use `word-wrap: break-word;`, which is an alias for`overflow-wrap: break-word;`.

`overflow-wrap: break-word;` allows for a word to be broken at any arbitrary point and does not take into account soft wrap opportunities introduced by breaking up a word.

The last part of the fix is to account for browser specific styles. To do that, I added:

```
pre {
    white-space: -moz-pre-wrap;
    white-space: -o-pre-wrap;
}
```

Depending on your requirements, you can also add hyphens to word breaks with`hyphens: auto`. As my blog is mostly of a technical nature, auto hyphens would create more confusion in most situations where I utilize `<pre>` tags. For instance, in citing a command or url, if one were to copy and paste a string that was "auto hyphened", the user would immediatly say something is broken. As`www.google.com` is obviously not the same as `www.go-ogle.com`. Take this into consideration before applying CSS based auto hyphens.

My final thought on all of this is that to keep in mind a browser on one platform, Firefox/Chrome on Debian, will not behave the same on another platform. I.e. Firefox/ Chrome on iOS. Also, regardless of how long you've been writing code, always remember KISS. Keep it simple stupid! I often have to remind myself that the hardest of problems can be caused by the most simplistic solution that is right in front of your face. I.e. checking "disable cache" in a browser...

* * *

For more details on any of the referenced tags, checkout Chris Coyier's article at [css-tricks](https://css-tricks.com/snippets/css/prevent-long-urls-from-breaking-out-of-container/) & of course the [MDN web docs](https://developer.mozilla.org/en-US/docs/Web/CSS).