Shopify Builds>LUS Brands>Marketing image banner with mobile art, typography controls and highlight headings

Marketing Image Banner With Mobile Art Direction, Per-Block Typography and Highlight Headings

A campaign banner built as a fork of Dawn's image banner: the vendor's class contract and overlay behaviour left intact, with a real mobile source, per-block type controls and an inline highlight convention layered on top.

Dawn's image banner takes one image, the theme's own heading sizes and no inline emphasis — three things short of a campaign comp. This section forks it and keeps its class contract intact: a picture element with a real mobile source, aspect-ratio padding computed in Liquid because the two crops differ, per-block typography carried as CSS custom properties, and a token convention that highlights one phrase inside a headline.

The Problem

Campaign banners arrive from a designer as two comps: a wide one and a phone one, cropped differently because the composition does not survive being squeezed. The headline in those comps is set in a size and weight chosen for the campaign, and one phrase in it is usually a different colour — that emphasis is often the whole point of the banner.

Dawn's stock image banner offers none of the three. It takes one image and scales it, so the phone gets a letterboxed version of a desktop crop. Its heading sizes come from the theme's type scale, so a comp that specifies a headline treatment can only be matched by overriding the theme. And its heading is a plain text setting, so there is no way to colour a phrase inside it without writing HTML into a field that is not meant to hold it.

The Constraint

The theme's banner CSS had to keep working. section-image-banner.css is Dawn's, and it carries the responsive, overlay and adapt-to-image behaviour the theme's other banners rely on. So the fork keeps Dawn's class names and overlay rules as they are, and layers everything new on top as ID-scoped overrides.

That decision constrains the layout work too. Because the mobile and desktop images are genuinely different files with different aspect ratios, the box has to be reserved before either one decodes — and CSS cannot know the ratio of an image it has not loaded. The ratio has to be computed at render time, in Liquid, from whichever image the current breakpoint is going to use.

The colour system is also fixed. The banner follows the theme's colour scheme classes rather than carrying raw colours, so a campaign inherits the scheme it sits inside instead of hard-coding hex values that outlive the campaign.

What We Built

custom_image_banner.liquid renders a <picture> with a mobile <source> and a desktop image, so the phone gets its own file rather than a scaled crop of the desktop one. The ::before padding-bottom that reserves the banner's box is computed from the relevant image's aspect_ratio in Liquid, which is what keeps the layout from jumping when a tall mobile crop replaces a wide desktop one.

Layout controls. The section adds a container-width toggle (img_in_container) that switches between a contained banner and a full-bleed one without a second section file, a maximum width for the text column, and separate desktop and mobile section spacing. About fifty lines of ID-scoped overrides sit under all of it, carrying banner__box padding steps at 750, 992 and 1200 pixels plus the mobile content alignment that Dawn's own rules do not express.

Typography as tokens. Heading and text blocks each carry a full type set — size, line height, weight, colour, highlight colour, for desktop and for mobile — and the section emits those values as block-scoped CSS custom properties rather than as inline font rules. The stylesheet consumes them inside its media queries, so one block's values reach both breakpoints through a single flip rather than through two sets of markup. The same approach is used on another storefront by the hero slide content renderer, and the reason is the same in both places: a Shopify setting holds one value, and a responsive design needs two.

Highlight headings. A heading can carry a [[...]] token around a phrase, which renders as a span in the block's highlight colour. That is the mechanism behind the one-word colour change a campaign comp usually asks for, and it means the merchandiser types the emphasis into the same field as the headline rather than asking for a code change.

Buttons. A buttons block supports two labelled links with a secondary-style toggle, so a banner can carry a primary action and a quieter one — the shape a promo banner needs when it has both an offer and a "learn more."

Why This Way

Forking a vendor section is a decision you pay for later, so start with the bill: this file is now coupled to Dawn's class names, and a theme update that renames them lands here too. We took that on because the alternative fails in the same direction and worse — a restyle from scratch has to reimplement the responsive, overlay and adapt behaviour Dawn's CSS already gets right, and then keep reimplementing it every time the theme moves.

Keeping the class contract meant only the additions needed new CSS. That is a much smaller surface to get wrong and a much smaller one to maintain, and it is the whole argument for forking rather than replacing.

Typography as custom properties rather than inline font rules is what makes the per-breakpoint half work. Inline rules would need a second element or a second markup path for mobile; properties let one element carry both specs and let the cascade choose.

The smaller cost is a human one. The highlight token is a convention, not an affordance: nothing in the theme editor tells a merchandiser that double brackets do anything, so it has to be taught.

Why Not an App

Banner and page-builder apps cover this ground, and for a store without theme resource they are a reasonable purchase for campaign slots.

The reason this one is a section is what sits in front of the image. An app's banner renders through the app's own runtime, which puts a script between the page and the largest image on it, and puts the banner's markup outside the theme's colour-scheme and spacing system — so a campaign banner looks like a campaign banner rather than like the site. Here the team ships a campaign by swapping two images and a headline in the theme editor, and the banner inherits the same scheme classes and spacing steps as everything above and below it.

Implementation Notes

  • The banner's box is reserved by a ::before padding-bottom computed in Liquid from the relevant image's aspect_ratio, so the space is correct before either image decodes and the page below does not shift.
  • Heading and text typography is emitted as block-scoped CSS custom properties consumed inside the stylesheet's media queries, which is how one block's settings serve both breakpoints from a single element.
  • A heading can carry [[...]] tokens around a phrase; the section renders the token contents as a span in the block's highlight colour, so inline emphasis is a text convention rather than markup in a setting.
  • The banner uses the theme's colour scheme classes instead of raw colour values, so it follows the scheme settings that govern the rest of the storefront rather than freezing a campaign's palette into the section.
  • img_in_container switches between a contained and a full-bleed banner, which is what lets one section file serve both a boxed promo strip and an edge-to-edge campaign hero.
  • Roughly fifty lines of ID-scoped overrides carry the banner__box padding steps at 750, 992 and 1200 pixels and the mobile content alignment, layered on top of Dawn's rules rather than replacing them.
  • It runs live as the curl-quiz promo banner on page.2022_all_product_page.json, with a single "TAKE THE QUIZ" call to action — one placement doing one campaign's job, not a section written speculatively for a library.

Edge Cases

  • With no mobile image set, the section falls back to the desktop image's aspect ratio for its box reservation, so a half-configured banner still reserves the right space.
  • With no image at all, a placeholder media block renders rather than an empty frame, which keeps the section usable while artwork is still being produced.
  • The overlay ::before is only emitted when image_overlay_opacity is non-zero, so a banner that needs no darkening does not ship a transparent element over its artwork.
  • The second button is optional, and the multiple-buttons layout class is applied only when both labels are present — one button renders as one button, not as a gap where the second would be.

Platform Primitives Used

  • liquid-schema-settings — every layout, spacing and typography control is a section or block setting, and the aspect-ratio computation happens in the same Liquid pass that reads them.
  • theme-blocks — heading, text and buttons are blocks rather than fixed fields, so a merchandiser composes the banner's content and order instead of filling in a form the section decided on.

Where It Runs

Registered against landing pages, the home page and the collection listing. Today it renders on one template — page.2022_all_product_page.json — as the curl-quiz promo banner. One placement is worth stating plainly: this is a section built to a campaign brief, and the reusable part of it is the pattern rather than the placement count.

What This Demonstrates

How We Know

One section file read from the theme, roughly 860 lines, plus client working-session records and a scoping document. The records establish where the work came from: additional hero-banner design was requested beyond the original design scope, and a list of banners needing design was asked for; the scoping document separately names new merchandising banners, info tiles and general content needs as design work in scope. Those describe the demand. The engineering choices on this page — the aspect-ratio computation, the token typography, the highlight convention — are read from the section file rather than from any document.

Related Builds

The Buy-vs-Build Question

A banner app buys campaign slots with a visual editor and a runtime in front of the image. Forking the theme's own banner bought a section that inherits the storefront's colour schemes and spacing, and cost a permanent coupling to the vendor's class names. Whether to own a section library at all is the question on the theme section library and design system decision page.

Provenance & Evidence

  • Client: LUS Brands — loveurcurls.com
  • Surfaces: Landing pages, home page, collection listing
  • Templates served: one — page.2022_all_product_page.json
  • Complexity: Medium
  • Attribution: Deploi-authored, and it is a fork: the section is ours, and it deliberately keeps the class contract and overlay behaviour of Dawn's own image banner, in a theme built on Dawn 15.4.1. The additions are ours; the responsive and overlay rules underneath them are the vendor's.
  • Status: Live, verified 2026-09-06
  • Evidence: One section file from the theme, plus two client working-session records and a scoping document
  • Confidence: Strong on the code; the client record establishes the request for the work rather than the mechanism
  • Primary capability: Design system and reusable component library

Ready to Make Your Theme's Banner Match the Comp?

You dream it. We build it. If every campaign banner arrives as a design your theme can only approximate, Contact us today and we'll show you how far your existing sections can be pushed before anything gets rewritten.

More builds