Le système de design de Mocky

Il s'agit de l'interface de Mocky elle-même, pas des écrans qu'elle génère. Pour ces derniers, voir DESIGN.md et les presets de src/lib/styles.ts.

La direction : éditorial contrasté#

Noir et blanc, filets de 1px, aucun rayon, aucune ombre, un seul aplat de couleur signature. Affiche suisse plutôt que tableau de bord.

Ce n'est pas seulement un parti pris esthétique. Mocky sert à juger des couleurs : des maquettes sont posées côte à côte sur un canvas, et le chrome les entoure. L'ancienne palette était slate — un gris nettement bleuté (#64748b). Une maquette chaude posée dessus paraît plus jaune qu'elle n'est ; une maquette bleue paraît fade. Le chrome mentait sur les couleurs qu'il présentait, ce qui est disqualifiant pour un outil de design. Une coquille achromatique est la seule qui ne déforme pas ce qu'elle encadre, et le noir/blanc en est la version la plus complète.

Deux conséquences assumées :

• Les filets remplacent les ombres. L'élévation se lit par la valeur (trois niveaux de surface) et par un filet, jamais par un flou.
• L'accent est rare. Une seule action primaire par vue le porte. Un onglet ou un mode actif ne prend pas l'accent : il s'inverse (bg-ink text-surface). C'est plus franc, et ça reste lisible dans les deux thèmes.

Les jetons#

Tout vit dans src/styles/tokens.css, en canaux RGB bruts — c'est ce qui permet à Tailwind de composer l'opacité (bg-surface/60 fonctionne).

Deux thèmes, Papier et Encre, définis par les mêmes jetons. Ni l'un ni l'autre n'est une surcharge de l'autre.

Pourquoi deux jetons d'accent#

#228477 mesuré sur le papier (#faf8f3) :

D'où --accent-ink (#20796C, 4,93:1) : même teinte, un cheveu plus sombre, indiscernable à taille de texte. C'est ce qui permet d'utiliser la couleur largement sans livrer du texte illisible.

La règle : text-accent-ink pour du texte, bg-accent / border-accent pour tout le reste. text-accent n'est acceptable que sur un text-h2 ou plus grand, et sur une icône. Le test de contraste vérifie les deux jetons séparément, avec deux seuils différents.

En thème Encre, les deux jetons valent la même valeur claire (8,4:1 sur la surface) — un seul suffit là-bas.

Les dispositifs de presse#

Quatre choses font presque tout le travail pour qu'un écran ait l'air imprimé. Elles sont dans src/index.css.

Le format de page#

Un journal a un format fixe, et c'est celui-là. Les pages étaient d'abord enfermées dans max-w-4xl (896px), ce qui gâchait la moitié d'un écran large. Les libérer complètement allait trop loin dans l'autre sens : sur un écran de 2000px le contenu allait d'un bord à l'autre, l'œil devait traverser toute la largeur pour relier un nom de projet à sa date, et plus rien n'encadrait la page.

Mesuré, contenu utile selon l'écran :

En dessous de 1440px le comportement est celui d'une pleine largeur ; au-delà, la page s'arrête. Une seule valeur à régler, dans .page.

Les titres h1/h2/h3 prennent le serif automatiquement, via une règle en couche base. C'est la ligne qui sépare « application monochrome » de « page imprimée » : un titre en grotesque se lit comme du chrome, un titre en serif comme un article.

Aucune police n'est téléchargée. La pile serif s'appuie sur des faces livrées avec le système (Iowan Old Style et Palatino sur macOS, Georgia sur Windows) — les aperçus doivent fonctionner hors-ligne et sous une CSP stricte.

Les icônes#

src/ui/Icon.tsx — 48 icônes vectorielles en currentColor.

import { Icon, IconButton } from '../ui'<Icon name="link" />                                  {/* 20px par défaut */}<IconButton label="Supprimer"><Icon name="trash" /></IconButton>

L'interface était construite en emoji. Ce sont des bitmaps en couleur : le thème ne peut pas les toucher, ils font autocollant sur une coquille noir et blanc, et ils s'affichent différemment sur chaque système (Segoe UI Emoji, Apple Color Emoji, Noto) — la barre d'outils n'était jamais deux fois la même. Ils rendaient aussi autour de 12px, trop petit pour se lire comme une icône.

Icon est aria-hidden par construction : le nom accessible appartient au bouton, et IconButton l'impose.

Les règles#

1. Un composant décrit ce qu'un contrôle est, jamais sa couleur. bg-surface, text-ink-muted, border-line — oui. bg-slate-800, text-indigo-400 — non : ça ne suivra pas le thème.

2. L'échelle typographique a six pas, et rien entre eux. caption 11px (badges uniquement) · body-sm 13px (contrôles, barre d'outils) · body 14px (le défaut) · lead 16px · h3 20px · h2 28px · display 44px. Les tailles arbitraires (text-[11px]…) sont interdites. Les chiffres qui changent sous l'œil — zoom, dimensions, empreintes — prennent font-mono pour cesser de sautiller.

3. Toute cible cliquable fait au moins 32px de haut — et 44px au doigt. Les primitives l'imposent. Passer par elles suffit.

Les 32px sont dimensionnés pour un pavé tactile : un pointeur fin, guidé par un curseur qu'on voit. Un doigt n'a ni l'un ni l'autre, et il cache la cible au moment de la toucher. Sous @media (pointer: coarse), dans index.css, le plancher passe donc à 44px. Ce n'est pas une contradiction de la règle mais une seconde valeur pour un second appareil : la requête est purement additive — le fichier ne contient aucune autre requête de média sur la largeur — et ne peut donc rien régresser sur ordinateur.

4. Le focus est visible partout. Une règle unique en couche base dans index.css, posée en :where() pour rester à spécificité zéro. Ne l'annulez pas.

5. Une seule échelle de z-index. panel: 20 · menu: 30 · overlay: 40 · modal: 50 · top: 60. Pas de z-[70].

Les primitives#

Importer depuis src/ui :

import { Button, IconButton, Field, Input, Modal, Banner, Chip, Segmented, Panel } from '../ui'

Aucune primitive ne code un libellé en dur. Panel, Modal, Chip, Spinner et MockyLoader portent tous un nom accessible qui est le nom entier d'un contrôle sans texte — une croix de fermeture, un anneau qui tourne — et toutes les cinq le livraient en français, deux d'entre elles (Panel et Modal) sans aucune prop pour le surcharger. Une interface en anglais annonçait « Fermer le panneau », « Retirer » et « Chargement… », sur chaque panneau et chaque spinner de l'application. Chacune passe désormais par t('common.*') par défaut, et accepte une prop optionnelle pour les appelants qui ont mieux à dire. Un bloc de tests/i18n-parity.test.js échoue sur toute prop en forme de libellé affectée à une chaîne littérale sous src/ui : les contrôles de parité FR/EN ne pouvaient pas attraper ça, car une phrase qui n'atteint aucun dictionnaire est parfaitement cohérente entre deux dictionnaires.

Les garde-fous#

npx vitest run tokens-contrast

tests/tokens-contrast.test.js lit le vrai fichier de jetons et vérifie chaque paire texte/fond contre WCAG AA, dans les deux thèmes. Il vérifie aussi que les deux thèmes déclarent exactement les mêmes jetons — un jeton présent d'un côté seulement, c'est précisément comme une couleur retombe silencieusement sur la valeur de l'autre thème.

Ce test existe à cause de ce qui a été mesuré sur l'ancienne version :

Modifier le système#

• Changer l'accent : une variable, dans les deux blocs de thème. Rien d'autre.
• Ajouter un thème : dupliquer un bloc de jetons. Aucun composant à toucher.
• Ajouter une couleur : demandez-vous d'abord si c'est un rôle existant. Si oui, utilisez le jeton. Sinon, ajoutez le jeton dans les deux thèmes, exposez-le dans tailwind.config.js, et ajoutez sa paire au test de contraste.

Ce qui n'a pas été fait, et pourquoi#

Pas de migration vers Tailwind 4. Le gain principal (variables natives) est déjà obtenu en v3 par rgb(var(--x) / ). La v4 impose shadow-sm→shadow-xs, outline-none→outline-hidden, change l'anneau par défaut, supprime la config JS au profit de @theme, déplace le CDN Play vers @tailwindcss/browser — et surtout invaliderait les classes v3 des écrans déjà générés ainsi que toute la chaîne d'export (src/lib/export/). Coût réel, bénéfice utilisateur nul.