Hero Slide Content Renderer With Per-Breakpoint Typography Controls

One Liquid snippet renders a hero slide's pretitle, title, description and CTA from block settings, carrying the desktop and the mobile type spec on the same element as paired CSS custom properties, so two different slideshow sections share a single copy renderer.

A Shopify section setting holds one value, so a hero designed with one type scale for desktop and another for mobile can't be expressed in the theme editor. This snippet renders every slide's copy and CTA from block settings and writes both breakpoints' type specs onto the element as paired CSS custom properties, which the stylesheet resolves inside media queries. Two slideshow sections share it.

The Problem

A Shopify section setting is single-valued. A range setting is one number, a select is one choice, a color is one color. There is no setting type that means "this size on desktop, that size on mobile," and there is no per-block way to attach a media query to the value a merchandiser picked.

Campaign heroes on this storefront change weekly, and each one arrives from a designer with its own type scale, weights, letter-spacing and colors — specified separately for desktop and mobile, because a split-image desktop composition and a single-crop mobile one do not share a headline size. Without a way to express that in the editor, every campaign hero becomes a developer ticket: someone edits CSS, previews, and publishes, for a change that should have been a form field.

The Constraint

The two halves of the platform limit pull in opposite directions. Settings cannot carry a responsive value, and a theme cannot emit a media query per block without a {% style %} tag per block — which multiplies stylesheet output by the slide count and puts breakpoint logic in Liquid.

The slides also live in two places. The homepage hero carousel and the hero-banner section used on landing pages are different sections with different schemas, and both needed the same copy, CTA and offer treatment. Whatever rendered a slide's content had to be a snippet parameterized by block and a key, not a section — and the same snippet had to be safe to render more than once on one page, because the homepage mounts a desktop carousel and a mobile carousel and each renders its own slides.

Underneath all of it is Dawn 6.0.2, which predates theme blocks: the only block model available was the section's own blocks array.

What We Built

custom-banner.liquid is the renderer. Two sections call it: hero-banner.liquid on landing pages, and index-header-slider2.liquid, the homepage carousel documented on its own page. Each passes the current block, a key that identifies the slide, and an is_mobile flag saying which carousel the slide is being rendered into.

Typography as paired tokens. The snippet reads the block's desktop and mobile type settings and writes them onto the slide's content element as inline CSS custom properties, one pair per property per element: --desktop-banner-heading-size beside --mobile-banner-heading-size, --desktop-banner-heading-letter-spacing beside --mobile-banner-heading-letter-spacing, and the same pairs for the pretitle and the description. The stylesheet does the rest. Inside its desktop media query the heading reads the --desktop-* properties; inside its mobile query it reads the --mobile-* ones. One element, one markup path, both breakpoints' specs present in the HTML, and the browser's own cascade decides which applies.

Background tint. The slide's backdrop tint is composed in Liquid with color_modify: 'alpha', taking a color setting and a 0–100 opacity setting and producing a single RGBA value, so a merchandiser picks a brand color and a strength rather than typing an alpha channel. A video slide gets a second color and opacity pair for mobile, because the mobile crop of a video usually needs a different amount of darkening to keep the headline legible.

Copy and CTA. The description has a dedicated mobile override setting, banner_description_mobile, chosen at render time from is_mobile — a long desktop deck can become one line on a phone without a second block. When a button label is set, the whole pretitle, title and description group becomes the link, so the tap target is the composition rather than a small pill under it. The anchor carries data-trigger-promotion and data-button-content for GA4 promotion tracking, and its accessible name is generated by {% render 'anchor-aria-label' %}, the helper documented on the accessible link labels page, rather than hand-typed per slide.

Optional furniture. A slide can carry an offer-terms popover — an info button that opens a role="region" panel for the fine print — and a rotated sticky side banner with its own dismiss control. Every class the snippet emits is suffixed with the key, so one slide's styles never collide with another's when two sections, or two carousels, mount the snippet on the same page.

Why This Way

Pushing the responsive values into custom properties was the only way to keep one markup path and still let a merchandiser set mobile type independently. The alternative shapes are all worse in a specific way: a {% style %} block per slide emits a stylesheet fragment per block and puts media queries in Liquid; a second "mobile" block type doubles the editor work and lets the two drift; a JavaScript resize handler applies mobile type after first paint and shifts the largest text on the page.

The trade lives in the token set. Every typographic control is three edits, not one: a setting in each parent section's schema, a property pair in the snippet, and a rule in the stylesheet that consumes it. Adding "mobile pretitle weight" touches three files. We accepted that because the controls that exist are the controls designers actually vary — size, weight, spacing, color — and a fixed vocabulary keeps the editor from becoming a CSS panel. It also means every slide carries a long inline style attribute whether or not the merchandiser changed a default, which is extra markup in the initial HTML in exchange for type that is correct at first paint.

Why Not an App

Slideshow and hero apps hand the page an iframe or a script-rendered block. Either way the headline is not in the initial HTML: it arrives when the app's script runs, which means the largest text on the page — often the LCP element — paints late and the browser cannot size it before the script has decided what it says.

Here the hero is server-rendered Liquid. The headline, its size at both breakpoints and its tint are in the first response, and the stylesheet is the only thing between the HTML and the paint. A slideshow app also owns its own typography controls, which would have put the brand's type scale in a vendor's settings panel rather than in the theme's.

Implementation Notes

The description has a separate mobile override, banner_description_mobile, selected at render time by the is_mobile argument the parent section passes — the snippet never inspects the viewport itself.
Typography tokens come in --desktop-* / --mobile-* pairs for the heading, pretitle and description, covering size, weight and letter-spacing, and are emitted inline on the content element rather than in a per-block {% style %} tag.
The backdrop tint is a single value produced by color_modify: 'alpha' from a color setting and a 0–100 opacity setting; video slides get a second color-and-opacity pair applied only on mobile.
The CTA anchor carries data-trigger-promotion and data-button-content, the attributes the storefront's GA4 promotion tracking reads.
The CTA's aria-label is generated by {% render 'anchor-aria-label', href: ... %} rather than written per slide, so repeated "Shop now" buttons get distinct accessible names.
The pretitle, title and description group is wrapped in the CTA anchor only when a button label is set; a slide with no button renders the same group as plain text.
Every emitted class is suffixed with the key, so multiple slides — and the desktop and mobile carousels on the homepage — carry independent styles on one page.

Edge Cases

Every text block is optional. A slide with a title and nothing else renders only the title; empty settings emit no wrapper elements.
A slide with no button label renders its copy unlinked. There is no half-state where the text is wrapped in an anchor with no destination.
Video slides carry their own mobile tint pair, so a video that needs heavy darkening on a phone does not force the same treatment onto its desktop crop.
The sticky side banner remembers nothing. A dismissal lasts for the page view, and the banner returns on the next navigation.

Platform Primitives Used

liquid-schema-settings — every control the snippet renders is a block setting in the two parent sections' schemas; the snippet itself has no schema.
css-custom-properties — the carrier for both breakpoints' type specs on one element, resolved by the stylesheet's media queries.
liquid-snippets — the renderer is a snippet parameterized by block, key and is_mobile so two sections with different schemas share it.

Where It Runs

The home page and landing pages. Two sections mount the snippet: the homepage hero carousel, which renders it once per slide in each of its desktop and mobile carousels, and the hero-banner section placed on campaign landing pages. A change to how a slide's copy renders lands on both surfaces at once.

What This Demonstrates

Design system and reusable component library — the primary capability: a shared renderer with a fixed token vocabulary, consumed by two sections that would otherwise each carry their own copy of the same markup.
Art-directed hero and banner system — per-slide typography with separate desktop and mobile specs is the art-direction requirement stock heroes get wrong.
Campaign landing pages without a page builder — a weekly campaign hero becomes a merchandising task in the theme editor rather than a deployment.

How We Know

One Liquid snippet from the theme, roughly 240 lines, plus four client working records: two specification documents and two task-register entries. The specification describes an editor-configurable hero for the first phase of the redesign — a solid backdrop, a photo on one side, copy the marketing team can retype — and this snippet is the per-slide typography and layout control that made that spec a merchandising task rather than a code change. The custom-property mechanism is not described in the documents; it is a code-side decision, read from the snippet.

Related Builds

Homepage hero carousel v2 - video and split-image slides with per-slide typography control — the section that calls this snippet on the homepage. That page is about the two carousels and their slide types; this one is about what renders inside a slide.
Marketing image banner with mobile art, typography controls and highlight headings — the same problem on a different storefront and theme base: per-block typography emitted as tokens on top of Dawn's image banner.
Accessible link-label helpers for repeated CTAs — the snippet that gives this renderer's CTA its accessible name.
DE Hero: art-directed image/video hero with layout controls — a single-slide hero on another storefront, where the art-direction controls live in the section rather than in a shared snippet.

The Buy-vs-Build Question

A hero app buys a slideshow with its own typography panel and its own render path. Building the renderer bought a server-rendered headline with both breakpoints' type in the initial HTML, and cost a fixed token vocabulary that takes three edits to extend. Whether a shared section library is worth owning is the question on the theme section library and design system decision page.

Provenance & Evidence

Client: Nudestix — nudestix.com
Surfaces: Home page, landing pages
Mounted by: two slideshow sections
Complexity: Medium
Attribution: Deploi-authored. The snippet is ours. It runs in a theme built on Dawn 6.0.2 and is called by two sections we also wrote.
Status: Live, verified 2026-09-06
Evidence: One Liquid snippet from the theme, plus two specification documents and two task-register entries from client working sessions
Confidence: Strong — the code and the client record describe the same feature
Primary capability: Design system and reusable component library

Ready for a Hero Your Team Can Retype Without a Ticket?

You dream it. We build it. If every campaign hero on your store still ends in a developer's queue, Contact us today and we'll show you what a merchandiser-editable hero looks like in your theme.