Le design system de la famille miss-* / mister-*

Les applications de la famille

Seize dépôts publics, dont quinze consomment ce paquet — l’application desktop n’en importe rien, et c’est le champ « sous-chemins » qui l’a révélé. Cette grille n’est pas une liste tenue à la main dans la page : elle est engendrée depuis apps-catalog.js — le fichier qu’importent les applications elles-mêmes pour s’afficher les unes les autres. Ce qui serait faux ici serait faux dans leurs pieds de page.

Le domaine et la maturité sont éditoriaux, saisis à la main : ils disent une intention, pas une version publiée. La persistance et les sous-chemins sont relevés dans le code de chaque app — les import et les extends réels, pas une intention —, et laissés vides quand ils ne l’ont pas été : un filtre qui affiche « non relevé » vaut mieux qu’une donnée inventée. Le filtre Consomme répond ainsi à la question qu’un design system doit se poser en premier : qui utilise vraiment quoi ? components.css n’a qu’un adoptant sur seize. Les pastilles sont peintes avec la primaire réelle de chaque application, jamais avec une icône distante : le showroom ne fait aucune requête réseau.

Catalogue

Tout ce que le paquet exporte, en une grille. Un test compare cette liste aux exports réels de react/index.js : ce qui n’est pas ici est soit couvert par une autre fiche, soit nommément exclu — c’est ainsi que les neuf hooks, absents de leur propre vitrine, ont été repérés.

Fondations

Tous les tokens ci-dessous viennent de tailwind-preset.css et sont donc identiques dans toutes les applications de la famille. Les valeurs affichées sont calculées en direct : redimensionnez la fenêtre pour voir jouer les clamp().

Typographie fluide

Côté Tailwind : text-fluid-sm, text-fluid-2xl… La colonne « Rendu » utilise la police de titrage du thème courant.

Familles de police

Le preset ne fournit que sans et mono (piles système, zéro requête réseau). Les polices de titrage (Fredoka, Plus Jakarta Sans, DM Sans, Inter…) sont chargées par chaque app ; ce showroom ne les télécharge pas et retombe sur la pile système si elles ne sont pas installées localement.

Espacement fluide

Points de rupture

• base < 40rem — mobile
• sm --breakpoint-sm : 40rem (≈ 640 px)
• md --breakpoint-md : 48rem (≈ 768 px)
• lg --breakpoint-lg : 64rem (≈ 1024 px)
• xl --breakpoint-xl : 80rem (≈ 1280 px)

En rem et non en px : les ruptures suivent la taille de police du navigateur. Une police par défaut agrandie décale donc bien la mise en page — sinon c’est une régression d’accessibilité.

Safe-areas iOS

Ces valeurs valent 0 partout sauf sur un appareil à encoche / barre d’accueil, et uniquement si le document déclare viewport-fit=cover. Les variantes *-safe-3 ajoutent 0,75 rem à l’inset système.

Cible tactile & focus

Le preset pose aussi :focus-visible → outline: 2px solid currentColor avec outline-offset: 2px. Parcourez la page au clavier (Tab) : l’anneau suit la couleur du texte, donc reste lisible dans tous les thèmes.

Couleurs

Le preset partagé n’expose aucune couleur. C’est volontaire : chaque application définit sa palette dans son propre @theme. Le showroom mappe ces palettes sur un jeu de rôles sémantiques communs — c’est ce jeu que la bascule de thème réécrit.

• Activez JavaScript La palette est lue en direct sur le thème appliqué.

Clair et sombre, côte à côte

Valider une palette en alternant les deux schémas est un mauvais outil. Les voici simultanément, pour le thème sélectionné.

Deux applications, côte à côte

Choisir deux habillages pour comparer leurs primaires et surfaces dans le schéma courant — utile avant une revue visuelle croisée.

Écarts entre les deux apps

Seuls les rôles qui diffèrent — pour une revue croisée sans lire deux panneaux entiers.

Palette du thème courant, lue via getComputedStyle.

Primitives d’interface

Ces six composants n’ont pas été inventés : ils ont été extraits de ce que plusieurs apps avaient déjà réécrit chacune de leur côté. Les matrices ci-dessous montrent les combinaisons — c’est là que vivent les régressions, pas dans l’instance isolée.

Button — variantes × tailles × états (4 apps avaient la même API)

loading pose aria-busy et désactive le bouton : afficher un indicateur sans bloquer laissait passer le double-clic dans deux apps.

Badge — tons sémantiques × variantes

Le tone dit une intention, pas une couleur — la teinte réelle vient du thème de l’app.

Field — états de validation

En erreur, aria-describedby référence l’aide et le message — les copies locales remplaçaient l’une par l’autre, faisant disparaître la consigne au pire moment.

Stat — chiffres-clés

La tendance porte une flèche et un libellé lu par les lecteurs d’écran : la couleur ne suffit pas à distinguer une hausse d’une baisse.

Card — la surface que dix apps avaient

Une carte est une surface, pas un contrôle : l’action va dans action (un élément focusable à l’intérieur), jamais sur la carte entière. CardHeader rend un vrai titre, pour que la structure du document survive à la mise en page.

Skeleton — chargement

Les barres sont aria-hidden ; seul le conteneur est annoncé (role="status"). Sinon un lecteur d’écran énumère « chargement » une fois par barre.

Sheet — feuille modale

Essayez au clavier : Tab boucle dans le panneau, Échap ferme, et le focus revient sur le bouton d’origine — les trois comportements qu’aucune copie locale n’avait au complet.

SegmentedControl — onglets « pilule »

Bac à sable — composer et copier

Les matrices montrent des combinaisons choisies ; celle dont vous avez besoin n’y est pas forcément. Réglez les props ci-dessous : le rendu suit, et l’appel React à copier se réécrit avec — y compris les attributs d’accessibilité qu’ils entraînent.

Le DOM engendré ici est écrit à la main, comme dans toute cette page — le showroom n’embarque pas React. C’est bien le même balisage que produit le composant, et il est habillé par le components.css réel du paquet ; mais c’est l’extrait de code, pas l’aperçu, qui fait foi.

Composants applicatifs

Les composants du paquet ne posent que des attributs data-dwc : aucune classe, aucun style imposé. Chaque app les habille avec sa propre CSS. Ci-dessous, le DOM exact produit par chaque composant, habillé par le thème courant.

Lequel choisir ?

Les sections précédentes montrent chaque composant seul. Elles ne disent jamais lequel prendre quand deux conviennent — et c’est pourtant là qu’on hésite. Chaque arbre tient en deux à quatre branches ; au-delà, ce n’est pas l’arbre qui manque de place, c’est l’API qui est sous-spécifiée.

Hooks et utilitaires

Neuf exports du barrel, soit près de la moitié de la surface React du paquet - et aucun n’apparaissait ici jusqu’à présent. Ils n’ont pas de démo : un hook ne se regarde pas. Ils ont une signature, une phrase, et le piège qui va avec.

Hooks et utilitaires exportés par le paquet

useTheme mérite une mention à part : c’est le contrat que reproduit le sélecteur en haut de cette page - light | dark | system persisté sous dwc_theme, attribut data-theme posé sur <html>.

Contrôles d’accessibilité

Mesurés sur cette page, dans le thème courant, à chaque changement de thème ou de taille de fenêtre. Ce ne sont pas des valeurs recopiées : elles sortent de getBoundingClientRect et de getComputedStyle.

La chaîne d’outils

Quatre filets successifs, du clavier du développeur au navigateur de l’utilisateur. Aucun ne suffit seul, et c’est pour ça qu’ils sont quatre.

axe-core ne détecte que 30 à 50 % des défauts, et Lighthouse encore moins. Un score de 100 ne dit pas qu’une appli est utilisable au clavier ni qu’un lecteur d’écran l’annonce correctement — d’où les deux dernières lignes du tableau, et les mesures ci-dessous.

Cible tactile

Seuil de 2,75 rem (≈ 44 px), recommandation WCAG 2.5.5 / iOS. Le Button partagé le tient même en taille sm — les variantes locales des apps descendaient à 32 px.

Contraste du texte

Seuil AA : 4,5:1 pour le texte courant, 3:1 pour le grand texte et les éléments d’interface. Un thème d’app qui échoue ici échoue aussi dans l’app.

Campagne contraste multi-apps

Ratios calculés sur les palettes déclarées (sans habiller la page) — pour prioriser une campagne, pas une app à la fois. Seuil AA 4,5:1.

Schéma de couleurs Clair Sombre

Contraste forcé

Sous « contraste élevé » de Windows, le navigateur remplace d’autorité les couleurs de texte, de fond et de bordure, et supprime les ombres. Tout components.css reposant sur des variables et des color-mix(), ce rendu-là ne se déduit pas : il se regarde.

Ces deux panneaux sont une émulation, pas le vrai mode : la page reproduit à la main ce que fait le navigateur — couleurs ramenées à la palette système « Aquatique » de Windows, ombres supprimées, et transparent laissé intact, car le forçage ne le touche pas. C’est précisément ce dernier point qui vide le bouton primaire à gauche. Le rendu authentique s’obtient en activant le thème de contraste dans le système, ou via Rendering › Emulate CSS media (forced-colors) dans les outils de développement.

Démo par application

Chaque tuile est peinte avec la palette réelle d’une application, dans le schéma en cours. Un clic habille la page entière — le même geste que Habiller la page sur une carte de la vitrine. L’aperçu en grand reprend alors les composants partagés dans cet univers. C’est la même page, le même CSS : seules les treize variables du contrat changent.

Toutes les palettes

Ce sont des aperçus générés, pas des captures d’écran. Ils sont peints en direct avec la palette réelle de chaque app et les composants réels du paquet — ils montrent donc fidèlement le design system dans chaque univers, mais pas les écrans des applications. Une vraie capture déposée dans showroom/screenshots/ et déclarée dans screenshots.js prend automatiquement la place de l’aperçu.

Stack de la famille

Relevé dans le package.json et le code source des applications, pas dans une note d’intention. Ce qui suit décrit ce qui est réellement installé et appelé.

Bases de données

Trois familles de persistance coexistent, et c’est délibéré : une app qui n’a pas besoin de compte utilisateur n’embarque pas de backend.

miss-supaboss est à part : elle pilote d’autres comptes Supabase via un backend Node et un jeton personnel, sans client Supabase côté navigateur. Le paquet fournit par ailleurs un keep-alive (workflow réutilisable + templates/supabase/keep-alive.sql) contre la mise en pause automatique du plan gratuit.

Icônes

lucide-react est le standard famille : 10 apps sur 15 l’utilisent. Icônes SVG tree-shakées (seules celles importées sont embarquées), strokeWidth et size ajustables, et currentColor qui suit les tokens du thème.

Deux réserves apprises à l’usage : lucide 1.x a retiré les icônes de marque — le logo GitHub des composants partagés est un SVG inline ; et une icône décorative doit porter aria-hidden, le libellé accessible vivant sur le bouton qui la contient. Les 5 apps sans lucide utilisent des SVG inline maison.

Cartes et géographie

Une seule app en a besoin : miss-lookhouse (veille immobilière), avec Leaflet 1.9 — affichage des biens et éditeur de zone par polygone. Tuiles OpenStreetMap, avec attribution et sans clé d’API : pas de compte tiers, pas de quota, pas de traceur.

Pas de standard famille imposé ici — un seul cas d’usage ne justifie pas une règle. Si une deuxième app cartographie, Leaflet + OSM est le point de départ à reprendre.

Animations — Rive

3 apps sur 15 intègrent Rive — animations vectorielles pilotées par machines à états, plutôt que par des Lottie/GIF joués en boucle. Et sur deux runtimes différents : @rive-app/react-canvas pour miss-badminton et mister-mölkky, @rive-app/react-webgl2 pour miss-genius.

Deux constats qui ne se voient pas dans un package.json. Aucun fichier .riv n’est livré — les trois dossiers ne contiennent qu’un README : en production, les trois apps affichent aujourd’hui leur repli statique, et c’est le chemin le mieux testé. Et aucune n’utilise le wrapper du paquet (RiveAnimation, sous-chemin /react/rive) : il enveloppe le composant <Rive>, alors que les trois ont besoin du hook useRive pour atteindre l’instance — entrées de machine à états, événements d’erreur, cleanup(). Un wrapper qui ne donne pas accès à l’instance ne sert à rien ici ; c’est une inadéquation d’API, pas un oubli.

Outils de test

axe-core ne détecte qu’une partie des défauts d’accessibilité — typiquement 30 à 50 %. Il ne remplace ni le parcours au clavier, ni les contrôles de contraste de la section précédente.

Intégration

Deux lignes dans le CSS principal de l’app suffisent à hériter de tout ce qui précède. La palette, elle, se déclare ensuite dans le @theme du projet.

/* src/index.css */
@import 'tailwindcss';
@import '@mister-guiiug/dev-pwa-config/tailwind-preset.css';

/* Identité PROPRE à l'application — jamais dans le preset partagé. */
@theme {
  --color-primary: #1758ba;
  --color-accent: #edc715;
  --font-display: 'Fredoka', system-ui, sans-serif;
  --radius-card: 1.1rem;
}

Rappel de priorité : un @theme placé après l’import écrase le preset ; du CSS non « layered » l’emporte sur la couche base.

Le schéma clair/sombre est piloté par le hook useTheme() (light | dark | system), qui pose data-theme sur <html> — ou la classe .dark avec l’option attribute: 'class'. Le sélecteur en haut de cette page reproduit exactement ce contrat.