Ori
GitHub

Responsive design

Ori expose 4 breakpoints alignés Tailwind, repris de PF-UI pour rester cohérent avec les apps existantes. Le DS suit une logique mobile-first : on écrit le style mobile d’abord, puis on l’enrichit aux paliers supérieurs avec min-width.

Breakpoints

Les breakpoints sont publiés dans @govpf/ori-tokens et exposés en CSS via les variables --breakpoint-*, en JavaScript via les exports Breakpoint*, en Tailwind via les screens du preset.

TokenValeurCibleQuand l’utiliser
--breakpoint-sm500pxSmartphone XL en paysage, petite tabletteFaire passer une grille de 1 à 2 colonnes
--breakpoint-md768pxTablette en portraitBascule sidebar drawer vers persistent, header passe en mode complet
--breakpoint-lg992pxTablette en paysage, petit laptopApparition d’une troisième colonne, padding plus généreux
--breakpoint-xl1200pxDesktop standardLargeur max conteneur, affichage tableau riche

Règle mobile-first

Toujours écrire le style mobile par défaut, puis enrichir avec min-width. Ne pas utiliser max-width sauf cas justifié (masquage d’un élément qui n’a pas de sens en grand écran).

/* OK : mobile-first */
.kpi-grid {
  display: grid;
  grid-template-columns: 1fr;
  gap: 0.5rem;
}
@media (min-width: 768px) {
  .kpi-grid {
    grid-template-columns: repeat(4, 1fr);
    gap: 1rem;
  }
}

/* À éviter : desktop-first */
.kpi-grid {
  display: grid;
  grid-template-columns: repeat(4, 1fr);
}
@media (max-width: 767px) {
  .kpi-grid {
    grid-template-columns: 1fr;
  }
}

Avec Tailwind, les utilitaires sont mobile-first par construction : md:grid-cols-4 applique grid-template-columns: repeat(4, 1fr) à partir de 768px, sans rien défaire sur mobile.

Composants déjà responsive

ComposantComportement
AppShellSidebar in-flow desktop, drawer overlay sous 768px piloté par la prop sidebarOpen.
SideMenuVariant explicite persistent (desktop) ou drawer (mobile), pas d’auto-bascule.
HeaderLayout 3 colonnes (brand, nav, actions) qui wrap en mobile. La nav doit être pilotée par l’app si on veut un burger menu.
Table / DataTablePas d’adaptation native pour l’instant. Sur mobile, prévoir un wrapper avec overflow-x: auto ou un layout alternatif (cf. roadmap mobile).

Touch targets

WCAG 2.5.5 niveau AAA recommande des cibles tactiles d’au moins 44x44px. Ori expose le token --size-touch-target (valeur 44px) et l’applique automatiquement aux composants interactifs principaux en contexte tactile uniquement, via @media (pointer: coarse) :

ÉlémentHit-area en pointer: coarse
.ori-button (toutes variantes)min-block-size: 44px
.ori-inputidem
.ori-selectidem
.ori-tabs__tabidem
.ori-choice (wrapper checkbox / radio / switch)idem, padding vertical pour étendre la rangée cliquable autour du visuel 18x18

Sur souris ou trackpad (pointer: fine), la densité actuelle est conservée pour ne pas surcharger les interfaces denses (back-office, tableaux d’instruction).

Pour un composant custom qui a besoin de la même règle :

@media (pointer: coarse) {
  .mon-bouton-custom {
    min-block-size: var(--size-touch-target);
  }
}

Tester en viewport mobile

Les deux Storybooks (React et Angular) exposent 5 viewports prédéfinis dans la barre d’outils :

  • Mobile S (360x640) : smartphone Android entrée de gamme, plus petit dénominateur commun à viser.
  • Mobile L (414x896) : iPhone Pro Max et grands smartphones.
  • Tablet (768x1024) : iPad mini.
  • Desktop (1280x800) et Desktop L (1440x900) : écrans laptop courants.

Pour activer un viewport, cliquer sur l’icône loupe dans la barre d’outils Storybook puis choisir un format. La story rend dans une iframe à la taille demandée, ce qui permet de valider le comportement sans redimensionner manuellement la fenêtre.

Voir aussi