← Design System Index | Component Reference | Token Reference

IGrow Design System — Responsive Guidelines

This document defines how to build responsively for IGrow digital surfaces. All rules apply across HTML/CSS, Tailwind, React, and WordPress unless a stack-specific note says otherwise.

Traffic context. 80% of IGrow traffic is on Android devices. The two dominant screen sizes are 384 × 832 px (Android mobile, portrait) and 1920 × 1080 px (desktop). Every layout decision should be validated at these two anchors first, then at the breakpoint boundaries in between.

1. Mobile-first principle

Write base styles that work at 384px — no media query required. Then layer overrides upward using min-width breakpoints. Never write max-width media queries in product UI; they fight the cascade and produce fragile code.

System chrome exception. The design system's own documentation site and preview pages use max-width queries internally for their navigation drawers and layout switches. This is a pragmatic exception for tooling — it does not apply to product UI built with this system.

/* ✅ Mobile-first */
.ig-listing-grid { grid-template-columns: 1fr; }

@media (min-width: 768px) { .ig-listing-grid { grid-template-columns: repeat(2, 1fr); } }
@media (min-width: 1024px) { .ig-listing-grid { grid-template-columns: repeat(3, 1fr); } }

/* ❌ Max-width — avoid */
@media (max-width: 767px) { .ig-listing-grid { grid-template-columns: 1fr; } }

2. Breakpoint reference

Five named tiers, Tailwind-aligned. The CSS custom properties below are for reference — they cannot be used inside @media queries (CSS custom properties don't interpolate there). Use the raw pixel values in CSS or the sm: / md: / lg: / xl: / 2xl: prefixes in Tailwind.

Key rule: If a behaviour should apply to the 384 px majority, it belongs in base styles — no media query. If a behaviour should apply to the 1920 px majority, it belongs at 2xl — and it should look intentional, not just "wider".

3. Gutters

Gutters are the horizontal padding applied to page-level containers. Use the canonical tokens — do not pick ad-hoc --space-* values for container edges.

HTML / CSS

.ig-container {
  width: 100%;
  padding-inline: var(--gutter-mobile);
}

@media (min-width: 768px)  { .ig-container { padding-inline: var(--gutter-tablet); } }
@media (min-width: 1024px) { .ig-container { padding-inline: var(--gutter-desktop); } }

Tailwind

<div class="px-gutter-mobile md:px-gutter-tablet lg:px-gutter-desktop max-w-igrow-lg mx-auto">
  …
</div>

React

<div style={{
  paddingInline: 'var(--gutter-mobile)',
  maxWidth: 'var(--container-lg)',
  margin: '0 auto',
}}>
  {/* or use a <Container> wrapper component */}
</div>

WordPress (theme.json)

The repo's system/wordpress/theme.json registers spacing via spacingSizes. Add the gutter sizes to that array so the block editor exposes them as presets:

{
  "settings": {
    "spacing": {
      "spacingSizes": [
        { "slug": "gutter-mobile",  "name": "Gutter Mobile",  "size": "16px" },
        { "slug": "gutter-tablet",  "name": "Gutter Tablet",  "size": "24px" },
        { "slug": "gutter-desktop", "name": "Gutter Desktop", "size": "32px" }
      ]
    }
  }
}

In PHP templates, reference the CSS custom property that theme.json generates:

<div style="padding-inline: var(--wp--preset--spacing--gutter-mobile);">

4. Spacing scale per breakpoint

The design system uses a 4 px base scale (--space-1 through --space-10). When adapting spacing across breakpoints, never jump more than 2 steps between tiers.

Why the 2xl step up matters. On a 1920 px screen, inheriting 48 px section padding from mobile makes the layout feel cramped and unintentional. Stepping up to 128 px creates the premium, spacious feel the brand calls for — it also signals to the user that whitespace is deliberate, not accidental.

5. Fluid typography

For headings and display copy, prefer the clamp()-based fluid tokens over static values. These scale continuously with the viewport — no media-query breakpoints needed.

Static tokens for body and UI. Body copy (--fs-16), captions (--fs-12), labels (--fs-14), and button text should use fixed sizes. Scaling body text with the viewport degrades readability.

The ceilings are intentional. The fluid tokens cap at defined maxima — display stops at 72 px, h1 stops at 40 px, lead stops at 20 px. These are correct for 1920 px screens. Do not override them upward.

HTML / CSS

h1 { font-size: var(--fs-fluid-h1); line-height: var(--lh-heading); }
.hero__title { font-size: var(--fs-fluid-hero); line-height: var(--lh-tight); }

Tailwind

<h1 class="text-fluid-h1 leading-heading">…</h1>
<p class="text-fluid-lead leading-body">…</p>

React

<h1 style={{ fontSize: 'var(--fs-fluid-h1)', lineHeight: 'var(--lh-heading)' }}>…</h1>

WordPress (theme.json)

{
  "styles": {
    "elements": {
      "h1": { "typography": { "fontSize": "clamp(1.75rem, 1rem + 2.5vw, 2.5rem)" } },
      "h2": { "typography": { "fontSize": "clamp(1.5rem, 1rem + 1.8vw, 2rem)" } }
    }
  }
}

6. Layout

Band + container pattern

Every page section uses a full-bleed band with a constrained inner container. The band takes colour, imagery, or gradient to the screen edge. The container limits content width. This applies at all widths — it is especially important at 1920 px where unconstrained content looks adrift.

<!-- Full-bleed band, constrained content -->
<section class="ig-hero-section" style="background-image: url(…)">
  <div class="ig-container">          <!-- constrained wrapper -->
    <h1 class="ig-hero-section__title">…</h1>
    <p class="ig-hero-section__body">…</p>
  </div>
</section>

This applies to the nav, hero, every section band, and the footer. The nav bar always spans the full viewport width. Only the nav's inner content (logo + links) is constrained.

Container sizes

At 1920 px, max content width is --container-lg. The space outside it is intentional whitespace or band colour — never an empty void to apologise for.

Prose max-width

Body copy, lead paragraphs, and form fields should be capped at approximately 70ch (~680 px) regardless of container width. This is a readability rule — long line lengths slow reading comprehension.

.article-body { max-width: 70ch; }

Column grid

Property card grid

The property card grid uses a specific column progression:

<!-- HTML / CSS -->
<div class="ig-grid ig-grid--cards">…</div>

<!-- Tailwind -->
<div class="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 xl:grid-cols-4 gap-igrow-4">…</div>

Imagery aspect ratios at 2xl

Hero and banner images need explicit aspect ratios at wide viewports to prevent awkward stretching.

At 2xl, apply aspect-ratio: var(--aspect-banner) to hero sections so they fill the canvas proportionally rather than growing arbitrarily tall.

Deliberate whitespace at 2xl

Large screens should feel spacious and premium — not sparse. Step up section padding intentionally at 2xl:

.ig-section { padding-block: var(--space-7); }                      /* 48px — mobile */
@media (min-width: 768px)  { .ig-section { padding-block: var(--space-8); } }  /* 64px  */
@media (min-width: 1536px) { .ig-section { padding-block: var(--space-10); } } /* 128px — 2xl */

7. Component responsive behaviour

For component-specific markup and variants, see the Component Reference. This section covers responsive behaviour only.

Navigation

• Mobile nav height: 56 px (--nav-height-mobile)
• Desktop nav height: 72 px (--nav-height-desktop)
• The nav bar is always full-bleed. The inner content is constrained to --container-lg.
• Account for nav height when positioning sticky or full-screen elements: top: var(--nav-height-mobile) / top: var(--nav-height-desktop).

Hero

Use --fs-fluid-hero for the title — it handles the 384 px → 1920 px range without breakpoint overrides.

Property card grid

See the column progression in Layout → Property card grid.

Cards inside the grid lock their thumbnail to aspect-ratio: var(--aspect-card) (3/2) at all sizes. Do not allow card thumbnails to resize proportionally with text — the image height should be stable.

Buttons

Buttons inside a card footer or listing bar are never full-width — only standalone hero/form CTAs go full-width at mobile.

<!-- Full-width on mobile only -->
<a class="ig-btn ig-btn--primary ig-btn--block sm:w-auto">Request a viewing</a>

Forms

Form containers should use max-width: var(--container-sm) (760 px) — forms should never stretch to --container-lg. Apply inputmode and autocomplete attributes on every field: they directly improve the 384 px Android experience by triggering the correct keyboard and autofilling common values.

<form style="max-width: var(--container-sm)">
  <div class="ig-field-group ig-field-group--2col">
    <div class="ig-field">…</div>
    <div class="ig-field">…</div>
  </div>
</form>

Tables

Always wrap .ig-table in .ig-table-wrap. Never hide table columns on mobile — horizontal scroll is preferable to missing data. If a table has more than 6 columns, consider a card-based alternative for mobile.

Typography headings

Always use fluid tokens for h1–display-level headings. Use static tokens for body, labels, captions, and UI text.

8. Testing checklist

Test in this order — the two majority sizes first, then the boundaries.

• 384 px — no horizontal scroll; all content accessible; primary CTA full-width; body copy legible
• 1920 px — content constrained by container-lg; whitespace feels intentional; no text larger than fluid ceilings; hero aspect ratio correct
• 640 px (sm boundary) — inline buttons switch from full-width to auto
• 768 px (md boundary) — nav links appear; gutter increases; form goes 2-col
• 1024 px (lg boundary) — full desktop nav; gutter at desktop size
• 1280 px (xl boundary) — 4-column card grid kicks in
• Rotate 384 px device to landscape (667 px wide) — layout should not break
• Verify prefers-reduced-motion — all transitions should collapse to near-zero