2026 Acceptation front sur Mac distant :
scrollbar-gutter — tableau Safari/Chromium et amélioration progressive en trois étapes
Objectif : livrer une acceptation release où la largeur utile ne « respire » plus quand la barre verticale apparaît. Les pipelines centrés sur Chromium Linux oublient souvent les barres overlay et les préférences macOS qui changent la géométrie réelle. Ce guide fournit une matrice navigateurs, un tableau des différences, des combinaisons CSS/HTML prêtes à coller avec stratégie de repli, puis retour arrière et surveillance et une FAQ. Pour aller plus loin : Playwright WebKit sur Mac distant, appareil réel, simulateur ou cloud, et la checklist Node/npm côté Safari.
Pourquoi ce sujet bloque encore les releases
Lorsque overflow passe de hidden à auto sur une longue page marketing ou un tableau dense, une barre « classique » peut voler quinze à dix-huit pixels sur le bord droit : les grilles centrées, les en-têtes sticky et les boutons d’action semblent « sauter » alors que les scores Lighthouse restent verts. Les équipes produit qualifient cela de bug visuel bloquant même si aucune exception JavaScript n’est levée.
La propriété scrollbar-gutter: stable vise à réserver l’espace à l’avance, mais son interaction avec les modales plein écran, les scrollers imbriqués et les feuilles de style tierces qui forcent overflow: hidden sur body demande une preuve bi-moteur. Sur macOS, Safari s’appuie sur WebKit et AppKit : le comportement overlay, les réglages système « afficher les barres de défilement » et le zoom fractionnaire ne se reproduisent pas fidèlement sur une simple image Docker Chromium. D’où l’intérêt d’une session sur Mac distant pour archiver captures et métadonnées (SHA du déploiement, version Safari, préférence barres) dans le même ticket que la fusion.
Trois points de friction récurrents : (1) double bande réservée quand la racine et un panneau latéral appliquent chacun une stratégie de gouttière ; (2) both-edges jugé trop large par la direction artistique sur certaines largeurs ; (3) scripts A/B qui réinjectent du CSS sur html après hydration et désactivent silencieusement votre bloc @supports. Anticiper ces trois cas dans la définition d’« acceptable » évite les allers-retours le soir du gel.
02 Tableau des différences
Les libellés de spécification restent en anglais dans vos tickets (scrollbar-gutter, stable, both-edges) pour rester alignés avec MDN et les revues de code ; le tableau ci-dessous résume les attentes opérationnelles côté QA francophone.
| Sujet | Safari / WebKit | Chromium |
|---|---|---|
scrollbar-gutter: stable |
Réserve l’espace lorsque la fonctionnalité est prise en charge ; vérifier la racine réelle du défilement et les ancêtres transformés qui créent un conteneur de défilement implicite. | Comportement généralement prévisible ; attention aux routes qui appliquent overflow: hidden sur body à l’ouverture d’une modale. |
both-edges |
Symétrie gauche/droite utile pour certaines grilles, mais peut sembler « trop d’air » si la maquette supposait une seule barre classique. | À recouper en RTL et en modes d’écriture verticaux si votre audience internationale l’exige. |
| Overlay vs barre classique | La préférence utilisateur macOS modifie le moment où la gouttière devient visible ; notez-la dans le compte-rendu. | Les réglages « overlay » réduisent la largeur réservée ; ne validez pas uniquement depuis une VM Linux. |
| Absence de support ou repli volontaire | Les WebKit anciens ignorent la règle : prévoir la filière overflow-y: scroll ou accepter un léger saut documenté. |
Même logique ; gardez une colonne « palier actif » dans le registre de release (gouttière vs overflow forcé). |
03 Étapes d’implémentation
La stratégie recommandée comporte trois paliers : (1) marquer la racine du document pour cibler uniquement les pages concernées ; (2) activer scrollbar-gutter: stable derrière @supports ; (3) basculer proprement sur overflow-y: scroll lorsque le support fait défaut ou lorsque la QA observe une double gouttière à côté d’un tiroir modal. Évitez d’empiler both-edges sur la même itération que stable si vous n’avez pas encore de captures validées par design.
- HTML : ajoutez une classe sémantique sur la racine, par exemple
layout-root, réservée aux gabarits longs (dashboard, documentation). Les landings courtes peuvent rester sans classe pour limiter la surface de test. - CSS moderne : encapsulez
scrollbar-gutterdans@supports (scrollbar-gutter: stable)pour ne jamais envoyer une déclaration ignorée silencieusement au moteur de secours. - Repli : dans
@supports not (scrollbar-gutter: stable), appliquezoverflow-y: scrollsur le même sélecteur racine. Mentionnez explicitement dans la note de release que la barre peut rester visible même lorsque le contenu est court — c’est le compromis pour supprimer le saut horizontal.
Combinaison CSS + HTML prête à l’emploi (adaptez le nom de classe à votre design system) :
<html lang="fr" class="layout-root">
<head>…</head>
<body>…</body>
</html>/* Palier moderne */
@supports (scrollbar-gutter: stable) {
html.layout-root {
scrollbar-gutter: stable;
}
}
/* Repli explicite — barre toujours présente sur l’axe Y */
@supports not (scrollbar-gutter: stable) {
html.layout-root {
overflow-y: scroll;
}
}
/* Optionnel : n’ajoutez both-edges qu’après validation design + RTL */
@supports (scrollbar-gutter: stable both-edges) {
html.layout-root.layout-symmetric {
scrollbar-gutter: stable both-edges;
}
}Pour les modales qui verrouillent le défilement du document, testez la séquence complète : ouverture (souvent overflow: hidden sur body), interaction, fermeture. Si votre framework réinjecte des styles inline, prévoyez une règle de priorité ou un reset post-fermeture afin que la classe layout-root retrouve son palier actif. L’objectif d’acceptation reste simple : aucun saut horizontal mesurable sur la grille principale lorsque la scrollabilité verticale change pendant le scénario de démo standard.
04 Retour arrière et surveillance
Exposez la décision CSS derrière un feature flag documenté (même s’il s’agit d’une simple constante de build) afin que l’astreinte puisse revenir au palier overflow-y: scroll en une modification reviewable. Joignez au dépôt une note de trois lignes : auteur, date, symptôme observé — cela réduit le temps de diagnostic quand une bannière marketing republie une ancienne feuille qui neutralise votre bloc @supports.
Côté surveillance, segmentez les métriques Web Vitals par moteur lorsque c’est possible : le CLS autour des transitions d’overflow sur les routes à modales est le premier signal. Comparez les builds par étiquette Git et corrélez avec les déploiements de tags tiers. Si deux versions consécutives divergent uniquement sur Safari, remontez d’abord les changements touchant html, body ou les portails de modale avant d’investiguer le JavaScript métier.
Préférence barres macOS, build navigateur, largeur intérieure avant/après ouverture modale, palier actif (scrollbar-gutter vs overflow-y: scroll), présence éventuelle de both-edges.
Aucun déplacement horizontal inexpliqué supérieur à un pixel d’appareil sur la grille héro lorsque la scrollabilité verticale bascule pendant le script de démonstration validé par produit.
Après deux itérations infructueuses entre moteurs, figez le palier overflow simple et reportez l’affinage des gouttières sur une epic design tokens plutôt que sur des bricolages JavaScript de largeur de barre.
05 FAQ
La propriété scrollbar-gutter remplace-t-elle toujours les astuces overflow-y: scroll ?
Non. Elle adresse surtout la réervation d’espace lorsque le moteur comprend la règle. Les cas de scrollers imbriqués, d’iframes autonomes ou de styles concurrents sur la racine peuvent encore provoquer des sauts : gardez le repli overflow-y: scroll comme filiera d’acceptation explicite dans la documentation interne.
Pourquoi exiger Safari sur matériel Apple ou Mac distant ?
Parce que la géométrie des barres et les interactions overlay ne sont pas entièrement modélisées par Chromium sur Linux. Une preuve WebKit sur macOS complète la colonne « conforme » du tableau de bord release et rassure les parties prenantes métier.
Que faire si une bibliothèque tierce force overflow: hidden sur body ?
Isoler la modale dans un portail qui n’écrase pas vos classes racine, ou appliquer le reset dès la fermeture documenté. Si ce n’est pas possible, désactivez temporairement both-edges et capturez l’incident pour négocier une mise à jour du vendor plutôt que d’empiler des correctifs CSS fragile.
Signez l’acceptation WebKit + Chromium sans expédier de Mac
Consultez l’accueil, les tarifs et l’aide sans connexion, puis enchaînez avec achat ou location. Côté articles : tests Playwright WebKit, comparatif appareil / simulateur / cloud, et l’index du blog pour les autres checklists compatibilité.