Mockup

A picture frame for a screenshot — or, better, for a live composition. Wrap anything in a browser window, a desktop window, a code editor, a phone or a tablet, and it reads as a product shot.

The frame is deliberately thin and neutral: it is made entirely of design tokens, so it restyles with your theme instead of being a hardcoded drawing of someone else's window chrome. The content inside is the point.

#Basic Usage

<x-wirekit::mockup url="app.example.com">
    <x-wirekit::stack gap="sm" style="padding: 1rem;">
        <x-wirekit::heading :level="3" size="lg">Invoices</x-wirekit::heading>
        <x-wirekit::text variant="muted">12 open · 3 overdue</x-wirekit::text>
    </x-wirekit::stack>
</x-wirekit::mockup>

#Frame a live composition, not a picture

The best use is not a PNG. Put real components inside and the shot can never go stale — it restyles with the theme and stays in sync with the library.

<x-wirekit::mockup variant="window" title="Dashboard">
    <x-wirekit::stack gap="md" style="padding: 1rem;">
        <x-wirekit::row gap="sm" align="center">
            <x-wirekit::badge intent="success">Live</x-wirekit::badge>
            <x-wirekit::text size="sm" variant="muted">Updated just now</x-wirekit::text>
        </x-wirekit::row>
        <x-wirekit::progress :value="72" label="Storage used" show-value />
    </x-wirekit::stack>
</x-wirekit::mockup>

#Code

The code frame gives a snippet a filename tab. Pair it with Code Block.

public function index(): View
{
    return view('teams.index', [
        'teams' => auth()->user()->teams,
    ]);
}

<x-wirekit::mockup variant="code" title="TeamController.php">
    <x-wirekit::code-block language="php">public function index(): View
{
    return view('teams.index', [
        'teams' => auth()->user()->teams,
    ]);
}</x-wirekit::code-block>
</x-wirekit::mockup>

#Devices

phone and tablet swap the chrome bar for a device shell.

<x-wirekit::mockup variant="phone">
    <x-wirekit::stack gap="sm" style="padding: 1.5rem 1rem 1rem;">
        <x-wirekit::heading :level="3" size="md">Today</x-wirekit::heading>
        <x-wirekit::text size="sm" variant="muted">3 tasks left</x-wirekit::text>
    </x-wirekit::stack>
</x-wirekit::mockup>

<x-wirekit::mockup variant="tablet">
    <x-wirekit::stack gap="sm" style="padding: 1.5rem;">
        <x-wirekit::heading :level="3" size="md">Dashboard</x-wirekit::heading>
        <x-wirekit::text size="sm" variant="muted">Everything at a glance.</x-wirekit::text>
    </x-wirekit::stack>
</x-wirekit::mockup>

#Screenshots

When you do frame an image, use Image so it stays CLS-safe and keeps its alt text:

{{-- 1. The frame is decoration; the image carries the meaning --}}
<x-wirekit::mockup url="app.example.com">
    <x-wirekit::image
        src="/screenshots/dashboard.png"
        alt="The dashboard showing 12 open invoices"
        :ratio="16/9"
    />
</x-wirekit::mockup>

#Sizing

A mockup has no size prop — you control its width the way you would any block: a max-width (or a Tailwind width class) on the component itself.

{{-- 1. A browser / window / code frame fills its container — cap it for a centered demo --}}
<x-wirekit::mockup url="app.example.com" style="max-width: 40rem; margin-inline: auto;">…</x-wirekit::mockup>

{{-- 2. Tailwind width utilities work just as well --}}
<x-wirekit::mockup variant="code" title="Example.php" class="max-w-2xl mx-auto">…</x-wirekit::mockup>

The phone and tablet device frames ship with default sizes so they read as a device even around a small snippet: the phone is 15rem wide with a 30rem minimum height, the tablet 22rem wide with a 28rem minimum height, and the browser / window / code frames fill their container up to 34rem. Override the width when you want a different scale:

{{-- 3. A wider phone frame --}}
<x-wirekit::mockup variant="phone" style="width: 18rem;">…</x-wirekit::mockup>

The device proportions are chosen to read as a phone or tablet, not to match any specific model — the tablet, for example, is a little squarer than a real one.

#Props

#Accessibility

• All chrome is decorative and aria-hidden — the traffic lights, the address bar, the notch. A screen-reader user is never told about fake window buttons they cannot press.
• The lights are inert spans, not buttons. Rendering them as buttons would put three dead controls in the tab order of every marketing page.
• The slot content carries every bit of the meaning — so frame real components, or an Image with real alt text.
• The address bar is not a URL a user can act on; do not rely on it to communicate anything the page does not also say in text.

#Keyboard Interaction

The frame is presentational and does not respond to keyboard input. Anything you place inside keeps its own keyboard behavior.

#Pitfalls

• Do not fake a product you do not have. A frame full of invented UI is the oldest tell of a generated landing page. Frame the real thing.
• Do not put an address bar on a non-browser frame. A url on a window or phone frame is ignored on purpose — it would be a lie.
• Do not treat the lights as controls. They are a genre convention, drawn neutral rather than red/amber/green precisely so they do not read as status.

#Design Tokens

Every value is a token — the frame follows your theme rather than drawing someone else's chrome.

#Further Reading

• MDN: CSS logical properties