À partir de quelle largeur une navigation doit-elle passer d'un menu replié à une barre horizontale ? La réponse à cette question porte un nom : le breakpoint, le seuil où une Media query bascule la mise en page dans un autre comportement.
Le mot lui-même donne la bonne méthode pour le choisir : il désigne l'endroit où quelque chose se casse, pas une largeur d'appareil recopiée d'une liste trouvée en ligne.
Définition
Un breakpoint est la valeur de largeur utilisée dans une media query pour déclencher un changement de mise en page. En dessous de ce seuil, un comportement s'applique ; au-dessus, un autre prend le relais. Un projet peut n'avoir qu'un seul breakpoint ou en compter plusieurs, selon la complexité de ses gabarits.
Le piège des breakpoints calés sur des appareils
Une pratique répandue consiste à choisir des breakpoints qui correspondent aux largeurs d'appareils populaires au moment où le site est conçu : 375 pixels pour tel téléphone, 768 pour telle tablette. Le problème, c'est que ces largeurs deviennent obsolètes dès qu'un nouveau modèle sort, alors que le CSS, lui, reste calé sur l'ancien.
Caler le breakpoint sur le contenu
La bonne méthode consiste à élargir progressivement la fenêtre du navigateur et à repérer le moment précis où la mise en page devient inconfortable : un texte trop long sur une seule ligne, des boutons qui se chevauchent, un espace vide qui devient excessif. C'est cette largeur-là, et pas une largeur d'appareil, qui devient le breakpoint.
.navigation {
display: flex;
flex-direction: column;
}
/* Le seuil choisi ici correspond au moment où les liens
commencent à se chevaucher sur une seule ligne, constaté
en élargissant la fenêtre, pas à une largeur de téléphone. */
@media (min-width: 640px) {
.navigation {
flex-direction: row;
justify-content: space-between;
}
}Combien de breakpoints prévoir
Un projet qui multiplie les breakpoints finit par maintenir autant de versions du même composant qu'il a de seuils, ce qui devient vite ingérable. La plupart des interfaces se contentent de deux ou trois breakpoints bien choisis, chacun correspondant à un vrai point de rupture visuelle plutôt qu'à une catégorie d'appareil supplémentaire.
Le mode d'émulation d'appareil des outils de développement aide à repérer ces seuils rapidement, en redimensionnant la fenêtre en continu plutôt qu'en changeant d'appareil physique à chaque essai. Il reste malgré tout recommandé de vérifier le résultat sur un appareil réel avant de considérer un breakpoint comme définitif, certains comportements tactiles ne se simulant jamais parfaitement dans un navigateur de bureau.
Une alternative : ne plus dépendre d'un seul breakpoint global
Un même composant, une carte par exemple, peut être trop étroit dans une colonne latérale et parfaitement à l'aise en pleine largeur, indépendamment de la taille de l'écran qui l'affiche. Dans ce cas, une Container query remplace avantageusement un breakpoint global, puisqu'elle réagit à l'espace réellement disponible pour le composant plutôt qu'à la largeur de la fenêtre entière, ce qui rejoint la philosophie Mobile first : partir du strict nécessaire, puis n'ajouter de la complexité que là où elle est justifiée.
Questions fréquentes
Des habitudes courantes existent, autour de 600, 768, 1024 et 1280 pixels, mais aucune n'est une norme technique. Elles servent de point de départ raisonnable, à ajuster ensuite en observant où le contenu réel du projet commence vraiment à se déformer.
Pas nécessairement. Un jeu réduit de breakpoints partagés par toute l'interface facilite la maintenance, mais un composant isolé dont le comportement casse à un seuil très différent des autres mérite son propre breakpoint plutôt qu'un compromis qui ne convient à personne.
La media query est l'instruction CSS elle-même, écrite avec @media. Le breakpoint est la valeur de largeur qu'on y inscrit. On peut donc dire qu'une media query utilise un breakpoint, mais pas l'inverse : le breakpoint n'existe pas sans la media query qui le met en œuvre.