Old-fashioned, Slice-n-Stack Background Images

Published: 9/14/2017

A long time ago, using sliced background images in multiple divs to create fancy "layouts" was a pretty neat thing. The technique was streamlined by image editors that provided a way to build web mock-ups, slice them into sections (opens in new tab), and then export the slices as individual images.

Consider the layout below. There was a time when this might have been accomplished with background images, using a method I like to call Slice-n-Stack.

Imagine that this "layout" was created as an image in Photoshop, or any graphic editor. Now imagine the image (minus the CTA text) being sliced in half horizontally to become a top and a bottom image. In the markup, two div elements would be stacked on top of one another, and the top and bottom image slices would be added in the background of their respective div. To make this work, the images had to match perfectly at the "seam" and no margins could exist on the divs:

(And yes, in the scenario I'm describing, the word "here" would be placed as content in a separate div from the words "Some CTA".)

If you're scratching your head in disbelief right now, it's OK. Obviously, this creates some questionable markup. But we did all sorts of image trickery back in the day to accomplish things we couldn't otherwise accomplish – I'm talking long before CSS3, or even the days of CSS Zen Garden (opens in new tab).

Today you'd probably do something with clip-path, negative margins and relative positioning, as demonstrated in this angled background CodePen (opens in new tab) to accomplish the angled background and floating CTA. Since these CSS properties are available today, and browser support for them is good, there's no need to devolve to the methods of 2001.

But is there ever any reason to use old-fashioned, sliced background images? Up until recently, I might have answered "no." But then a thing happened.

I did some work on a Drupal theme with three simple regions: Header, Content, and Footer. The site used Layout Builder (opens in new tab) to place components in the Content Region, including a Hero with a background image. On the majority of the pages, the Header region had a plain, white background. However, on two special landing pages, the background image from the Hero component needed to "bleed into" the Header region.

The design for most pages looked like this, with the dotted lines representing two separate divs, or in this case, two complex sets of divs and markup that make up a Drupal region.

The design for the special landing pages looked like this.

At first I laughed at the idea of using ol' Slice-n-Stack to implement the header background. But then I thought, geesh, I could have this whole thing done in about an hour.

I considered – and attempted – a few different approaches but quickly decided that they were going to take more time than I wanted, or impacted too many other things.

The background image had to be added through a field in a layout builder component. And even though the actual image would rarely, if ever, be edited on the special landing pages, the Hero component itself could be used on other pages.

At first I laughed at the idea of using ol' Slice-n-Stack to implement the header background. But then I thought, geesh, I could have this whole thing done in about an hour...

The header content had a certain height, so I cropped off the top of the hero image to match the header content height, and placed the cropped piece as the header background on my special pages. I set the background-position of the header image to bottom center, and the background-position of the hero image to top center. And the images lined up perfectly.

My CSS looked something like this:

.special-page-header {
background: url(upper-sliced-image.jpg) no-repeat bottom center;
max-height: 122px;

@media screen and (max-width: 762px) {
height: 73px;
}
}

.hero {

// Note that the actual URL to the image is set in a template. This code is only for positioning.
background-position: no-repeat top center;
}

The only adjustment I had to make was on smaller screen sizes, when the header content shrunk, and a small white line appeared at the bottom of header. But setting a fixed height for smaller screens resolved the issue.

Why This Approach Worked

There are a few reasons why this approach worked for this particular problem and project.

1. As stated before, the background image of the special landing page hero did not need to change regularly. If that wasn't the case, each time a new hero image was desired, the image would have to be sliced, and the upper portion saved to whatever path was referenced in the CSS, making this a potentially inefficient solution.
2. The URLs of the special landing pages were known and did not need to change regularly. This is what allowed me to target those pages in a template and provide a separate class for their headers. Here again, if routinely changed, the solution might be inefficient.

Other Possible Approaches

Build the special landing pages without Layout Builder.

My first consideration was to create a new content type for the special landing pages and custom theme the entire nodes. At the node template level, I could access both the Header and Content regions. This approach certainly would have worked, but it would have meant longer development time and a different process for content editors, who were learning to build pages with Layout Builder.

Some positioning trick.

Another thing I considered was absolutely positioning the header on the special landing pages only. This would pull the header out of the normal flow and force everything below it upwards. But, at least in my quick experimentation using the browser inspector, it was going to require additional CSS to resolve margin issues on the hero. Additionally, the Statue of Liberty flame was, itself, an absolutely positioned element that moved about as the screen size change, and it was going to need styling work to adjust its position at various breakpoints.

In the end, an old technique seemed to be the quickest, easiest solution. And sometimes the quickest, easiest solution is the right one.