Applying a max-width when there’s no container

Recently, I had a situation where I needed to apply a max-width to content inside a container. The problem was that:

• the container itself had to fit the width of the larger layout, so it needed to be a lot wider than a comfortable line length
• the text wasn’t contained in an inner container, so there wasn’t an element that I could just apply max-width to.

There’s a trick I’ve used before for situations like this, though: using padding to simulate a max-width. Basically, just add padding on either side to constrain the text to an ideal line-length.

If the width of the container element doesn’t change, it’s pretty easy to calculate how much padding you’d need on either side. The problem, of course, is that most layouts aren’t fixed-width any more; they’re fluid. Even if they stop getting wider past a certain point, their widths will still change at narrower viewport widths. So I can’t just calculate the padding once; I have to make sure that no matter what the width of the container element is, the width of the content remains constant.

The first thing I tried was this:

padding: 1em calc((100% - 75ch) / 2);

Broken down:

• 100% is the width of the viewport: the window if you’re on a desktop machine, the screen if you’re on a mobile device.

• 75ch is the width of 75 characters. That’s the max-width I want. The most comfortable line length is somewhere between 60-75 characters per line—anything above that requires the reader’s eyes to do more work scanning each line. That’s not a good reading experience. (I’m looking at you, Wikipedia)

So basically, we’re specifying top and bottom padding of 1em, and side padding of whatever space there is when you subtract the ideal paragraph width from the overall width of the viewport. Since the padding is going to be placed on either side of the text, we’re dividing that value by two.

And that works nicely—until the screen gets really narrow, and the content presses up against it.

Because, of course, the width of 75ch—which is a fixed value, 75 characters per line—is now wider than the width of the viewport. Large value subtracted from small value = negative value. That’s going to look awkward on a phone. It would be nice to have some padding there, but how?

The quickest solution would be to use a media query to simply hide the max-width padding from smaller viewport sizes. That requires more code, though. Also, if you’re using a set of specific media queries—small, medium, large—the point at which the type hits the edge might not match any of them, so you’d have to either set up a whole new query, or hardcode that particular value into the CSS. Both are more complicated than the idea solution, which would be that the side padding never goes below, say, 1em (or however much you want).

Well, we could try something like:

padding: 1em calc(((100% - 75ch) / 2) + 1em);

In theory, that’s adding 1em of padding to whatever calc((100% - 75ch) / 2) evaluates to. But what happens if—as will happen at very narrow screen sizes—((100% - 75ch) / 2) evaluates to a negative number? If that negative number is a lot less than 1em, wouldn’t that counter the additional 1em padding, and leave us back to the content up against the edges?

As far as padding is concerned, that shouldn’t happen—padding can’t be negative. Indeed, if you check the Chrome inspector, negative values passed to padding are adjusted to 0.

So if we’re operating under the assumption that there can be no negative padding in CSS and negative calc() expressions evaluate to zero, the math in the above should work. As long as 75ch is smaller than 100%—i.e. narrower than the screen width— we’ve got our max-width effect. When 75ch is wider than the screen width, calc(((100% - 75ch) / 2) + 1em) resolves to calc((0) + 1em)…or 1em padding, which is what we want.

But here’s the weird part. That doesn’t work.

This is where I don’t fully understand what’s happening. calc(((0%) + 1em) should always produce 1em. The results we’re getting—the text being right up against the edge of the element—suggest the scenario I mentioned earlier: the value calc() returns is being treated as negative, even if Chrome isn’t registering it as such. That 1em looks like it’s being swallowed by a value a lot smaller than it is.

Regardless, what we do know is that at some point, our calc() statement is going to be less—maybe a lot less—than 1em. That’s where max() comes in.

max() is a neat little CSS function that returns the greater of two values. And whatever is happening behind the scenes, that’s all we really need to know: which is larger, the padding value we just calculated, or 1em?

Even neater, max() accepts calc() expressions as a value. So the following is valid CSS :

padding: 1em max(1em, calc((100% - 75ch) / 2));

And that should do it.