nota-bene.org > Sur le web > Le problème de position:fixed

Le problème de position:fixed

À propos de cet article

Un article de Stéphane

Publié le 28 janvier 2011

URL courte : http://nota-bene.org/405

16 commentaires

Mots-clés (tags)

, ,

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

    • 28 janvier 2011

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

    Répondre à Pascale

    • 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 clin d'œil

    Répondre à goetsu

    • 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 langue tirée 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

    • 28 janvier 2011

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

    Répondre à Nicolas Hoizey

    • 28 janvier 2011

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

    Répondre à Pascale

  • Décidément Nicolas, ce n’est pas ton jour sourire

    Répondre à Stéphane

    • 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

    • 28 janvier 2011

    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

    • 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

    • 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

    • 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

    • 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

    • 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

    • 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

    • 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

    • 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

Qui êtes-vous ?
Votre message
  • Pour créer des paragraphes, laissez simplement des lignes vides. Tous les liens sortants comporteront un attribut rel="nofollow". Merci de ne pas spammer.

Ceci est la version Bureau Afficher la version Mobile