Crédit Image

Le navigateur web est un logiciel que nous utilisons tous et toutes au quotidien. Il nous est presque impossible de nous en passer pour réaliser nos diverses tâches.

Je ne connais personnellement personne qui peut s’en passer — sauf Richard Stallman, bien sûr, qui dit lui-même ne pas utiliser de navigateur web. Il passerait par son client mail en CLI pour récupérer le contenu de pages internet. Ça doit être une expérience quotidienne assez particulière, mais bref.

Il y a un an de cela, j’utilisais Opera GX, par simple plaisir personnel. J’aimais bien ce navigateur, j’y avais mes repères et il me convenait pour mon usage. Puis, lors de ma rentrée en études supérieures, j’ai lâché Opera GX pour passer sur Chrome. J’avais déjà remarqué quelques petites choses qui ne me plaisaient guère dans Opera, et je voulais me rapprocher d’une solution simple : toutes mes extensions disponibles, aucun souci de compatibilité. Bref, Chrome.

Puis, cette année encore, je me suis pas mal plongé dans le monde de l’open source. J’en ai compris le modèle, saisi plein de spécificités, et je me suis dit : les données, ça compte. C’est dans cette volonté que j’ai, par exemple, quitté mon client mail classique au profit de Thunderbird, une solution open source. Pour la prise de notes, j’utilise désormais Obsidian (qui n’est pas open source à proprement parler, mais qui est auto-hébergé). Et bien d’autres outils dont j’ai progressivement aimé le sentiment d’autosuffisance. Je ne suis pas paranoïaque, simplement un peu plus conscient de l’enjeu que représentent nos données.

Et donc je suis passé sur Mozilla Firefox. Quelle fut ma surprise lorsque, en faisant du CSS, je me rendis compte que les choses ne se comportaient pas tout à fait comme prévu.

Chrome et Firefox ne voient pas le CSS pareil

Avant, je développais exclusivement pour Chrome, en me disant que les autres navigateurs devaient se comporter à peu près de la même façon. Je me trompais.

La réalité, c’est que chaque navigateur embarque son propre moteur de rendu :

  • Chrome (et Edge, Opera, Brave) utilisent Blink, le moteur issu du projet Chromium, lui-même un fork de WebKit réalisé par Google en 2013.
  • Firefox utilise Gecko, développé par Mozilla depuis la fin des années 90.
  • Safari utilise WebKit, maintenu par Apple et ancêtre direct de Blink.

Ces moteurs interprètent les spécifications CSS du W3C, mais pas toujours de la même façon, et parfois avec des années de décalage dans le support des nouvelles propriétés. C’est d’ailleurs l’une des grandes frustrations historiques du développement web : les specs existent, mais leur implémentation est laissée à la discrétion de chaque éditeur. Le Web Compatibility project de Mozilla tente d’ailleurs de recenser et corriger ces divergences au fil du temps.

La “tolérance” de Chrome

Ce que j’ai perçu comme un “filtre de tolérance” chez Chrome, c’est en réalité son comportement face aux valeurs CSS invalides ou ambiguës : Blink a tendance à les ignorer silencieusement plutôt qu’à les rejeter. Firefox via Gecko est souvent plus strict, plus proche de la spec, ce qui peut faire apparaître des bugs qui étaient masqués sous Chrome.

Un exemple classique : les valeurs par défaut. Chaque navigateur applique une feuille de style interne (user-agent stylesheet) avant la vôtre. Firefox et Chrome n’ont pas les mêmes valeurs par défaut pour des propriétés comme margin, padding, ou le rendu des éléments de formulaire. C’est pour ça que la plupart des développeurs commencent leur CSS par un petit reset manuel. Quelque chose dans ce genre :

body {
    margin: 0;
    padding: 0;
    box-sizing: border-box;
}

L’idée est simple : on écrase les valeurs par défaut du navigateur pour repartir sur une base propre et identique partout. Sans ça, un margin que vous n’avez jamais déclaré peut très bien apparaître sur Firefox et pas sur Chrome — ou l’inverse.

Les différences concrètes

Voici quelques cas où le comportement diverge réellement :

Flexbox et Grid : Le support est aujourd’hui globalement excellent dans les deux navigateurs, mais des subtilités persistent. La spec Flexbox du W3C est pourtant claire sur le calcul des gap, des min-content ou des éléments imbriqués chaque moteur l’interprète néanmoins légèrement à sa façon.

Scrollbar : Chrome (et les navigateurs Chromium) supportent ::-webkit-scrollbar pour personnaliser les barres de défilement une pseudo-classe non standard, propriétaire WebKit. Firefox, lui, utilise depuis la version 64 les propriétés standardisées scrollbar-width et scrollbar-color. Deux approches, deux syntaxes, un rendu différent.

Sub-pixel rendering : Le rendu des bordures fines, des ombres (box-shadow) ou des polices peut varier légèrement selon le moteur, notamment à cause de la gestion de l’anti-aliasing et du sub-pixel rendering.

Propriétés expérimentales : Certaines propriétés CSS récentes — comme container-queries, :has(), ou color-mix() ont été implémentées à des dates différentes selon les moteurs. Un outil comme Can I Use permet de vérifier en un coup d’œil le support d’une propriété selon les navigateurs et leurs versions, indispensable avant d’utiliser quoi que ce soit de récent en production.

Développer pour Firefox d’abord : une approche sous-estimée

Voilà quelque chose qu’on entend rarement, mais qui mérite d’être dit : développer en priorité pour Firefox, c’est probablement la meilleure approche technique.

L’argument est simple. Gecko est plus strict dans son interprétation des specs CSS. Si votre CSS fonctionne correctement sur Firefox, il y a de très fortes chances qu’il fonctionne aussi sur Chrome parce que Blink applique ce fameux filtre de tolérance qui corrige silencieusement vos approximations. L’inverse n’est pas vrai : du CSS qui passe sans broncher sous Chrome peut très bien casser sous Firefox, précisément parce que Gecko refuse d’interpréter ce que la spec ne prévoit pas explicitement.

C’est un peu la même logique que de compiler son code avec les warnings au maximum : ça fait mal sur le moment, mais ça force à écrire quelque chose de propre. Firefox est votre compilateur strict. Chrome est celui qui ferme les yeux sur vos erreurs.

Il y a également une dimension éthique dans ce choix. Firefox est le seul navigateur majeur dont le moteur n’est pas contrôlé par une entreprise dont le modèle économique repose sur la publicité ciblée. Blink (Google), WebKit (Apple). Tous deux appartiennent à des acteurs qui ont des intérêts directs dans la façon dont le web évolue. Favoriser Firefox dans vos habitudes de développement, c’est aussi contribuer à maintenir une certaine diversité dans l’écosystème des moteurs, ce qui, à terme, est bon pour tout le monde. La MDN Web Docs (maintenue par Mozilla) reste d’ailleurs la référence de documentation la plus fiable et la plus neutre du développement web.

Bien sûr, ça ne veut pas dire ignorer Chrome. Avec presque 69% de parts de marché selon Statcounter, le négliger serait une erreur. L’idée, c’est plutôt de commencer par Firefox, de s’assurer que tout y fonctionne proprement, puis de vérifier sous Chrome où les problèmes seront, au pire, minimes.

Ce que ça m’a appris

La conclusion de tout ça, c’est que développer uniquement pour Chrome, c’est développer pour la majorité - mais pas pour tous, et surtout pas de la façon la plus rigoureuse qui soit. Tester sur Firefox (et idéalement Safari) est indispensable pour un rendu cohérent et un code CSS vraiment solide.

Changer de navigateur pour des raisons de valeurs: la confidentialité, l’open source, la diversité de l’écosystème web m’a donc aussi rendu meilleur développeur. Pas mal, pour un simple changement de logiciel ;)