Le problème de position:fixed

Les feuilles de style, c’est vraiment terrible. On peut faire des tas de fantaisies graphiques qui jusque-là nécessitaient soit d’ajouter du Javascript, soit de s’en passer alors qu’on aurait tellement envie de les mettre en place. position:fixed, ça y est, ça marche. Oui mais attention.

Il y a des bonnes idées en tout, et puis il y a de temps en temps des mauvaises surprises qui s’y associent.

Avec son aval, je vous propose de regarder en détail ce qui se passe sur la page « Mentions légales » de Jérémie.

Aspect technique

Les CSS nous permettent de spécifier, comme vous le savez, la position des éléments, leur inscription (ou pas) dans le flot du document relative aux éléments qui les précèdent et les suivent, bref de faire de grandes choses sans quoi nous serions encore en train d’empiler les balises de tables et de pleurer pour les maintenir.

En guise de positions, on trouve plusieurs réglages :

  • le réglage implicite, c’est un genre de relative mais qui ne conditionne pas la position de ses enfants (je ne m’étale pas, on n’est pas ici pour ça pour le moment) ;
  • relative : nous permet de préciser que la position (si on n’y touche pas) est exactement relative à l’endroit où est l’élément dans le flot. C’est intéressant, si on le couple avec des réglages de décalage (top et left) pour le promener un peu mais sans vraiment bousculer l’ensemble ;
  • absolute : sort l’élément du flux, et le dépose à un endroit défini par ses coordonnées en x/y dans le document. Bien pratique pour faire des menus déroulants ;
  • fixed : celui qui nous intéresse. Un élément dont la position est fixée se comporte comme un élément de position absolue, mais il se repère sur l’espace d’affichage du navigateur (son nom de code c’est viewport).

Ce dernier mode, qu’on n’utilisait pas forcément jusqu’à récemment (la faute à Internet Explorer qui l’interprétait comme une position absolue jusqu’à sa version 7), se répand maintenant tranquillement.

Un cas concret chez Jérémie

L’ami Jérémie, qui a un goût très sûr, a décidé de positionner l’en-tête et le pied de page de son site en fixed. C’est chouette, un peu comme la bande noire au cinéma, j’aime bien.

Quand on fait défiler le site avec la petite mollette de souris qui va bien, c’est vraiment super. Oui mais, vous me connaissez, moi j’utilise le clavier.

Comment fait-on défiler une page au clavier ?

  1. on appuie sur flèche bas : c’est lent ;
  2. on appuie sur espace ou sur Page Down : c’est plus rapide, on saute à chaque fois d’une page d’affichage à la suivante.

C’est là qu’est l’os, hélas [1]. Car si mon navigateur défile d’un coup d’une page entière, mais qu’une partie de cette page est cachée, je vais donc d’un seul coup ne pas lire les quelques dernières lignes qui étaient cachées sous la bande du bas, puis ne pas lire les quelques dernières lignes qui sont cachées sous la bande du haut.

Magie de l’internet, avec un doigt, sans souris, je fais défiler la page :

Le haut de page...
... et un cran plus bas

Au lieu de lire :

Dans l’éventualité ou je ne donnerai pas suite à vos sollicitations, la loi vous permet de vous adresser directement à l’hébergeur :

  • Par courrier à l’adresse précédemment cité.
  • Par e-mail à [adresse mail]

Je lis, comme vous pouvez le constater sur les saisies d’écran ci-dessus :

Dans l’éventualité ou je ne donnerai pas suite à vos sollicitations, la loi vous permet de vous

un petit coup sur la barre espace et je saute à :

  • Par e-mail à [adresse mail]

Me voilà fort marri.

Dans un commentaire, Michel V. se plaignait exactement de ce problème : il faut, après avoir fait défiler une page, appuyer en rafale sur la flèche haut pour lire les lignes qu’on a manquées. C’est rageant, quand il s’agit de le faire quinze fois de suite.

Y a-t-il une solution simple ? J’ai peur que non. Cet article ne souhaite que vous alerter sur le risque de grand inconfort pour les gens qui n’utilisent pas systématiquement de souris [2], et ils sont plus nombreux qu’on ne le pense.

Je ne vous dis pas de ne jamais utiliser la position:fixed, mais j’ai l’impression que certains usages, magnifiques « sur le papier » comme c’est le cas ici, se heurtent douloureusement au quotidien.

Encore une fois, merci à Jérémie de m’avoir permis de le prendre comme exemple.

Notes

[1Je suis sûr de vous l’avoir déjà placée, celle-là, ces derniers temps ; mais je l’aime bien. Le cinéma de papa est mon chouchou.

[2Tenez, par exemple, j’écris ces lignes avec un ordinateur sur les genoux, dans un train, et un trackpad défectueux qui me force à ne l’utiliser qu’en dernier recours et qui ne marche correctement que les jours de pleine lune ; et encore, uniquement les années bisextiles.

Commentaires

  • Pascale (28 janvier 2011)

    Ah ouais... Même problème chez moi ! pfffff O_o

    Répondre à Pascale

  • goetsu (28 janvier 2011)

    ça doit etre faisable avec un peu de js qui va :

    • prendre la taille du viewport, soustraire la taille de tes éléments en position fixed
    • positionner correctement la scrollbar sur le onkeypress correspondant au pagedown, pageup

    Simple non ;)

    Répondre à goetsu

  • karl (28 janvier 2011)

    ce qui est drôle avec le commentaire de Pascale, c’est qu’elle m’avait fait le reproche pour La Grange :p dans le passé et que j’ai fini par l’enlever pour cette exacte raison de navigation au clavier.

    Je pense qu’il y a une opportunité pour les fabricants de navigateur.

    Tiens d’ailleurs si tu veux t’amuser à tester. l’accessibilité dans les listes en overflow dans la page karl

    http://www.la-grange.net/karl/#ailleurs

    Répondre à karl

  • Nicolas Hoizey (28 janvier 2011)

    Zut, pareil chez moi aussi, avec la navigation qui passe en position: fixed; quand on descend ! 🙁

    Répondre à Nicolas Hoizey

  • Pascale (28 janvier 2011)

    Ce qui est pénible avec Karl, c’est qu’il a de la mémoire ! 😄

    Répondre à Pascale

  • Stéphane (28 janvier 2011, en réponse à Nicolas Hoizey)

    Décidément Nicolas, ce n’est pas ton jour :)

    Répondre à Stéphane

  • Nicolas Chambrier (28 janvier 2011)

    En fait une bonne solution serait donc de conserver ce genre de positionnement pour les menus latéraux. Et si on veut le mettre en place pour une barre horizontale, je vois plusieurs solutions (toutes basées sur du JS) :
    * Reformater pour que ça ne soit plus une barre horizontale, mais un élément latéral.
    * Jouer de la transparence : une transparence à 90% par défaut, et qui passe à 0% au rollover ou au focus, mais si ça répond au problème de lecture je ne suis pas convaincu du côté ergonomique de la chose.

    Répondre à Nicolas Chambrier

  • Une variante de ce problème, plus grave encore : quand un élément en position:fixed occupe le haut de la page (ne serait-ce que sur 10px de haut) et que le navigateur défile la page jusqu’à une ancre, le contenu cible se retrouve sous l’élément en position:fixed, donc masqué.

    En passant, la valeur par défaut pour position, c’est "static".

    Répondre à fvsch

  • Autre problème de position:fixedStéphane (28 janvier 2011, en réponse à fvsch)

    Oui tiens je n’ai pas parlé de l’ancre, qui me chagrine pourtant assez souvent.

    Effectivement c’est static la valeur par défaut de position, c’est le mot que je cherchais mais comme il est implicite on l’utilise forcément peu, et il m’échappait au moment de l’écriture de ces lignes (je tape mes articles en déconnecté dans le train).

    Répondre à Stéphane

  • Anthony (28 janvier 2011)

    On retrouve le même problème aussi lorsque l’on utilise la recherche de son navigateur. Le mot cherché est là mais caché par un élément en position:fixed.

    Autre point, c’est actuellement le foutoir sur mobile ce position : fixed. Plein de raisons pour ça, assez bien résumées par PPK, avec des solutions potentielles ->
    http://www.quirksmode.org/blog/archives/2010/12/the_fifth_posit.html

    Mais tout de même, je l’aime bien ce position : fixed pour tout ce qui ressemble à des notifications. Ça te permet d’accrocher temporairement un message à la fenêtre.

    Ou encore les boites à outils, ça te permet d’avoir des actions fréquemment utilisées à portée de souris.

    Répondre à Anthony

  • STPo (31 janvier 2011)

    Je n’ai pas lu le lien de Rik qui semble aborder le sujet mais pour moi le vrai problème de la position:fixed c’est la taille des viewports : un écran trop petit et un contenu en fixed trop "haut" et c’est la fin du site (je ne parle même plus d’inconfort là, c’est tout simplement PAS UTILISABLE DU TOUT). C’est hyper dangereux, à utiliser avec circonspection, je me casse la tête sur un de ces cas d’école en ce moment-même.

    Le pire que j’aie vu jusqu’à présent étant les popins démesurés dont on ne PEUT pas atteindre le bouton "fermer" sur les petits écrans : argh.

    Répondre à STPo

  • eleg (31 janvier 2011)

    Bonjour,

    Ne « suffit-il pas »* pour le problème de l’ancre <a name="toto">… appelée de la décaler /en css/ (p. ex. avec une position relative) vers le haut de la hauteur de l’élément qui est en position fixée (p. ex. 3 em) ?

    quelque chose comme :

    a[name] { position: relative; top: -3em;}

    Bon, après, si vous insistez pour utiliser les IDs, on n’est pas sorti de l’auberge…

    * précaution oratoire

    Répondre à eleg

  • gaby (4 février 2011, en réponse à eleg)

    Bonjour,
    Je ne pense pas avoir fait quelque chose de très spécial avec :
    div#navbar position : fixed ; top : 74px ; right : 0 ; white-space : nowrap ; padding : 1px 0 2px 32px ; background :#F0DFB4 url(images/tab-curve3.jpg) bottom left no-repeat ; font-size : 0.9em ;
    et pourtant ça marche avec 1E8,
    voir cette page :
    http://www.camping-car-monde.fr/danube/index.php
    a+

    Répondre à gaby

  • STPo (5 février 2011, en réponse à gaby)

    @gaby
    Ton argument est invalide parce que tu utilises de la Comic Sans MS !

    Répondre à STPo

  • Emmanuel Clément (18 février 2011)

    Ah mais en voilà une idée intéressante !
    La visionneuse de livre utilisée par OpenLibrary comporte elle aussi 2 barres de navigation haute et basse.
    http://www.archive.org/stream/writingilluminat00johnuoft#page/n7/mode/2up
    En bas à droite, la flèche verticale (show/hide nav bar) permet d’enlever les menus pour profiter de tout l’espace de lecture. C’est une solution graphique élégante.
    Il faudrait voir comment cela pourrait être réalisé de façon accessible sur le site de Jérémie. Même non 100% accessible, un JavaScript serait sans doute une première solution permettant de montrer/cacher les barres par exemple.

    Répondre à Emmanuel Clément

  • Nicolas Hoizey (11 avril 2011)

    Bon, j’ai finalement viré mon bandeau de navigation qui se fixait lorsqu’on descendait.

    Outre le problème indiqué dans ce billet, qui suffit à détruire le concept, il posait un (petit) problème de performance.

    Je devais vérifier toutes les 100 millisecondes si la position de scroll avait changée, pour basculer entre position fixed ou non. Bin oui, c’était du fixed uniquement après un certain scroll. C’était du plus bel effet. Snif.

    Et encore, c’était pire avant, c’était sur l’événement JavaScript window.onscroll que c’était traité, heureusement que John m’avait remis dans le droit chemin...

    Répondre à Nicolas Hoizey

  • un petit proute (15 avril 2023)

    j’ai un problème... je suis en train de créer un site web pour héberger un bot discord. j’ai fais une barre de navigation fixée qui me permet de naviguer dans le site, mais après que j’ai centré un élément (sans lui mettre de "position") et ma barre de navigation n’est plus fixée.

    Comment faire pour "refixer" ma barre de navigation ?

    Merci d’avance

    Répondre à un petit proute

Qui êtes-vous ?
Votre message

Ce formulaire accepte les raccourcis SPIP [->url] {{gras}} {italique} <quote> <code> et le code HTML <q> <del> <ins>. Pour créer des paragraphes, laissez simplement des lignes vides.

Lien hypertexte

(Si votre message se réfère à un article publié sur le Web, ou à une page fournissant plus d’informations, vous pouvez indiquer ci-après le titre de la page et son adresse.)