Skills de mise en page mobile : corriger les textes coupés, espacements et ruptures

Une page peut sembler soignée sur ordinateur et mal fonctionner sur téléphone. Cette méthode transforme une plainte vague en une boucle limitée et vérifiable : documenter le défaut, choisir le bon skill, appliquer une correction ciblée et contrôler à nouveau le rendu.

Publié le Mis à jour le Analyse originale, sources citées

Contrôle dans le navigateur : une longue commande qui pousse le bouton Copier hors écran

Nous avons construit un cas CSS synthétique et vérifié la même commande avant et après un petit changement de retour à la ligne, le 19 octobre 2026. C’est un exemple reproductible dans le navigateur, pas un résultat généré par un skill ni l’affirmation que le site de production présentait exactement ce défaut. Aucun installateur ni aucune commande de terminal n’ont été exécutés.

Le cas initial associe une ligne flex et une commande sans rupture. Sur un écran étroit, la largeur minimale du contenu pousse le bouton de copie hors du panneau. La correction autorise la ligne et le code à rétrécir, fait revenir la commande affichée à la ligne et empêche le bouton de rétrécir. Elle ne masque pas le débordement du document. Le retour à la ligne modifie l’affichage, pas le texte copié dans le presse-papiers.

Dans le navigateur intégré de Codex sous Windows, avec une hauteur de 900 pixels CSS et des polices à chasse fixe du système, les mesures étaient les suivantes. La version corrigée conservait horizontalement commande et bouton dans le panneau aux quatre largeurs ; à 390px, nous avons aussi cliqué sur Copier et observé le message de réussite. Les valeurs exactes dépendent du navigateur et de la police disponible.

Cas synthétique de commande longue : débordement horizontal du document
Largeur de la fenêtreDébordement avantDébordement aprèsBouton Copier après
320px597px0pxDans le panneau
390px527px0pxDans le panneau
768px149px0pxDans le panneau
1280px0px0pxDans le panneau
  • Gardez le texte de la commande et le balisage identiques entre les deux modes.
  • Contrôlez la largeur défilable du document et le maintien des éléments dans leur conteneur, pas seulement la capture.
  • Pour un affichage de terminal sur une seule ligne, un défilement horizontal limité au bloc est une autre possibilité ; ce cas teste le retour à la ligne.
  • Un cas dans un navigateur ne démontre ni l’accessibilité, ni la compatibilité entre navigateurs, ni la sécurité, la qualité d’un skill ou une amélioration de conversion.

Documenter le défaut avant de modifier le CSS

Notez la page, la largeur de fenêtre, le ratio de pixels si pertinent, le contenu coupé et la relation attendue entre les éléments. Une capture est utile, mais indiquez aussi le texte ou la commande qui pose problème pour permettre à une autre personne de reproduire le défaut.

Gardez le premier passage en lecture seule si possible. Ne mélangez pas une correction d’espacement mobile avec une refonte, une réécriture ou une mise à jour de dépendance : un périmètre limité rend la cause et le retour arrière visibles.

  • La page et la largeur défaillantes sont précisées.
  • L’élément coupé, débordant ou mal espacé est identifié.
  • Le résultat attendu est formulé en une phrase.
  • La capture initiale ou la note de reproduction est conservée.

Attribuer une question à chaque skill

frontend-design est utile pour une direction visuelle cohérente, mais ne constitue pas un test de non-régression mobile. web-design-reviewer convient mieux à la comparaison des rendus entre points de rupture et au lien entre défaut visible et source. webapp-testing intervient si la correction peut affecter un parcours réel ou exige des journaux navigateur et assertions répétables.

Choisissez le rôle le plus restreint capable de répondre. Installer trois skills pour un débordement d’une ligne ajoute des permissions et des résultats à examiner sans améliorer le diagnostic.

Revérifier trois largeurs représentatives

Après la plus petite correction possible, contrôlez la largeur du téléphone signalé, une largeur intermédiaire étroite et une largeur de bureau auparavant correcte. Cherchez les textes coupés, débordements horizontaux, commandes écrasées, espacements irréguliers et actions principales repoussées hors de la zone utilisable.

Comparez des états identiques : même page, contenu, état du navigateur et critère d’acceptation. Si un changement améliore une largeur et en casse une autre, consignez le compromis au lieu de déclarer la vérification réussie.

  • Le défaut mobile initial a disparu.
  • La largeur intermédiaire ne présente ni défilement horizontal ni texte coupé.
  • Le rendu de bureau de référence reste intact.
  • L’action principale est utilisable au clavier et au pointeur.

Savoir ce qu’une capture réussie ne prouve pas

Une capture montre un seul état rendu. Elle ne prouve ni la sémantique pour les lecteurs d’écran, ni l’ordre du focus, le contraste de chaque état, le chargement, les performances ou la compatibilité avec tous les navigateurs. N’affirmez pas ces qualités sans les contrôles correspondants.

Les meilleures preuves au niveau d’une page sont une paire avant/après, le périmètre exact du changement et une brève fiche d’acceptation. Elles sont plus utiles au futur responsable de maintenance qu’une affirmation générale selon laquelle la page est désormais responsive.

Corrigez un défaut mobile que vous pouvez montrer

Définissez une page, une largeur précise et un contrôle visible avant/après avant d’élargir la demande de conception.