Une barre plus étroite que sa fenêtre

Chaque page de notre panneau défilait latéralement à une largeur de fenêtre de 768 pixels. Huit pixels de trop en anglais, trente-huit en roumain. C’était le cas depuis un moment, dans neuf langues, sur toutes les routes. Ces chiffres viennent d’un balayage dans deux notations monétaires ; une lecture isolée antérieure du même en-tête donnait trois.

La cause tient dans une phrase que l’on approuve volontiers et qui est fausse : l’en-tête repliait son contenu selon la largeur de la fenêtre.

La fenêtre n’est pas la barre

À partir du point de rupture moyen, la barre latérale se place à côté de l’en-tête au lieu de se cacher derrière un menu, et elle coûte seize rem. À une fenêtre de 768 pixels, la boîte de contenu de l’en-tête fait donc 464 pixels. Ni 768, ni 736 non plus.

Les deux règles censées empêcher le débordement, masquer le nom du compte et réduire la pastille de connexion à un point, étaient toutes deux écrites contre le petit point de rupture : 640 pixels de fenêtre. Cela arrive 128 pixels avant l’endroit où la barre latérale apparaît et emporte ses seize rem. Entre ces deux nombres, il existe une bande où l’en-tête se croit au large et dispose en réalité de moins de place qu’à n’importe quelle largeur inférieure, car à 640 la barre latérale était encore masquée.

Ce n’est pas un problème de Tailwind ni un point de rupture réglé un cran trop bas. C’est une erreur de catégorie. Une requête de média répond à la question de la taille de la zone visible. La question que l’en-tête a besoin de voir traitée est celle de la place qu’il a reçue, et jusqu’aux requêtes de conteneur, il n’existait aucun moyen de la poser.

Mesurez ce que la rangée demande, pas ce qu’elle fait

À ce stade, la tentation est de relever un peu le point de rupture et de regarder le résultat. Cela produit un nombre qui fonctionne sur la machine de celui qui l’a relevé.

Une rangée souple réduit ses enfants à leur largeur de contenu minimale avant que quoi que ce soit ne déborde : ce que l’on voit à l’écran est donc le symptôme final et non la mesure. Une rangée peut dépasser largement son budget et paraître correcte, jusqu’au moment précis où un enfant ne peut plus se réduire. Le nombre sur lequel se guider est ce que la rangée demande quand rien ne la contraint : la cloner, la mettre à la largeur de contenu maximale, et la lire, dans chaque langue.

À 768 pixels dans la notation monétaire la plus large, sur neuf langues, les postes ressortent ainsi.

Il en découle deux seuils, tous deux énoncés contre la boîte de contenu de l’en-tête et non contre la fenêtre. Afficher le nom du compte demande 524 pixels : il démarre donc à 34 rem, avec vingt pixels de marge. Afficher la pastille plutôt que le point demande 622,8 : il démarre à 40 rem, avec dix-sept. Sous le seuil du nom, la rangée demande 422,3 pixels, ce qui tient largement dans les 464 qu’elle reçoit.

L’agréable, avec une question de conteneur plutôt qu’une question de fenêtre, c’est ce qui se produit ensuite sans une ligne de plus. Quand la barre latérale se replie en rail, cette même fenêtre de 768 pixels laisse 656 pixels d’en-tête, et le nom comme la pastille reviennent d’eux-mêmes. Rien ne sait quoi que ce soit du rail ; la barre s’est simplement remesurée.

La langue à zéro pixel de débordement

Le balayage qui attrapait cette classe de défauts mesure la largeur du document contre celle de la zone visible. Sur neuf langues, il a signalé un débordement partout, de huit à trente-huit pixels, sauf en français, où il a signalé zéro.

Le français n’allait pas bien pour autant. La pastille de connexion était passée à une deuxième ligne dans une barre de soixante-quatre pixels de haut aux éléments centrés : le texte se tenait donc discrètement à moitié hors de sa propre boîte tandis que le document restait exactement aussi large que la fenêtre. Aucun balayage de débordement ne voit cela, puisque rien n’a débordé.

C’est la même forme qu’un défaut antérieur sur notre site vitrine, où un titre d’un seul mot dans une tuile rétrécie peignait par-dessus sa voisine sans que la largeur de la page change jamais. Un texte qui quitte sa boîte n’élargit pas le document. Le contrôle doit donc être l’autre : le bord droit du texte contre le bord intérieur de la boîte où il devrait tenir, plus le nombre de boîtes de ligne qu’il occupe. Dans une barre à hauteur fixe, plus d’une boîte de ligne est déjà un défaut à soi seul.

Deux façons dont la mesure vous ment

L’appareil de mesure a demandé deux tentatives, et les deux échecs pointaient dans la même direction : vers un résultat vert qui ne veut rien dire.

Un clone à la largeur de contenu maximale doit être mesuré à l’intérieur du conteneur. Le nôtre était ajouté au corps du document, qui se trouve entièrement hors de l’en-tête : la requête de conteneur ne s’appliquait donc jamais et le clone se dessinait dans sa forme étroite, 394,8 pixels là où la vraie rangée demandait 515,3. Lu comme un avant et un après, cela ressemble exactement à une réparation réussie. C’est le même piège que mesurer en euros pendant que le client voit des dollars, ou mesurer une page dont les données ne sont jamais arrivées : le nombre n’est pas faux, il répond à une autre question.

Le second est plus terne et mérite d’être connu quand même. Un contrôle de syntaxe du script de balayage passe au-dessus d’un accent grave non échappé dans un gabarit : une sonde peut donc n’être subtilement pas celle que vous avez écrite alors que le fichier s’analyse sans souci.

C’est pourquoi le balayage a reçu un mode de preuve qui accroche dans l’en-tête des éléments cassés à dessein, un bloc trop large pour la barre, un bouton trop étroit pour son libellé et une ligne de texte qui sort de sa propre boîte, et exige que la sonde les signale tous. Il exige aussi que le bouton de compte existe tout court. Un scanner qui ne trouve rien ne se distingue pas d’un scanner qui ne regarde pas, et le seul moyen de les séparer est de lui donner quelque chose à trouver.

Contre le code non réparé, le balayage a produit soixante-quatorze échecs sur quatre-vingt-dix-huit contrôles. Contre la réparation, dans les deux monnaies, 2033 sur 2033.

Tronquer sans casser le bouton

Trois décisions plus petites dans la réparation sont exactement du genre que quelqu’un annule plus tard en rangeant, elles sont donc notées là où se trouvent les classes.

La troncature vit sur un élément à l’intérieur du bouton, pas sur le bouton. Poser overflow: hidden sur le bouton lui-même rogne sa propre zone de clic et son anneau de focus, ce qui transforme une correction cosmétique en défaut d’accessibilité au clavier.

Le nom accessible reste entier. Tronquer est un choix de présentation ; un lecteur d’écran devrait recevoir le nom complet de l’organisation, l’étiquette le porte donc en entier.

Et exactement une chose de cette rangée a le droit de rétrécir. Sans fixer les boutons à icône, le modèle souple répartit le rétrécissement sur tous, et l’on obtient trois boutons à icône écrasés au lieu d’un nom qui se tronque proprement. Rétrécir est une décision sur qui cède, et si vous ne la prenez pas, le moteur de mise en page la prend pour vous, également, ce qui n’est presque jamais ce que l’on veut.

Autre chose à savoir avant d’y recourir : un conteneur crée aussi une frontière de confinement de mise en page, ce qui en fait le bloc conteneur de tout élément fixe placé en dessous. Ici cela ne change rien, car les menus et tiroirs concernés sont des dialogues natifs de la couche supérieure, et parce que la barre portait déjà un filtre d’arrière-plan, qui a le même effet. Cela a été vérifié en les ouvrant et non déduit, et si la réponse avait été autre, le conteneur aurait dû aller ailleurs.

D’où la dernière contrainte : le conteneur doit être déclaré dans l’unique fonction qui construit tous les en-têtes, car l’en-tête d’administration monte le même menu de compte. Une requête de conteneur sans conteneur ne s’applique jamais, en silence. Déclarez-la à un endroit et oubliez l’autre, et le nom du compte disparaît d’une section entière du produit sans laisser de trace dans le moindre journal.

Ce que nous noterions

1. 01Une requête de média répond à une question sur la zone visible. Si un composant partage sa largeur avec une barre latérale, c’est la mauvaise question, et la réponse est fausse exactement de la largeur de cette barre.
2. 02Guidez-vous sur ce qu’une rangée demande, pas sur ce qu’elle fait. Le modèle souple réduit d’abord les enfants, l’écran vous montre donc le symptôme final.
3. 03Mesurez le clone à l’intérieur du conteneur. Dehors, la requête ne s’applique pas et vous mesurez la forme étroite, ce qui se lit comme une correction.
4. 04Zéro pixel de débordement peut être le cas cassé. Un texte qui quitte sa boîte n’élargit pas le document ; contrôlez le texte contre sa propre boîte et comptez les boîtes de ligne.
5. 05Donnez au scanner quelque chose à trouver. Un mode de preuve qui plante des défauts connus est le seul moyen de distinguer « rien à signaler » de « ne regarde pas ».
6. 06Tronquez sur un élément intérieur. Rogner le bouton rogne l’anneau de focus, et le nom accessible devrait rester entier.
7. 07Choisissez quel élément rétrécit. Laissé à lui-même, le modèle souple répartit la douleur également sur tout.

Pour être clair : la réparation est construite, mesurée sur neuf largeurs, neuf langues, cinq routes et les deux monnaies, et elle tourne. Elle n’a pas été mesurée sur une compilation de production, rien ici ne dit donc quoi que ce soit sur le décalage de mise en page, et un seul nom d’organisation a servi tout du long.

Issu du travail de plateforme sur Provibr. La page dont le débordement a lancé tout cela est décrite dans hors ligne à côté d’un titre qui dit en ligne, et ce que neuf langues font à un ensemble de commandes de taille fixe dans seize mille clés et neuf langues.