🇩🇪 Deutsch 🇺🇸 English 🇪🇸 Español 🇫🇷 Français 🇮🇹 Italiano 🇳🇱 Nederlands 🇵🇹 Português
🇩🇪 Deutsch 🇺🇸 English 🇪🇸 Español 🇫🇷 Français 🇮🇹 Italiano 🇳🇱 Nederlands 🇵🇹 Português

FaceFlow — Layout System

A layout is the structural frame that wraps every page. It defines where the header goes, where the footer goes, what global styles apply, and where page-specific content is placed. Think of it as the "shell" of your website — consistent across all pages that use it.

Layout Developer Docs

Layouts define the shared page frame used by FaceFlow Pages.

For technical users, a Layout is the page shell contract. It determines where shared regions live, where page content is injected, and how a family of Pages keeps a consistent frame without duplicating structure page by page.

Core Responsibility

A Layout should control:

  • overall document structure
  • placement of header, footer, and shared regions
  • the main content insertion point
  • structural wrappers and page-family framing
  • optional layout-level style or behavior

A Layout should not own page-specific marketing content.

Layout Skeleton

Most Layouts can be understood through one simple pattern:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>{{ page.title }}</title>
</head>
<body>
  {header}
  {siteComponents}
  <main>
    {content}
  </main>
  {footer}
</body>
</html>

The key requirement is a reliable {content} insertion point. Without that, Pages have nowhere predictable to render.

Shell Contract Example

A Layout can also expose additional shared regions while keeping the ownership boundary clean:

<body class="resource-layout">
  {header}
  <div class="resource-shell">
    <aside class="resource-sidebar">
      {siteComponents}
    </aside>
    <main class="resource-main">
      {content}
    </main>
  </div>
  {footer}
</body>

The important rule is that the shell stays structural. The Page still owns the sequence rendered into {content}.

Relationship to Pages and Components

Keep the ownership model clear:

  • Layout owns the shell
  • Page owns composition of the experience
  • Component owns reusable content sections inside the experience

When Layouts stay structural, page families remain easy to evolve.

Shared Regions

Layouts are the right place for shared regions such as:

  • persistent navigation
  • standard footer framing
  • documentation sidebars
  • support rails used across one page family

Example:

<body class="docs-layout">
  {header}
  <div class="docs-shell">
    <aside class="docs-sidebar">
      {siteComponents}
    </aside>
    <main class="docs-content">
      {content}
    </main>
  </div>
  {footer}
</body>

That is structural reuse. A one-off promotional banner does not belong here.

Layout Families

Common layout families include:

  • main marketing site shell
  • campaign landing shell
  • resource or documentation shell
  • portal or knowledge-base shell

Each family should represent a durable structural pattern, not a temporary content variation.

Layout-Level Styling

Layouts can define shared style decisions that belong to the shell:

<body class="min-h-screen bg-slate-950 text-white">
  {header}
  <main class="mx-auto max-w-7xl px-6 py-16">
    {content}
  </main>
  {footer}
</body>

This is appropriate when the style belongs to the page frame. Section-specific styling still belongs in Components.

Change Impact

Layout changes are high impact because one Layout often affects many Pages.

Before changing a Layout, review:

  • which page family depends on it
  • whether shared regions change meaning
  • whether content width, spacing, or navigation assumptions change
  • whether existing Components still fit the shell correctly

Layout Review Pattern

When a Layout change is proposed, check impact in this order:

shell semantics
-> shared regions
-> content width and spacing
-> component fit
-> dependent page-family behavior

This helps teams avoid approving a seemingly small shell change that silently breaks several dependent Pages.

Technical Review Checklist

  • does the Layout expose a clear content insertion point?
  • does it own only shell-level concerns?
  • can multiple Pages reuse it without one-off exceptions?
  • are shared regions truly shared?
  • would changing this Layout affect many Pages in an understandable way?

Anti-Patterns

Avoid:

  • embedding page-specific copy directly in the Layout
  • creating near-duplicate Layouts for tiny variations
  • moving section logic into the shell
  • using the Layout as a dumping ground for all shared content
  • changing shell semantics without checking dependent Pages

Example Decision Rule

Use a Layout when the change affects the frame around many Pages:

new docs sidebar across the whole docs section -> Layout
new CTA block inside one page section -> Component
new page-specific proof content -> Page composition