Card eyebrow
Card title 1
Author nameJune 2026
Contact us banner
Aliquam pharetra et orci at vestibulum. Vivamus lacnia erat urna, vel consectetur urna maximus inyrb eratjhup.
Contact Us- Would you consider using any third party libraries or techniques that could support the implementation?
- No, I didn't reach for any third-party libraries — the banner doesn't really need them. The layout, typography, gradient frame and responsive behaviour are all plain Tailwind utility classes. The one thing Tailwind doesn't give you out of the box is the angled clip-path on the image frame, so that lives as a small custom class (.clip-path-cta) in globals.css — just a couple of clip-path: polygon() rules, with one behind a media query for the wider desktop shape.
- Sitecore frontend implementation (HTML, CSS/Sass and/or JS as needed) of the contact us banner based on how you interpret the module specification.
- From Sitecore's side this is a fairly simple rendering — three datasource fields and not a lot else. Title is a Single-Line Text field (Rich Text if the editors ever need light formatting) bound to an <h2>. Link is a General Link, which maps straight onto the CTA anchor — href, link text and target all come from the field, and I truncate the link text on the frontend so an over-long label can't break the layout. Image is an Image field (or a Media field if video ever comes into play) bound to a responsive image. For the markup I split a <section> into two columns: a text column with the title and CTA, and a media column for the image. The image sits inside a decorative gradient frame clipped to the angled shape from the design, and below the md breakpoint that whole media column is hidden — on a phone you just get the title and the CTA, which keeps it clean. Styling is almost all Tailwind — flex layout, max-widths, the gradient frame and spacing are all utilities. The exception is the angled clip-path, which Tailwind doesn't cover, so it's a small custom class in globals.css (with a media query for the slightly different desktop shape). Light and dark come from a .dark class on the root that swaps the design tokens, and the CTA just takes its variant from the active theme — so I'm leaning on the theme provider the app already has rather than writing any banner-specific theming code. That means there's basically no JavaScript that belongs to the banner itself. The only client-side bits are reading the current theme through that shared provider and the defensive truncation of the title and link before they render. In a headless/JSS setup the component receives a fields object — { Title, Link, Image } matching the Sitecore JSON shape — and maps each one to the matching primitive (Text, the link-style Button, NextImage). In a classic SXA/MVC setup those same three fields would sit on the rendering's datasource and render from a Razor partial with the same markup and styles.
- Which questions would you ask the UX & Design team to help provide you with a better understanding and information to implement the module?
- What is meant by Light and Dark — is it tied to the global site theme (e.g. follows user preference or a site-wide setting), or are Light and Dark two independent variants that an author can place interchangeably on any page regardless of the surrounding theme?
Grid module variants
Two cards
eyebrow Description
H2 Title
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris.
View all
Three cards
eyebrow Description
H2 Title
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris.
View all
Four cards
eyebrow Description
H2 Title
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris.
View all
Five cards
eyebrow Description
H2 Title
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris.
View all
- Would you consider using any third party libraries or techniques that could support the implementation?
- No, nothing third-party here either. CSS Grid does all the heavy lifting — the desktop 4×2 layout and the per-variant card placement are just Tailwind grid utilities (col-span, row-span, col-start, row-start), and making it responsive was mostly a case of scoping those placement classes to the lg breakpoint so the cards drop to two columns on tablet and a single one on mobile. The cards themselves — the type, the image handling, the gradient overlay on the image cards — are built from Tailwind plus the primitives the project already has (Text, NextImage, Button). The only real config is a small TypeScript file describing the slot layout for each variant, which felt cleaner than pulling in a grid library for what's basically a fixed set of arrangements.
- Sitecore frontend implementation (HTML, CSS/Sass and/or JS as needed) of the grid module and its variants based on how you interpret the module specification.
- The way I read it, the grid module is a rendering with a module-level datasource plus a nested set of cards. At the module level there's a handful of fields: Title as Single-Line Text (the <h2> in the header), Subtitle as Single-Line Text for the little eyebrow above it, Description as Multi-Line or Rich Text shown next to the CTA, and Link as a General Link bound to the secondary "View all" button. The cards come from a Multilist or Treelist of child items — one item per card — and the frontend just takes the first N of them depending on the variant (2, 3, 4 or 5). Each card item carries its own fields: Title (the <h3>), Subtitle for the eyebrow, an Image, Author, Date and a Link. The whole card is wrapped in that link, and the footer shows author | date with a chevron on the right. For the variants I'd go one of two ways: four separate renderings, or — probably nicer for authors — a single rendering with a "Card count" parameter (2, 3, 4 or 5). Either way the datasource shape stays the same; all that changes is how many cards get consumed and which slot map is used. I deliberately tied a card's visual style to its slot rather than to an author field, so "image card with a text panel", "text-only card" and "full-bleed image with an overlay" are decided by where the card sits in the layout, not by something the author has to pick. Structurally it's a <section> with a header (subtitle, title, description + link) and a CSS grid underneath. On desktop that's the 4×2 arrangement; on narrower screens it collapses to two columns and then a single one. Every cell is a card <article> inside an <a>. The first card type splits vertically — image across the top half, a content panel (#f2f2f3) below. The second is that same panel but text only. The third is a full-bleed background image with a top-to-bottom gradient so the white text at the bottom stays readable. Styling is all Tailwind — the grid, spacing, colours and the overlay (bg-linear-to-b from-transparent to-black/70). The card background is a token (--color-grid-card: #f2f2f3) defined in @theme. I didn't reach for Sass; tokens and utilities covered it, though I'd happily switch if the wider project standardised on it. There's very little JavaScript in play. Which variant renders is resolved at render time from the rendering parameter — or simply from which rendering the author placed — and the same mock datasource can drive all four variants, with the variant component feeding the first N cards into its layout config. In a headless/JSS setup the component receives a fields object — { Title, Subtitle, Description, Link, Cards[] } — matching the Sitecore field JSON and maps each piece onto the shared primitives. In an SXA/MVC setup the equivalent Razor partials would output the same grid structure and classes.