yonathan-boop/Claude

antislop-layoutmobile

Anti Slop : Règles pour les agents IA de codage. Compétence de mise en page mobile

Fait partie du système antislop. À lire avec antislop.md (le noyau). Cette compétence approfondit le problème de la mise en page adaptative : comment une mise en page doit se redistribuer sur différentes tailles d'écran, du téléphone au bureau. Points d'arrêt, échelle, grilles, débordement, cibles tactiles et navigation. Elle fait référence aux règles de base par leur numéro et ne les duplique ni ne les renumérote jamais. Chargez-la lorsque la tâche construit ou modifie une mise en page qui doit tenir sur n'importe quelle largeur d'écran.

Comment utiliser cette compétence

• Chargez-la avec antislop.md chaque fois que la tâche concerne un travail mobile ou de mise en page adaptative. Le noyau contient le mécanisme (le test de propos, les trois niveaux, la porte de livraison) ; cette compétence contient la profondeur de la mise en page mobile.
• Chaque entrée a la même forme : Tell (le modèle), Why (pourquoi il est considéré comme du slop), Fix (quoi faire à la place), avec la règle de base correspondante citée comme R-XX.
• Le principe derrière cette compétence : la mise en page mobile est une mise en page différente, pas la mise en page de bureau à une taille plus petite. Elle doit se redistribuer : se ré-empiler, se redimensionner et se réorganiser avec intention. Chaque modèle ci-dessous est une façon dont une mise en page échoue à se redistribuer.
• La porte de livraison dans le noyau reste la porte. La "Liste de contrôle de la compétence de mise en page mobile" à la fin de ce fichier est le supplément spécifique au mobile à exécuter parallèlement.

Points d'arrêt

Mise en page de bureau uniquement

• Tell : un état de mise en page pour chaque écran ; la vue mobile est la mise en page de bureau comprimée dans un téléphone.
• Why : R-03 exige une mise en page mobile parfaite, pas une réflexion ultérieure. Une page qui ne fait que rétrécir n'a aucun design mobile du tout : les cartes qui fonctionnaient côte à côte se chevauchent, et le texte destiné à un grand canevas s'entasse dans un espace étroit.
• Fix : définissez un état mobile réel au point d'arrêt où le contenu cesse de fonctionner. La mise en page mobile se redistribue : les colonnes s'empilent, les tailles diminuent et l'ordre change là où le contenu en a besoin. Si la vue mobile est simplement la vue de bureau à une largeur plus petite, la mise en page n'est pas terminée.

Point d'arrêt déterminé par une liste d'appareils

• Tell : des points d'arrêt nommés d'après des largeurs de téléphone (375px, 414px, 768px) choisis parce que "c'est la taille de l'iPhone", pas parce que le contenu s'y brise.
• Why : les largeurs d'appareils changent chaque année et chaque modèle. Un point d'arrêt est un point où la mise en page cesse de tenir ; le forcer à correspondre à une liste d'appareils fait que la mise en page suit une fiche technique plutôt que le contenu (R-03).
• Fix : placez les points d'arrêt là où le contenu se brise réellement : lorsqu'une colonne cesse d'être lisible, lorsqu'une rangée de cartes devient trop étroite. Testez en rétrécissant la fenêtre d'affichage et en observant où elle se brise, puis définissez le point d'arrêt à cet endroit.

Mobile stylisé en dernier

• Tell : des règles mobiles ajoutées comme une surcharge finale : une longue feuille de style de bureau avec une petite requête média à la fin corrigeant une ou deux choses.
• Why : un correctif de surcharge n'est pas un design mobile. Il corrige le symptôme qui a été signalé et en laisse le suivant, et les styles de base restent réglés pour un grand écran (R-03).
• Fix : traitez le mobile comme un état conçu, pas une surcharge. Donnez à la petite fenêtre d'affichage ses propres tailles délibérées et son propre empilement, et vérifiez toute la mise en page à cet endroit, pas seulement les endroits corrigés (R-35).

Mise en page à deux états

• Tell : une mise en page avec exactement deux états : une seule colonne empilée en dessous d'un point d'arrêt, et une grille à plusieurs colonnes large au-dessus, avec rien de défini entre les deux. Une largeur de tablette ou de petit ordinateur portable hérite alors de l'état le plus proche : l'empilement de téléphone étiré absurdement large, ou la grille de bureau comprimée dans une fraction de son canevas prévu.
• Why : une page est une plage continue de largeurs, et R-03 exige qu'elle tienne à chacune d'elles, pas seulement à deux points d'arrêt choisis. Deux états laissent toute la bande médiane de la plage (approximativement 600 à 1024 px, où vivent les tablettes et les petits ordinateurs portables) comme un accident : un contenu qui ne s'empile pas délibérément ni ne s'insère dans une grille qui convient. La mise en page semble conçue uniquement à ses deux points d'échantillonnage et cassée partout entre.
• Fix : définissez des états réels aux largeurs où le contenu cesse de fonctionner, et laissez-les être aussi nombreux que le contenu le nécessite. Une redistribution typique est de trois états, pas deux : une seule colonne, puis une grille à deux colonnes lorsque les cartes deviennent trop larges en un seul empilement, puis la grille à plusieurs colonnes complète uniquement lorsqu'elle tient vraiment. Vérifiez en faisant glisser la fenêtre d'affichage sur toute la plage, pas en vérifiant deux largeurs et en considérant le travail terminé (R-35).

Échelle et dimensionnement

Tout à la taille du bureau

• Tell : les paddings, les espaces, les hauteurs de héros et les tailles de cartes reportés inchangés du bureau au mobile, de sorte que chaque section paraisse agrandie sur un téléphone.
• Why : un élément dimensionné pour un canevas de 1440px domine un canevas de 375px. Ce qui est confiant sur le bureau devient surdimensionné sur mobile : rien ne tient, rien ne respire, et la page semble conçue pour un écran qui n'est pas celui en main (R-03). L'espacement et la typographie doivent suivre le rythme de conception (R-05), et ce rythme a un registre plus petit sur mobile.
• Fix : donnez au mobile son propre pas de taille : une échelle typographique plus petite, un padding de section plus serré, des espaces plus petits. Maintenez les cibles tactiles à leur taille minimale (voir Cibles tactiles), mais réduisez tout le reste délibérément au point d'arrêt.

Typographie en pixels fixes

• Tell : des tailles de police en px fixes qui ne changent jamais entre le bureau et le mobile, de sorte que les titres et le corps du texte restent surdimensionnés sur un téléphone.
• Why : une typographie qui ne répond pas à la fenêtre d'affichage est une typographie dimensionnée pour un seul écran. R-03 exige que la mise en page mobile tienne, et R-06 nécessite une typographie qui améliore la lisibilité. Un titre qui s'étend sur toute la largeur du téléphone ou une taille de corps réglée pour une ligne large brise les deux.
• Fix : utilisez une typographie fluide (clamp()) pour que les tailles s'adaptent à la fenêtre d'affichage, ou définissez un pas typographique plus petit au point d'arrêt. Vérifiez le résultat à une largeur étroite (R-35), pas seulement dans l'aperçu de bureau.

Sections de 100vh

• Tell : les hauteurs de héros et de sections définies à 100vh, de sorte qu'une section remplisse tout l'écran du téléphone et pousse tout le reste en dessous de la ligne de flottaison.
• Why : une section plein écran conçue pour un moniteur de bureau devient une dalle géante sur un téléphone, et 100vh inclut le chrome du navigateur, donc elle déborde de la zone visible sur les navigateurs mobiles. Elle domine la mise en page au lieu de l'introduire (R-03).
• Fix : laissez les sections se dimensionner à leur contenu (auto), ou utilisez l'unité dynamique de la fenêtre d'affichage (dvh) lorsqu'une section pleine hauteur réelle est prévue. Rien en dessous de la ligne de flottaison ne devrait être un accident d'unités de fenêtre d'affichage.

Énorme padding vide

• Tell : le padding de section à l'échelle du bureau (96px, 128px) conservé sur mobile, créant de grands espaces vides entre les sections sur un téléphone.
• Why : un padding réglé pour un grand canevas se transforme en espace vertical gaspillé sur un petit. La page défile à travers du vide, et le rythme que R-05 appelle devient un vide entre chaque section.
• Fix : réduisez le padding de section au point d'arrêt à un registre mobile (environ la moitié ou moins), et vérifiez que la page défile à une densité naturelle au lieu de traverser des déserts d'espace.

Grilles et empilement

Colonnes qui ne s'effondrent pas

• Tell : une grille à plusieurs colonnes garde ses colonnes côte à côte sur mobile, de sorte que les colonnes rétrécissent, le texte s'enroule maladroitement et les éléments entrent en collision.
• Why : une grille est une promesse sur la largeur disponible. Lorsque la fenêtre d'affichage se rétrécit et que la grille ne se ré-empile pas, chaque colonne obtient une lamelle, le texte devient illisible et les cartes se chevauchent (R-03). C'est l'échec de collision : le côte à côte du bureau devient l'amas du mobile.
• Fix : effondrez la grille en une seule colonne redistributive au point d'arrêt. Le côte à côte devient empilé, et chaque élément obtient à nouveau la pleine largeur. Revérifiez à une largeur étroite (R-35).

Grille à largeur fixe

• Tell : grid-template-columns défini en px fixes, ou des zones de grille qui ne peuvent pas se redistribuer, de sorte que la grille reste rigide lorsque la fenêtre d'affichage se rétrécit.
• Why : une piste en px fixes ne se soucie pas de la fenêtre d'affichage ; elle garde sa largeur et force le débordement ou la collision. La mise en page a été construite pour un seul canevas et ne peut pas changer de forme (R-03).
• Fix : dimensionnez les pistes avec minmax() ou auto-fit et auto-fill pour que les colonnes rétrécissent et s'enroulent avec le contenu, et définissez des zones de grille qui s'effondrent au point d'arrêt. La grille doit être fluide par défaut, rigide uniquement là où une taille fixe est délibérée.

Grille à 12 colonnes forcée

• Tell : une grille à 12 colonnes forcée sur un contenu mobile qui a besoin d'une ou deux colonnes, de sorte que les étendues semblent arbitraires et que le calcul combat la mise en page.
• Why : un système à 12 colonnes est pour un grand canevas avec de nombreuses colonnes de contenu. Le forcer sur un téléphone fait de chaque élément une fraction d'une grille invisible que l'utilisateur ne voit jamais, et le contenu est adapté à la grille au lieu de la grille au contenu (R-03).
• Fix : laissez les colonnes suivre le contenu. Sur mobile, le contenu veut généralement une colonne, ou deux au maximum ; l'étendue à 12 colonnes n'a de sens que là où la mise en page a réellement autant de choses côte à côte.

Débordement

Fuite de défilement horizontal

• Tell : la page défile latéralement parce qu'un élément est plus large que la fenêtre d'affichage : un tableau, un bloc de code, une image, une longue chaîne ininterrompue.
• Why : le défilement horizontal est une promesse brisée sur mobile. L'utilisateur ne peut pas voir où la page se termine, et la mise en page se répand visiblement hors de l'écran (R-03). C'est le slop de débordement le plus courant car le fautif est hors écran dans l'aperçu de bureau et passe inaperçu jusqu'à ce qu'un téléphone l'ouvre.
• Fix : trouvez l'élément plus large que la fenêtre d'affichage (un tableau qui nécessite une mise en page redistributive ou un conteneur de défilement, un bloc de code qui s'enroule, des images avec max-width: 100%), puis contenez-le ou redistribuez-le. Vérifiez que toute la page a zéro défilement horizontal à la cible la plus étroite (R-35).

Découpage par débordement caché

• Tell : overflow: hidden sur un conteneur qui découpe le contenu aux largeurs étroites, cachant le texte ou les contrôles au lieu de les laisser s'adapter.
• Why : le découpage cache un échec. Lorsqu'un conteneur coupe son contenu parce que la mise en page ne peut pas le faire tenir, l'utilisateur perd de l'information et de l'interactivité (R-03). L'aspect zoom et redimensionnement du texte est couvert par antislop-human.
• Fix : laissez le contenu se redistribuer au lieu de le découper : permettez au conteneur de grandir, enroulez son contenu, ou effondrez-le au point d'arrêt. Découpez uniquement là où le recadrage est l'intention de conception (comme une vignette), jamais là où il cache du contenu.

Enfants à largeur fixe

• Tell : des enfants flex ou grille avec une largeur px fixe ou min-width qui sortent de leur parent sur un petit écran.
• Why : un enfant dimensionné en px absolus ne se soucie pas de la place de son parent. Sur mobile, le parent rétrécit et l'enfant reste large, donc il déborde du conteneur et de la page (R-03).
• Fix : dimensionnez les enfants avec des unités relatives et laissez-les s'enrouler (flex-wrap, largeurs fluides, min-width: 0 sur les enfants de grille). Un enfant doit pouvoir rétrécir avec son conteneur, pas conserver une taille de bureau.

Cibles tactiles

Cibles sous-dimensionnées

• Tell : des boutons, liens et contrôles plus petits qu'environ 44 x 44 px, faciles à toucher sur le bureau avec un curseur mais difficiles à toucher avec le pouce.
• Why : un curseur de bureau a une précision au pixel près ; un pouce non. Une cible qui est bien à 16px devient un exercice de frustration sur un téléphone, et elle échoue à la promesse que l'interface utilisateur est utilisable sur mobile (R-03).
• Fix : donnez aux cibles interactives une zone tactile minimale de 44 x 44 px, en utilisant du padding ou une plus grande zone de frappe même lorsque le visuel est plus petit. Vérifiez l'ensemble des contrôles à une largeur de téléphone (R-35).

Cibles trop proches

• Tell : des cibles de 44px regroupées sans espace, de sorte qu'un tap du pouce touche la mauvaise.
• Why : la taille de la cible n'a d'importance qu'avec l'espacement des cibles. Deux grands contrôles qui se touchent se comportent comme un seul grand contrôle : l'utilisateur ne peut pas sélectionner l'un ou l'autre de manière fiable (R-03).
• Fix : laissez un espace clair entre les cibles interactives adjacentes, au moins quelques px et idéalement assez pour que la zone de pression du doigt ne se chevauche pas. L'espacement est l'autre moitié de la taptabilité.

Interactions uniquement au survol

• Tell : des menus, révélations et info-bulles qui n'existent qu'au survol, de sorte qu'un utilisateur tactile ne peut jamais les ouvrir.
• Why : il n'y a pas de survol sur un écran tactile. Une interaction qui ne répond qu'au survol n'existe tout simplement pas pour les utilisateurs mobiles, et tout contrôle qui en dépend est une impasse (R-03).
• Fix : donnez à chaque interaction de survol un équivalent tactile : un menu qui s'ouvre au survol s'ouvre aussi au tap, une révélation s'affiche aussi au clic, et les éléments interactifs montrent un retour :active visible pour qu'un tap soit enregistré. Testez en utilisant l'interface uniquement avec le toucher (R-35).

Navigation mobile

Navigation qui reste celle du bureau

• Tell : la barre supérieure du bureau avec sa rangée de liens maintenue côte à côte sur mobile, de sorte que les liens s'entassent, s'enroulent en deux rangées, ou débordent de la fenêtre d'affichage.
• Why : une navigation de bureau est dimensionnée pour un grand canevas. Gardée en rangée sur un téléphone, elle devient un désordre de liens serrés, et c'est la première chose qu'un utilisateur mobile rencontre (R-03). La navigation est l'endroit où la redistribution compte le plus : l'utilisateur doit trouver où aller avant de pouvoir aller quelque part.
• Fix : effondrez la navigation en un modèle mobile au point d'arrêt : une navigation en bas pour les quelques destinations principales, ou un menu pour le reste. Les liens se redistribuent hors de la rangée, et les destinations principales restent à un tap du pouce. Vérifiez qu'elle tient à une largeur étroite (R-35).

Le menu hamburger nu

• Tell : tout est caché derrière une icône de hamburger sans libellé ni indice, de sorte qu'un utilisateur ne réalise jamais que le menu existe ou ne peut pas dire ce qu'il ouvre.
• Why : un hamburger nu suppose que l'utilisateur sait déjà ce que l'icône signifie et qu'un menu se cache derrière. C'est une connaissance que l'utilisateur mobile peut ne pas avoir, et sur mobile, le menu caché peut détenir le seul moyen de naviguer dans l'application (R-03).
• Fix : rendez le menu découvrable : étiquetez le hamburger ("Menu"), ou gardez les destinations principales visibles et cachez uniquement les secondaires. Si un menu est le seul moyen d'atteindre quelque chose d'important, cette accessibilité doit être évidente.

Navigation en bas qui mange le contenu

• Tell : une barre de navigation en bas fixe qui se superpose au contenu, couvrant les derniers éléments de la liste, le bouton final ou le formulaire que l'utilisateur essayait de terminer.
• Why : une barre en bas fixe occupe de l'espace sur mobile où il y en a déjà peu. Si elle recouvre le contenu que l'utilisateur veut voir ou avec lequel il veut interagir, le bureau bénéficie d'un accès facile qui bloque sur téléphone (R-03).
• Fix : donnez au contenu sous la navigation en bas un padding inférieur suffisant (la hauteur de la barre + de l'espace de défilement), ou faites que la barre de navigation apparaisse uniquement lors d'un défilement vers le haut pour qu'elle ne recouvre pas le contenu tout le temps. Un utilisateur ne devrait pas perdre un bouton de soumission ou un accordéon parce que la barre de navigation se tient dessus.

Navigation en bas qui ne peut pas changer

• Tell : une navigation en bas fixe avec des liens qui ne changent pas selon le contexte : toujours les mêmes icônes et destinations quelque soit l'endroit où se trouve l'utilisateur.
• Why : une navigation qui ne change pas ne s'adapte pas. R-03 exige une mise en page mobile qui est complète dans son contexte ; une barre en bas qui offre les mêmes éléments dans le panier et sur la page de connexion n'aide pas la tâche actuelle de l'utilisateur.
• Fix : adaptez les éléments de la barre en bas lorsque le contexte change : différentes sections d'une application avec des éléments principaux différents devraient mettre en avant leurs propres liens, la page actuelle devrait être mise en évidence, et l'endroit où l'utilisateur se trouve devrait être clair à partir de la barre en bas elle-même.

"