La technique des sprites CSS a longtemps été une excellente solution pour optimiser les menus à base d’image, mais en plus de 15 ans, le Web a bien évolué. En 2026, on peut (on doit ) construire des menus horizontaux plus souples, responsives et accessibles. Dans cet article, on va voir comment recréer l’idée d’un « menu horizontal avec sprites CSS » en utilisant des techniques modernes, en gardant les mêmes objectifs qu’à l’époque : esthétique et performance.

Pourquoi les sprites CSS ne sont plus la solution par défaut

La technique des sprites consistait à regrouper tous les états graphiques (normal, survol, actif) dans une seule grande image, puis à afficher la bonne portion via background-position. Ça réduisait le nombre de requêtes HTTP nécessaires, ce qui était crucial avant l’arrivée de HTTP/2.

Aujourd’hui, cette approche a plusieurs limites pour un menu de navigation, même si elle fonctionne toujours :

• Maintenance lourde : chaque changement de pictogramme ou de texte implique de recalculer les positions.
• Mauvaise adaptation aux écrans haut densité (Retina, 4K), sauf en multipliant les versions d’images.
• Accessibilité limitée : le texte est souvent masqué au profit d’images purement décoratives.
• Utilité réduite : HTTP/2, les formats d’image modernes (WebP, SVG) rendent ce gain de requêtes moins critique.

La technique des sprites reste pertinente pour certains cas (animations, jeux en HTML5), mais pour un simple menu de navigation, des alternatives modernes font clairement mieux le job aujourd’hui.

Structure HTML moderne

La base n’a pas fondamentalement changé depuis 2009 : une liste non ordonnée reste un excellent choix pour construire une navigation. En revanche, on va profiter d’HTML5, des attributs ARIA et des bonnes pratiques en matière d’accessibilité.

<nav class="main-nav" aria-label="Navigation principale">
    <a class="main-nav__logo" href="/">
        <span class="sr-only">Retour à l'accueil</span>
        <!-- Logo SVG inline ou image -->
        <svg aria-hidden="true" viewBox="0 0 100 20">
            <!-- ... -->
        </svg>
    </a>
    
    <button class="main-nav__toggle" aria-expanded="false" aria-controls="main-menu">
        <span class="sr-only">Ouvrir le menu</span>
        <span class="main-nav__toggle-bar"></span>
        <span class="main-nav__toggle-bar"></span>
        <span class="main-nav__toggle-bar"></span>
    </button>

    <ul id="main-menu" class="main-nav__list">
        <li class="main-nav__item">
            <a class="main-nav__link is-active" href="/" aria-current="page">Home</a>
        </li>
        <li class="main-nav__item">
            <a class="main-nav__link" href="/services">Services</a>
        </li>
        <li class="main-nav__item">
            <a class="main-nav__link" href="/references">Références</a>
        </li>
        <li class="main-nav__item">
            <a class="main-nav__link" href="/contact">Contact</a>
        </li>
    </ul>
</nav>

Quelques points importants :

• Utilisation de <nav> et aria-label pour expliciter le rôle de la zone.
• Un bouton de type « hamburger » pour le mobile, relié à la liste via aria-controls.
• Une classe is-active pour gérer l’onglet actif côté CSS.

Mise en page avec Flexbox (bye-bye float !)

Là où mon article d’origine utilisait float: left sur les <li>, on peut aujourd’hui aligner le menu avec Flexbox. Plus simple et plus… flexible ! (ouais, je suis un marrant ).

.main-nav {
    display: flex;
    align-items: center;
    justify-content: space-between;
    gap: 2rem;
    padding: 0.75rem 1.5rem;
    background: linear-gradient(90deg, #1f2933, #111827);
    color: #ffffff;
}

.main-nav__logo {
    display: inline-flex;
    align-items: center;
    text-decoration: none;
    color: inherit;
}

.main-nav__list {
    display: flex;
    align-items: center;
    gap: 1.5rem;
    list-style: none;
    margin: 0;
    padding: 0;
}

.main-nav__link {
    position: relative;
    display: inline-flex;
    align-items: center;
    padding: 0.25rem 0;
    font-weight: 500;
    color: #e5e7eb;
    text-decoration: none;
    transition: color 200ms ease-out;
}

Ici, la liste devient une simple rangée flex, ce qui rend l’ajout ou la suppression d’éléments beaucoup plus naturel que la gestion de coordonnées de sprites. On peut aussi, si besoin, passer sur CSS Grid pour gérer un en-tête plus complexe.

Effets de survol modernes

Au lieu de gérer les états normal/hover/actif via une image sprite, on peut recréer des effets visuels sophistiqués en pur CSS : soulignement animé, fond dégradé, « pill » qui se déplace, etc.

Exemple : soulignement animé avec un pseudo-élément

.main-nav__link::after {
    content: "";
    position: absolute;
    left: 0;
    bottom: -0.2rem;
    width: 100%;
    height: 2px;
    border-radius: 999px;
    background: linear-gradient(90deg, #f59e0b, #ec4899);
    transform-origin: center;
    transform: scaleX(0);
    transition: transform 0.2s ease-out;
}

.main-nav__link:hover::after,
.main-nav__link:focus-visible::after,
.main-nav__link.is-active::after {
    transform: scaleX(1);
}

.main-nav__link:hover,
.main-nav__link:focus-visible,
.main-nav__link.is-active {
    color: #fff;
}

Avec cette approche, on reproduit l’idée d’un état survolé distinct, sans aucune image et avec un rendu parfaitement net sur tous les écrans. On améliore aussi l’accessibilité en stylant :focus-visible pour la navigation au clavier.

Icônes : du sprite bitmap au SVG

Autre gros virage : la façon d’intégrer des icônes. Là où l’on utilisait auparavant une sprite PNG, on privilégie maintenant :

• une « Icon Font » (de moins en moins recommandée),
• des SVG inline (avec <svg> dans le HTML),
• ou une sprite SVG via <symbol> et <use>

Exemple avec une sprite SVG

<svg aria-hidden="true" style="display:none">
    <symbol id="icon-home" viewBox="0 0 24 24">
        <!-- … -->
    </symbol>
    <symbol id="icon-services" viewBox="0 0 24 24">
        <!-- … -->
    </symbol>
</svg>

<nav class="main-nav" aria-label="Navigation principale">
    <ul class="main-nav__list">
        <li class="main-nav__item">
            <a class="main-nav__link is-active" href="#home">
                <svg class="main-nav__icon" aria-hidden="true">
                    <use href="#icon-home"></use>
                </svg>
                <span>Home</span>
            </a>
        </li>
        <!-- … -->
    </ul>
</nav>

.main-nav__icon {
    width: 1.1rem;
    height: 1.1rem;
    margin-right: 0.4rem;
    flex-shrink: 0;
}

Les avantages sont nombreux : un rendu vectoriel, une couleur facilement personnalisable en CSS (via fill et optionnellement currentColor), et plus aucune gymnastique de background-position !

Rendre le menu responsive

Un menu horizontal moderne doit s’adapter à toutes les tailles de fenêtre. On peut combiner CSS à un petit peu de JavaScript pour gérer l’ouverture et la fermeture du menu sur mobile.

CSS : basculer en mode « hamburger » sur mobile

.main-nav__toggle {
    display: none;
    border: none;
    background: transparent;
    cursor: pointer;
    padding: 0.25rem;
}

.main-nav__toggle-bar {
    display: block;
    width: 1.5rem;
    height: 2px;
    margin: 0.2rem 0;
    border-radius: 999px;
    background-color: #e5e7eb;
    transition: transform 0.2s ease-out, opacity 0.2s ease-out;
}

/* Mobile */
@media (max-width: 768px) {
    .main-nav {
        flex-wrap: wrap;
        align-items: center;
        row-gap: 0;
    }

    .main-nav__toggle {
        display: flex;
        flex-direction: column;
        margin-left: auto;
    }

    .main-nav__list {
        flex-basis: 100%;
        flex-direction: column;
        align-items: flex-start;
        gap: 0.75rem;
        max-height: 0;
        overflow: hidden;
        transition: max-height 0.25s ease-out;
    }

    .main-nav__list.is-open {
        max-height: unset;
        overflow: initial;
    }
}

JavaScript : gestion de l’état « ouvert »

const navToggle = document.querySelector('.main-nav__toggle');
const navList = document.querySelector('#main-menu');

if (navToggle && navList) {
    navToggle.addEventListener('click', () => {
        const isOpen = navToggle.getAttribute('aria-expanded') === 'true';
        navToggle.setAttribute('aria-expanded', String(!isOpen));
        navList.classList.toggle('is-open', !isOpen);
    });
}

Ce petit script suffit amplement pour un menu responsive classique, tout en respectant les attributs ARIA pour les lecteurs d’écran. Des implémentations plus avancées peuvent gérer le focus, l’échappement au clavier ou les sous-menus (dropdown, mega menu, etc.)

Accessibilité et UX, à ne surtout plus ignorer

Si mon article d’origine se concentrait surtout sur la technique des sprites et l’optimisation des requêtes HTTP, un menu moderne doit aussi intégrer de vraies bonnes pratiques d’accessibilité (et on aurait dû s’en rendre compte déjà à l’époque des mises en page en <table> ).

Quelques points clés :

• Utiliser des textes visibles plutôt que de les masquer derrière une image.
• Prévoir des styles de :focus-visible suffisamment contrastés pour la navigation clavier.
• S’assurer que le contraste texte/fond est suffisant pour une lecture confortable.
• Gérer l’état actif (aria-current="page") pour que l’utilisateur sache où il se trouve.

17 ans de progrès en un menu

En 2009, les sprites CSS étaient une astuce magique pour booster les performances d’un menu horizontal un peu « design ». Aujourd’hui, grâce à Flexbox, SVG, des CSS modernes et un peu de JavaScript (bye jQuery ! ), on obtient un résultat plus performant, plus accessible et infiniment plus maintenable.

See the Pen Untitled by Ange Chierchia (@nighcrawl) on CodePen.

Alors là, je dois dire que @scope me parle vraiment. J’ai passé des années à jongler avec BEM, SMACSS, et toutes ces conventions de nommage qui finissent par te donner l’impression d’écrire du morse plutôt que du CSS. L’idée de pouvoir scoper du CSS natif sans avoir à préfixer chaque classe avec le nom du composant trois fois, c’est exactement ce qu’il me fallait.

Ce qui me botte, c’est que ça reste lisible. Pas de .card__header–modifier à rallonge. Juste du CSS qui dit clairement “ça s’applique dans ce contexte, point final”. Et le support navigateur est déjà là pour une bonne partie. Bon, évidemment, il faut un peu de temps pour que tout le monde suive, mais l’approche progressive me va bien.

Je pense tester ça sur mon prochain side project, histoire de voir comment ça se comporte dans la vraie vie. Parce qu’en vrai, les conventions c’est bien, mais si le langage peut gérer le problème nativement, pourquoi se compliquer la vie ?

Ça fait deux semaines que j’utilise Windsurf pour développer un plugin WordPress.
Le principe ? Ajouter des options sur les blocs Gutenberg natifs (en React/JSX), et gérer des Custom Post Types proprement.

Rien de dingue sur le papier.
Mais en vrai, c’est le genre de projet où tu te retrouves vite avec du code front mélangé au code métier, des fichiers qui grossissent, et un moment où tu te demandes « mais pourquoi j’ai foutu ça là ? ».

Avant, j’aurais passé une journée entière à refactoriser pour que ce soit propre.
Là, j’ai tenté de faire équipe avec l’IA.

Spoiler : c’est ni parfait, ni magique. Mais franchement, c’est troublant.

Le moment où j’ai compris que c’était différent

Au début, je lui ai juste balancé :

« J’ai du code pour étendre des blocs Gutenberg. Aide-moi à séparer proprement le front-end de la logique métier. »

Windsurf ne m’a pas juste craché trois suggestions de fonctions.
Il a réorganisé des fichiers.
Il a créé des dossiers, proposé une archi, déplacé du code React d’un côté, les enregistrements de CPT de l’autre.

Pas parfait, hein. Mais cohérent.

Et moi, pendant ce temps, je ne codais presque pas.
Je lisais, je validais, je virais ce qui ne me plaisait pas.

C’est là que j’ai senti le truc : je n’étais plus vraiment en train de « coder ».
J’étais en train de piloter.

Font Awesome sur les boutons : ou comment j’ai réécrit mes prompts 15 fois

Le truc qui m’a le plus pris la tête, c’est l’ajout d’icônes Font Awesome sur les blocs core/button.

Sur le papier, c’est simple :
tu rajoutes un control dans le panneau Gutenberg, tu laisses l’utilisateur choisir une icône, tu l’affiches côté front avec la bonne classe Font Awesome.

Dans la réalité ?
Windsurf m’a sorti :

• Des contrôles Gutenberg qui ne compilaient pas.
• Des attributs qui disparaissaient au save/reload.
• Du JSX bancal avec des icônes qui se dupliquaient ou qui partaient dans le mauvais sens.
• Une fois, il m’a même proposé d’importer tout Font Awesome en JS côté éditeur (merci, mais non).

Le problème, c’est que je lui demandais des trucs trop vagues.
Genre :

« Ajoute une option pour choisir une icône Font Awesome. »

Résultat : il partait dans tous les sens.

J’ai dû affiner. Beaucoup.
Jusqu’à arriver à des prompts du style :

« Ajoute un SelectControl dans InspectorControls pour choisir parmi 5 icônes Font Awesome.
L’attribut doit s’appeler faIcon, de type string.
L’icône doit s’afficher avant le texte du bouton, côté front uniquement, avec la classe fa-solid fa-{nomIcone}. »

Là, ça commençait à tourner.

Mais j’ai quand même dû tout recommencer à zéro une fois, parce qu’il m’avait généré une logique tellement tordue que je ne m’y retrouvais plus.

Ce que j’ai appris : parler à une IA, c’est un métier

Ce qui m’a le plus marqué, c’est à quel point la façon dont tu poses la question change tout.

Si tu dis :
« Fais-moi un truc pour gérer des icônes »,
tu obtiens du code générique, verbeux, à moitié cassé.

Si tu dis :
« Crée un attribut faIcon de type string, ajoute un SelectControl avec 5 options fixes, affiche l’icône en <i> avec la classe correspondante dans le RichText »,
là, ça roule.

Et ça, pour moi, c’est nouveau.
Avant, coder, c’était : je sais ce que je veux, je le tape.
Maintenant, c’est : je sais ce que je veux, j’apprends à le formuler pour qu’une IA le fasse.

C’est presque un exercice de specs en temps réel.
Et franchement, ça m’a forcé à être plus clair dans ma tête sur ce que je voulais vraiment.

La structure du plugin : là où l’IA m’a vraiment aidé

Ce qui est cool, c’est que Windsurf m’a aidé à mettre en place une archi propre dès le début.

Avant, j’aurais fait un gros index.php, un dossier assets, et je me serais dit « je rangerai plus tard ».
Jamais fait, évidemment.

Là, il m’a proposé direct :

• Un dossier src/blocks pour tout le code React/JSX qui étend les blocs Gutenberg.
• Un dossier includes pour les CPT et la logique métier.
• Un build propre avec webpack (enfin… plus ou moins propre, j’ai dû ajuster).
• Une séparation claire entre ce qui tourne côté éditeur et ce qui se charge côté front.

C’est pas révolutionnaire.
Mais c’est exactement ce que j’aurais dû faire depuis le début, et que je faisais jamais par flemme.

L’IA m’a forcé à être structuré dès le départ, parce qu’elle avait besoin de comprendre où mettre les fichiers.

Et résultat : mon code est plus maintenable. Plus facile à relire. Moins bordélique.

Les moments de frustration (parce qu’il y en a)

Je ne vais pas mentir : il y a eu des phases où j’ai eu envie de tout fermer et de retourner coder comme avant.

Genre :

• Quand l’IA me modifiait 4 fichiers alors que je lui avais demandé d’en toucher qu’un.
• Quand elle « corrigeait » du JSX qui marchait très bien, merci.
• Quand elle m’inventait des hooks React qui n’existent pas, et que je perdais 20 minutes à comprendre pourquoi ça plantait.

Il y a aussi ce moment bizarre où tu te rends compte que tu lis plus de code que tu n’en écris.
Et parfois, ça frustre.
Parce que coder, c’est pas juste produire du code. C’est aussi réfléchir, tâtonner, trouver des solutions.

Avec l’IA, tu sautes une partie de ce process.
Des fois c’est génial.
Des fois, tu te sens un peu… spectateur.

Ce que je retiens après deux semaines

Windsurf, c’est un outil de structure avant tout.
Il te force à penser ton projet proprement, parce qu’il a besoin de comprendre où il met les pieds.

C’est aussi un amplificateur de clarté mentale.
Si tu ne sais pas vraiment ce que tu veux, il va partir en vrille.
Si tu es clair, il va vite.

Mais ça reste un assistant, pas un dev.
Tu ne peux pas lui laisser la main sur tout.
Surtout si tu fais du React/JSX un peu poussé, ou si tu touches à des trucs sensibles (attributs Gutenberg, save/edit, etc.).

Le truc à retenir ?
L’IA produit le squelette. Toi, tu mets la chair.

Et franchement, pour l’instant, ça me va bien comme ça.

Et toi, t’en es où ?

Je suis curieux de savoir si d’autres devs WordPress ont testé ce genre d’outils sur des projets Gutenberg.
Parce que franchement, entre le JSX, les attributs, le save vs edit, et tout le bordel de la compilation… c’est pas toujours évident de savoir ce qu’on peut déléguer à l’IA et ce qu’il vaut mieux garder sous contrôle.

Si t’as des retours d’expérience, des prompts qui marchent bien (ou qui partent complètement en couille), ou juste une opinion tranchée sur le fait de coder avec une IA, balance-moi ça.

Parce qu’au fond, on est tous un peu en train d’apprendre ensemble comment bosser avec ces trucs-là.
Et autant partager les galères, non ?

J’ai fais le fifou ce week-end ! J’en avais un peu marre des couleurs de mon blog, alors j’ai un tout petit peu rafraîchi tout ça ! Et en prime j’ai utilisé ma couleur préférée #vismavie #osef

Andy Bell propose une solution élégante pour contourner l’interdiction HTML d’imbriquer des éléments interactifs : créer une fausse zone cliquable qui reste accessible. L’idée, c’est d’utiliser un pseudo-élément positionné en absolu qui couvre toute la card, tout en gardant les vrais boutons ou liens interactifs au-dessus via z-index. Ça évite le balisage dégueu avec des <div> cliquables partout.

Ce qui me plaît, c’est que ça reste propre côté DOM et que l’accessibilité n’est pas sacrifiée sur l’autel du design. Pas de role="button" sur des trucs qui n’en sont pas, pas de JavaScript tarabiscoté pour gérer les clics. Juste du CSS malin et un peu de réflexion sur la hiérarchie des interactions.

Bon, faut quand même faire gaffe : si tu multiplies les zones cliquables imbriquées, ça peut vite devenir le bordel pour l’utilisateur. Mais pour une card avec un lien principal et quelques actions secondaires, c’est nickel. Andy donne même un exemple concret avec du code commenté, ce qui aide à bien piger la mécanique. Bref, une technique à garder dans un coin.

On a tous galéré avec `Date()` en JavaScript. Les fuseaux horaires qui décalent tout, les calculs foireux, les librairies tierces pour compenser. Bref, un bordel.

Temporal arrive enfin pour régler ça. Une API moderne, pensée dès le départ pour gérer proprement les dates, heures, durées et fuseaux. Fini de bidouiller avec des +86400000 pour ajouter un jour, fini les bugs silencieux quand on change de timezone.

Ce qui me plaît surtout, c’est la clarté : `Temporal.PlainDate`, `Temporal.ZonedDateTime`, `Temporal.Duration`… Chaque type a son rôle, pas d’ambiguïté. Tu sais ce que tu manipules. Et les méthodes sont intuitives, cohérentes.

Le support navigateur progresse doucement, mais ça vaut le coup de s’y intéresser maintenant. Parce que franchement, quand ça sera là partout, on se demandera comment on a pu vivre avec l’ancien système.

Quand j’ai lu le billet du gars de LapcatSoftware, j’ai eu ce petit frisson “yeah, ça, ça a du sens”.

Il explique qu’il vaut mieux désactiver les pointer-events sur les images utilisées comme liens — notamment les badges “Download on the App Store”. Sur iOS, la feature « Live Text » crée un bordel : quand tu tapes longuement sur l’image, tu tombes sur… la sélection de texte, pas le lien. Résultat, l’UX est foirée pour les utilisateurs de Safari iOS. 

Alors le taf, c’est simple : tu rends l’image non-clickable (pointer-events: none;) et tu t’assures que l’anchor parent a un display: inline-block — comme ça le lien est cliquable sur toute la surface de l’image, comme un lien normal. 

Moi ce que j’aime, c’est ce genre de petit coup de polish à la dev front-end : ça prend 2 secondes, mais ça améliore l’expérience utilisateur — surtout sur mobile. Si t’es comme moi, “pixel perfect” ça te parle. Le genre de détail qu’on zappe souvent, mais qui compte.

Andy Bell balance des principes solides pour les autodidactes du front. J’aime bien son approche parce qu’elle casse l’idée qu’il faut tout savoir pour être légitime. Il insiste sur la simplicité d’abord, les fondamentaux avant les frameworks, et surtout : résoudre des vrais problèmes plutôt que d’accumuler des technos sur son CV.

Ce qui me parle le plus, c’est son conseil de pas se laisser impressionner par la complexité des autres. On a tous tendance à croire que les devs « officiels » maîtrisent tout sur le bout des doigts, alors qu’en vrai, personne ne sait tout. L’impostor syndrome, ça touche tout le monde, diplômé ou pas.

Il rappelle aussi qu’être autodidacte, c’est souvent avoir développé une capacité d’apprentissage autonome qui vaut de l’or. Ça forge une débrouillardise que les cursus classiques n’offrent pas toujours. Bref, un article qui fait du bien à l’ego et qui recentre sur l’essentiel : construire des trucs qui marchent, proprement.