Ce que chaque moteur
casse, et comment l'éviter
Cinq recherches aux sources primaires : bugs WebKit, divergences Blink et Gecko, réalités mobiles. Chaque règle retenue correspond à un défaut documenté et devient un contrôle qui peut refuser de compiler — pas une note dans un document.
Sur mobile, c'est WebKit qui commande
La découverte qui a orienté tous les arbitrages : 58,4 % du trafic mobile américain est rendu par WebKit, contre 40,1 % pour Blink.
Le chiffre surprend, parce que « Safari » n'est mesuré qu'à 52,1 %. La différence vient de Chrome, Firefox et Edge sur iOS : ce sont des habillages autour de WebKit, pas des moteurs distincts.
| Moteur | Mobile États-Unis | Navigateurs concernés |
|---|---|---|
| WebKit | 58,4 % | Safari, et Chrome / Firefox / Edge sur iOS |
| Blink | 40,1 % | Chrome, Edge, Opera, Samsung Internet, Brave (hors iOS) |
| Gecko | < 1 % | Firefox (hors iOS) |
Aucun moteur alternatif n'a été livré sur iOS malgré l'ouverture imposée par le règlement européen en mars 2024. Les conditions posées — binaire séparé, distribution européenne seule, interdiction de cohabiter avec WKWebView — n'ont été acceptées par personne.
Conséquence pratique : tester sous Chrome de bureau laisse la majorité du trafic mobile américain non testée. C'est Safari qui commande nos choix.
StatCounter, export CSV brut, juillet 2026 · Open Web Advocacy, « Apple's Browser Engine Ban Persists Even Under the DMA », 14 juillet 2025Un critère unique plutôt qu'un arbitrage
Plutôt que de trancher fonctionnalité par fonctionnalité, le convertisseur applique un seul critère : Baseline Widely Available, le classement du groupe WebDX du W3C.
| État | Définition | Règle du convertisseur |
|---|---|---|
| widely | supportée par les quatre moteurs depuis plus de 30 mois | émise directement |
| newly | supportée partout, mais depuis moins de 30 mois | sous @supports, jamais porteuse de lisibilité |
| limited | absente d'au moins un moteur | interdite |
Pourquoi 30 mois et pas « supporté partout ». Le délai absorbe les navigateurs qui suivent Chromium avec du retard — Samsung Internet, Opera, Brave — et qui ne font pas partie des quatre moteurs de référence. Baseline « newly » ne protège donc pas d'eux ; « widely » si.
web.dev — BaselineCe que chaque moteur casse
Cinq recherches distinctes, menées aux sources primaires : bugs WebKit, divergences Blink et Gecko, réalités mobiles, structure du document.
Chaque règle retenue correspond à un défaut documenté — jamais à une préférence de style.
| Moteur | Le défaut | La règle émise |
|---|---|---|
| WebKit | 100vh vaut la hauteur barre masquée : le contenu déborde au chargement | min-height:100vh puis 100svh. Jamais dvh : il se recalcule à chaque défilement |
| Tous | overflow-x:hidden sur body crée un conteneur de défilement et casse tous les position:sticky | overflow-x:clip — coupe sans créer de conteneur. L'ancien site portait le défaut. |
| WebKit | un conteneur arrondi ne découpe pas un enfant animé en transform (bug ouvert depuis 2012) | isolation:isolate sur les cadres d'image |
| WebKit | iOS zoome au focus sur un champ sous 16 px — y compris dans le navigateur intégré d'Instagram | font-size:max(16px,1rem) sur tous les champs |
| Samsung Internet | mode sombre qui inverse algorithmiquement les couleurs d'un site clair | color-scheme: only light — le mot only est ce qui fait reculer l'algorithme |
| Blink | la barre de défilement Windows rétrécit le viewport : décalage horizontal quand la page devient défilante | scrollbar-gutter:stable sous @supports |
| Gecko | ::-webkit-scrollbar n'a jamais existé dans Firefox | syntaxe standard uniquement |
| Tous | survol collant sur tactile : le bouton reste allumé après le tap | @media (hover:hover) and (pointer:fine) — jamais any-hover |
Pourquoi any-hover est le mauvais test
Un ordinateur portable tactile équipé d'une souris répond « oui » à any-hover : les styles de survol s'appliquent, et le défaut du survol collant revient dès que l'utilisateur touche l'écran.
hover: hover interroge le mécanisme primaire, ce qui est la bonne question.
Le convertisseur émet toujours un état :active hors de la media query : c'est le vrai retour tactile, et il ne doit dépendre d'aucune condition.
Le zoom iOS sur les champs : un impact de conversion, pas de style
Un champ de formulaire dont la police est inférieure à 16 px déclenche un zoom automatique au focus sur iOS. La page se recadre, l'utilisateur perd le contexte, et doit dézoomer à la main.
Le point décisif : cela s'applique aussi dans les navigateurs intégrés d'Instagram et Facebook (WKWebView) — c'est-à-dire précisément là où arrive le trafic social. L'effet est un abandon de formulaire, pas une gêne esthétique.
La cible tactile : un seul chiffre
Quatre normes donnent quatre valeurs. Le convertisseur en retient une seule, qui les satisfait toutes.
| Norme | Valeur | Statut |
|---|---|---|
| WCAG 2.5.8 Target Size (Minimum) | 24 px | niveau AA — contraignant |
| WCAG 2.5.5 Target Size (Enhanced) | 44 px | niveau AAA |
| Apple Human Interface Guidelines | 44 pt | convention iOS |
| Material Design 3 | 48 dp | convention Android |
| Émis par le convertisseur | 48 px | satisfait les quatre |
Retenir 48 px les satisfait toutes d'un seul nombre : cela supprime l'arbitrage au lieu de le trancher au cas par cas. Les liens à l'intérieur d'un paragraphe sont exemptés par le critère lui-même — l'exception « Inline ».
Les contournements devenus faux
La recherche a autant servi à retirer des contournements qu'à en ajouter.
Un correctif pour un bug corrigé est de la dette, pas de la prudence — et le contrôle les refuse au même titre que les défauts.
| Contournement répandu | Réalité vérifiée |
|---|---|
| -webkit-overflow-scrolling: touch | supprimé d'iOS en 2013 — la propriété s'analyse encore mais n'a aucun effet |
Le hack JavaScript --vh = innerHeight * 0.01 | inutile depuis svh / dvh (mars 2022) |
| Polyfill de défilement doux | natif depuis Safari 15.4 — et le polyfill casse le scroll-snap |
Fallbacks pour gap en flexbox | corrigé Safari 14.1, avril 2021 |
Éviter :has() « à cause de Safari » | Safari l'a livré en premier, en mars 2022 |
| Éviter subgrid « à cause de Firefox » | Firefox l'a livré en premier, version 71 — Chrome a suivi en 117 |
-webkit-font-smoothing « casse le rendu sous-pixel » | macOS a retiré le sous-pixel en 2018 : l'objection est caduque |
| FastClick pour le délai de 300 ms | bibliothèque archivée ; elle cause aujourd'hui des double-déclenchements |
Un point vérifié à contre-courant
-webkit-text-size-adjust figure dans la quasi-totalité des resets CSS diffusés, présenté comme une harmonisation entre navigateurs.
Firefox ne l'implémente pas, sous aucun préfixe. La propriété corrige WebKit et Blink, pas Gecko.
Elle est conservée — elle est utile — mais le commentaire du code dit ce qu'elle fait vraiment. Une documentation qui répète une croyance répandue est pire qu'une absence de documentation : elle empêche de reposer la question.
Des règles exécutables, pas documentaires
C'est le point qui distingue cette recherche d'un article de blog : chaque règle est un contrôle qui peut arrêter la compilation.
Une règle écrite dans une documentation est oubliée en six mois ; une règle qui refuse de compiler ne l'est jamais.
INTERDITS = [
(r"overflow-x\s*:\s*hidden",
"overflow-x:hidden sur html/body crée un conteneur de "
"défilement : tout position:sticky de la page cesse de "
"coller. Utiliser overflow-x:clip.",
lambda ctx: ctx in ("html", "body", ":root")),
(r"text-wrap\s*:\s*pretty",
"Absente de Firefox. Baseline « limited ».", None),
(r"user-scalable\s*=\s*no|maximum-scale\s*=\s*1(?![\d.])",
"Empêche l'utilisateur de zoomer : échec WCAG 1.4.4 "
"(niveau AA). iOS l'ignore de toute façon depuis la "
"version 10.", None),
]La preuve que ces règles mordent. Appliqué à l'ancien site, le contrôle de compatibilité relève 28 fautes — dont l'overflow-x:hidden sur body qui cassait silencieusement tous les éléments collants de la page. Sur le nouveau site : zéro.