Benjamin De Cock nous fait cadeau d'un très bon article sur le positionnement CSS: Maîtriser le positionnement CSS dans toutes les situations, sous-titré «Comprendre le positionnement CSS et opter pour des choix adaptés à des situations précises».
Il ne faut cependant pas voir dans cet article une «bible» du positionnement CSS. Il n'est pas exhaustif et ne cherche pas à l'être. Il s'agit essentiellement d'illustrer une démarche qui consiste à faire des choix rationnels en matière de positionnement CSS. Quelle option de positionnement choisir parmi les différentes possibilités? Benjamin propose la logique suivante:
- Tant que cela est possible, on gardera les éléments dans le flux (
position: static; float: none;). - Si le positionnement en flux ne suffit pas (par exemple lorsqu'il faut mettre côte à côte deux blocs), on utilisera la propriété
positionet notamment le positionnement absolu, sauf lorsque les conséquences de ce positionnement ne sont pas gérables. - Enfin, si l'utilisation de
positionne convient pas, on pourra utiliser la propriétéfloat, en se rappelant qu'elle n'est pas initialement prévue pour les usages qu'on en fait (ce qui explique quelques difficultés connues de ceux qui sont coutumiers des flottants).
Ça se discute…
Comme tout parti-pris, celui-ci ne fera sans doute pas l'unanimité. Comme l'indique une première réaction que je me permet de citer:
(…) les solutions proposées en utilisant le positionnement absolu prennent des hypothèses très fortes qui sont en contradiction avec un site dynamique ou le contenu n'est pas maitrisé. (…)
Ces contraintes me semble également difficilement gérables dans un contexte de réutilisation des CSS.
Une observation qui me semble très juste. Nul doute que Benjamin apportera quelques précisions sur ces points. :)
On aurait pu rajouter que…
La propriété position a beau être davantage prévue pour positionner les principaux blocs d'une page que la propriété float, elle ne représente pas forcément la meilleure solution offerte par la spécification CSS 2 pour juxtaposer des blocs[1]. Dans l'absolu, on devrait plutôt utiliser en priorité:
display: inline-block;display: table-cell;
Nous ne les utilisons pas ou peu car ces valeurs de la propriété display[2] sont mal supportées par les navigateurs. La valeur inline-block n'est pas supportée par Firefox jusqu'à la version 2 (la version 3, actuellement en beta, corrige enfin le tir!) et partiellement supportée par Internet Explorer (version 7 incluse)[3]. Les valeurs table, table-row et surtout table-cell ne sont pas supportées par Internet Explorer (version 7 incluse).
On gardera toutefois ces options en tête. Il se pourrait qu'elles soient, d'ici quelques années, des solutions de choix largement utilisables, tandis que l'utilisation extensive des flottants sera considérée comme une relique du passé. ;)
Notes
[1] C'est à dire mettre des blocs côte à côte horizontalement: c'est l'utilisation la plus courante du positionnement CSS.
[2] Vous connaissez sans doute déjà display: block, display: inline et peut-être aussi display: none.
[3] Pour plus de précisions, on pourra lire Cross Browser Support for inline-block Styling.
Commentaires
Doit-ton reellement penser que les flotants passeront à la trappe?
Certes il est possible d'utiliser d'autres attributs, mais les flotants permettent de positionner facilement des elements sans se soucier de leurs tailles.
Plutot que les attributs display, ne faudrat-t-il pas, dans le futur , privilégier les colonnes (css3) pour le positionnement?
Pour réagir brièvement à la remarque judicieuse de Lambo, je préciserai juste deux points qui semblent confus.
Premièrement, les sites entièrement dynamiques et dont la projection visuelle future relève entièrement de l'inconnue demeurent — à mon sens — exceptionnels dans le sens où ils soulèvent une lacune hiérarchique évidente et probablement une carence ergonomique associée.
Ensuite, dans le cas de figure précédent, et uniquement dans ce cas, je favorise ostensiblement le recours aux flottants — situation qui "peut" être courante selon le profil client de l'agence concernée.
Il n'est par ailleurs pas dans le dessein de cette méthodologie de travail de diaboliser un outil, ma foi, singulièrement efficace, détrompez-vous! : il relativise au contraire son champ d'application et, tant s'en faut, lui confère jusqu'à la place de choix pour un contexte précis dans l'attente d'un support acceptable des facultés diverses du display.
Le choix d'une méthode de positionnement assujetit l'intégrateur à une réflexion qui ne peut être automatisée et bipartite, à l'exemple d'une démarche d'accessibilité non binaire.
j'ajouterais que les l'utilisation de positionnement absolue entraine généralement beaucoup plus de problème lors du redimensionnement des caractères que les flottants.
bonjour,
perso, j'ai vraiment du mal à saisir en quoi un élément en position:relative; se trouve hors du flux ... même si il est précisé dans le tutoriel partiellement hors du flux..
du coup c'est quoi un élément dans le flux?
A la vue du titre de l'article puis du contenu du tutoriel, je trouve que les tutoriels d'alasacréations mériteraient une classification par niveau ; celui-ci étant plus complexe et nécessitant plus d'investissement qu'il ne le laisse paraitre (ce qui n'est pas un mal ;-))
@ bzh : Un élément positionné relativement reste dans le flux, même s'il peut subir des décalages.
@ goetsu : Veux-tu parler de l'agrandissement de la taille des polices ?
Hum... privilégier le positionnement absolu pose en effet des problèmes non négligeables:
- d'accessibilité (cf ci-dessus).
- sur le fond, avec cette idée suprenante selon laquelle "les sites entièrement dynamiques et dont la projection visuelle future relève entièrement de l'inconnue demeurent (...) exceptionnels dans le sens où ils soulèvent une lacune hiérarchique évidente et probablement une carence ergonomique associée". Le coup de la lacune évidente me laisse très songeur ;)
Le problème étant ici en fait de savoir quoi recommander comme méthode **simple**de mise en page, les designs hybrides à base de tableau restent encore un moindre mal, si l'on souhaite éviter les flottants dont la maîtrise est effectivement moins immédiate.
Cela dit, il est intéressant de voir se dégager de plus en plus deux "écoles" de mise en page (flottants ou positionnement renforcé par javascript). Même si l'art de la mise en page CSS est en réalité beaucoup moins tranché, évidemment ;)
(Dites, rien à voir, mais: on ne pourrait vraiment pas supprimer cette sottise exaspérante de captcha pour intellectuels ?)
Ah, un oubli : pour préciser l'un des problèmes d'accessibilité à propos de positionnement :
Celui-ci "...jouit du confort de ne pas dépendre de l'ordre dans lequel les éléments HTML sont déclarés dans le code".
Certes. Mais la question du degré de cohérence entre ordre linéaire HTML et ordre de lecture visuelle du contenu positionné avec CSS est très loin d'être tranchée quant à l'accessibilité.
Sachant que l'ordre linéaire est celui de nombreuses aides techniques, jusqu'à quel point peut-on, de manière accessible, "extraire" un élément de l'ordre du flux pour le "projeter" à un autre emplacement ?
Cette liberté donnée par le positionnement n'a pas encore son pendant côté implémentations dans les outils. Il est préférable d'en user avec modération ;)
"(Dites, rien à voir, mais: on ne pourrait vraiment pas supprimer cette sottise exaspérante de captcha pour intellectuels ?)"
> Non, comme déjà expliqué : le serveur actuel rend impossible les "simples" capchas visuel+alt.
Et supprimer complètement le capcha est tout simplement inimaginable, vu le nombre de spam.
Cet article a le mérite de pointer une ambiguité de CSS : à la fois outil de mise en page (positionnement d'objets) et outil de mise en forme (gestion des aspects, polices, couleurs). Si la fonction de mise en forme ne pose pas de problèmes majeurs dans tous les cas de restitution possible, celle de mise en page implique en revanche une prise en compte des surfaces sur lesquelles s'opéreront les restitutions. C'est là qu'il y a problème : on introduit un paramètre non-inclus dans le flux... et donc incontrôlable depuis celui-ci. Il y a un dialogue qui s'établit entre le flux et les surfaces disponibles, dialogue qui négocie la place de chaque objet. Or le contrôle de ce dialogue ne peut s'effectuer qu'en contrôlant également les surfaces, ce qui n'est pas donné dans tous les cas.
Si (ou tant que...) la feuille screen ne s'adressait qu'aux écrans d'ordinateurs les usages de CSS comme outil de mise en page pourraient être définis avec précision, les méthodes éprouvées et les résultats (presque) garantis, mais un certain nombre d'UA (des mobiles par exemple) utilisent également screen... Un désastre est donc toujours possible.
Les flottants sont ce qu'il y a de plus fragiles dans une mise en page. Ils sont parfois incontournables (quoique...) mais le positionnement absolue est beaucoup plus approprié pour une page dite accessible. Comme le dit si bien l'article (que j'applaudi des deux mains), un positionnement absolue ne nous oblige pas à ordonnées les différentes balises en fonction de l'apparence du site. C'est important quand on pense au lecteurs d'écran. Si un site n'a qu'un seul menu positionné à droite du contenu principal, dans le squelette xhtml, il faudra le placer en haut de page.
De plus, le flottant peut parfois bousiller tout un mise en page d'un navigateur à l'autre. 1 pixel en trop et tout passe en dessous sous IE (quelle poisse).
Le positionnement absolue est en quelque sorte une garantie que notre site passera bien dans la plupart des navigateurs à conditions d'avoir bien défini les balises en position relative.
Toute la complexité réside en fait dans l'organisation des marges pour combler les vides puisque que les différents calques positionné en absolu ne sont plus dans le flux.
Dans mes réalisations web, je m'efforce d'utiliser au maximum les positionnements absolu qui m'évite de recourir à des hacks en tout genre comme c'est souvent le cas pour les flottant.
Salut,
Juste une précision. Pour l'exemple avec le conteneur wrap et l'overflow placé à hidden, cela bloque le défilement de la page pour les ie versions 5 et 5.5.
Je ne sais pas si dans le monde pro, on prend toujours en compte ces versions d'ie mais cela peut poser un problème lors de la création de la page.
"soulèvent une lacune hiérarchique évidente et probablement une carence ergonomique associée."
N'ayant lu le tuto qu'aujourd'hui, j'interviens un peu tard, mais faudrait expliciter un peu ce genre de propos et ce que tu entends exactement par "lacune hiérarchique" qui ne sont d'ailleurs évidentes que de ton point de vue à toi...
Pareil pour les carences ergonomiques, tu ne prouves rien.