The Fixed Background Attachment Hack

What options do you have if you want the body background in a fixed position where it stays put on scroll? background-attachment: fixed in CSS, at best, does not work well in mobile browsers, and at worst is not even supported by the most widely used mobile browsers. You can ditch this idea completely and let the background scroll on small screens using media queries.

Or get around it with a small fix. I suppose we could call it a “hack” since it’s a workaround in code that arguably we shouldn’t have to do at all.

The issue

Before I show you the fix, let’s examine the issue. We can see it by looking at two different approaches to CSS backgrounds:

1. a background using a linear gradient
2. a background using an image

Linear gradient

I want to keep the background gradient in a fixed position on scroll, so let’s apply basic CSS styling to the body that does exactly that:

body { background: linear-gradient(335deg, rgba(255,140,107,1) 0%, rgba(255,228,168,1) 100%); background-attachment: fixed; background-position: center; background-repeat: no-repeat; height: 100vh;
}

Here are the results in Chrome and Firefox, both on Android, respectively:

The gradient simply scrolls along with other content then jumps back. I don’t know exactly why that is — maybe when the URL tab goes up or disappears on scroll and the browser finds it difficult to re-render the gradient in real time? That’s my best guess since it only seems to happen in mobile browsers.

If you’re wondering about iOS Safari, I haven’t tested on iOS personally, but the issue is there too. Some have already reported the issue and it appears to behave similarly.

Background image

This issue with images is no different.

body { background: url(../assets/test_pic.jpg); background-repeat: no-repeat; background-size: cover; background-position: center; background-attachment: fixed; height: 100vh;
}

Another interesting thing to note is that when background-attachment: fixed is applied, the height is ignored even if we explicitly specify it. That’s because background-attachment calculates a fixed background position relative to the viewport.

Even if we say the body is 100vh, background-attachment: fixed is not exactly in accordance with it. Weird! Perhaps the reason is that background-attachment: fixed relies on the smallest possible viewport while elements rely on the largest possible viewport. David Bokan explains,

Lengths defined in viewport units (i.e. vh) will not resize in response to the URL bar being shown or hidden. Instead, vh units will be sized to the viewport height as if the URL bar is always hidden. That is, vh units will be sized to the “largest possible viewport”. This means 100vh will be larger than the visible height when the URL bar is shown.

The issues are nicely documented over at caniuse:

• Firefox does not appear to support the local value when applied on a textarea element.
• Chrome has an issue that occurs when using the will-change property on a selector which also has background-attachment: fixed defined. It causes the image to get cut off and gain whitespace around it.
• iOS has an issue preventing background-attachment: fixed from being used with background-size: cover.

Let’s fix it

Call it a temporary hack, if you will. Some of you may have already tried it. Whatever the case, it fixes the linear gradient and background image issues we just saw.

So, as you know, we are getting in trouble with the background-attachment: fixed property and, as you might have guessed, we are removing it from our code. If it’s looking at the smallest possible viewport, then maybe we should be working with an element that looks for the largest possible viewport and position that instead.

So, we are creating two separate elements — one for the background-gradient and another for the rest of the content. We are replacing background-attachment: fixed with position: fixed.

<div class="bg"></div>
<div class="content"> <!-- content -->
</div>

.bg { background: linear-gradient(335deg, rgba(255,140,107,1) 0%, rgba(255,228,168,1) 100%); background-repeat: no-repeat; background-position: center; height: 100vh; width: 100vw; position: fixed; /* z-index usage is up to you.. although there is no need of using it because the default stack context will work. */ z-index: -1; // this is optional
}

Now, wrap up the rest of the content — except for the element containing the background image — inside a main container.

.content{ position: absolute; margin-top: 5rem; left: 50%; transform: translateX(-50%); width: 80%;
}

Success!

We can use the same trick hack with background images and it works fine. However, you do get some sort of background scrolling when the URL bar hides itself, but the white patch is no longer there.

.img { background: url('../assets/test_pic.jpg'); background-position: center; background-repeat: no-repeat; background-size: cover; position: fixed; height: 100vh; width: 100vw;
} .content { position: absolute; left: 50%; margin-top: 5rem; transform: translateX(-50%); width: 80%;
}

Here are my takeaways

A fixed-position element with a height set to 100% behaves just like the element with background-attachment: fixed property, which is clearly evident in the example below! Just observe the right-most bar (purple color) in the video.

Even though, David Bokan in his article states that:

That is, a position: fixed element whose containing block is the ICB will resize in response to the URL bar showing or hiding. For example, if its height is 100% it will always fill exactly the visible height, whether or not the URL bar is shown. Similarly for vh lengths, they will also resize to match the visible height taking the URL bar position into account.

If we take into account that last sentence, that doesn’t seem to be the case here. Elements that have fixed positioning and 100vh height don’t change their height whether the URL bar is shown or not. In fact, the height is according to the height of the “largest possible viewport”. This is evident in the example below. Just observe the light blue colored bar in the video.

So, it appears that, when working with a container that is 100vh, background-attachment: fixed considers the smallest possible viewport height while elements in general consider the largest possible viewport height.

For example, background-attachment: fixed simply stops working when a repaint is needed, like when a mobile browser’s address bar goes away on scroll. The browser adjusts the background according to the largest possible viewport (which is now, in fact, the smallest possible viewport as URL bar is hidden) and the browser isn’t efficient enough to repaint on the fly, which results in a major lag.

Our hack addresses this by making the background an element instead of, well, an actual background. We give the element containing the content an absolute position to stack it on top of the element containing the image, then apply a fixed position on the latter. Hey, it works!

Note that the viewport height is calculated excluding the navigation bar at the bottom (if present). Here’s a comparison between the presence and absence of navigation bar at the bottom in Chrome Android.

Is there a downside? Perhaps! We’re using a general <div> instead of an actual <img> tag, so I wouldn’t say the markup is semantic. And that can lead to accessibility issues. If you’re working with an image that adds meaning or context to the content, then an <img> is the correct way to go, utilizing a proper alt description for screen readers.

But if we go the proper <img> route, then we’re right back where we started. Also, if you have a navigation bar at the bottom which too auto hides itself, then I can’t help it. If the hack won’t cut it, then perhaps JavaScript can come to the rescue.