Beaucoup de sites web présentent une mise en page sur trois colonnes, avec une colonne centrale de contenu et des colonnes latérales.
Ce tutoriel, rédigé par Florent Verschelde montre comment on peut utiliser les flottants pour réaliser ce type de mise en page, en largeur fixe ou fluide.
Au menu :
- Mise en place des trois « colonnes » (habillage, positionnement, rappel sur le positionnement flottant)
- Des marges latérales pour empêcher la colonne centrale de se glisser sous les flottants
- Forcer le bloc central à « fuir » les flottants avec un contexte de formatage (bugs IE)
- Quelle technique utiliser : marges ou contexte de formatage ?
- Aller plus loin : Comment faire des colonnes de même hauteur ?
Bon appétit ! :D
Commentaires
Très sympa :-) cependant il n'aurait pas mieux vallu que le <div id="contenu"></div> soit placé avant les divs des colonnes ?
Interressant.
N'y a t-il pas aussi la possibilité de faire simplement 3 float : left pour avoir 3 colonnes ? :p
"N'y a t-il pas aussi la possibilité de faire simplement 3 float : left pour avoir 3 colonnes ? :p"
-> Pas pour un site de largeur fluide... ou alors il faudra indiquer une largeur en % pour chacune des colonnes ce qui n'est pas souhaitable.
Si on veut utiliser trois "float:left" pour les trois colonnes, on procèdera ainsi :
- on aura un site en largeur fixe (en pixels) et des colonnes en largeur fixe également, ou bien un site en largeur fluide et des colonnes avec des largeurs en pourcentages ;
- on évitera caser pile poil trois flottants dans le conteneur (body ou autre conteneur global), car ça peut être problématique avec certains navigateurs... on aura donc les deux premiers blocs flottants, et le troisième bloc (colonne de droite) sera non flottant, avec... une marge ou un contexte de formatage.
Bref, on fera une variante du tutoriel. :D
Très bonne synthèse. Bravo Florent.
Sinon, la question de l'anti-spam était "combien faut-il de kiwis pour faire une omelette ?"... Sgmbl, elle est particulièrement déroutante, celle-là. Je continue à trouver ce système plus nuisible qu'une captcha graphique doublée d'un envoi de commentaire par mail, ou d'une publication modérée a priori en l'absence de réponse à la captcha...
<edit>Au moins, la question idiote ne pourrait elle pas être enlevée une fois atteint le stade de la prévisualisation ? Parce que deux questions différentes à la suite, franchement, non.</>
Petit détail: dans le strict respect de WCAG12.0, dans un avenir incertain, chaque question idiote devra, pour être accessible, correspondre à un niveau déterminé de connaissances scolaires... Là j'ai la tour de Pise... Je me pose à la fois des questions le bien-fondé de ce point typiquement anglo-saxon de WCAG2.0, et sur la possibilité de valider la Tour de Pise d'après les programmes scolaires français. Ou sur l'absurdité de la situtation ainsi créée.
@Laurent > pour toutes les modifs en profondeur du code et des plugins de Dotclear, on serait tous ravis d'avoir des experts qui nous bidouilleraient un truc parfait.
On sait tous que ce n'est pas le cas, mais le gain en terme d'anti-spam est d'une importance que tu ne soupçonnes même pas.
Je te sens un peu agacé, là ? Il ne faut pas. Si je reviens sur ce point, c'est qu'il est contradictoire avec la promotion de l'accessibilité.
Sans chercher la solution parfaite car illusoire, la captcha graphique n'est pas problématique pour l'accessibilité dès lors qu'une alternative accessible est fourni (cf ci-dessus). De même, le système de questions appliqué ici n'a pas d'alternative accessible: Ajoute-lui cette alternative avec un simple lien mail au minimum, pour faire au plus simple.
Sinon, je soupçonne assez bien, tu sais ? ;)
Agacé ? Que nenni :)
Blasé peut-être, et Sincère sans-aucun doute : lorsque je dis que je n'ai pas les compétences pour modifier DC en profondeur et appliquer tes recommandations, c'est tout à fait vrai.
Et lorsque je dis que toute aide serait bienvenue, c'est également vrai.
J'ai l'impression que tout ce que j'essaye de mettre en place pour combattre le fléau de robots-spammeurs "à mon niveau" est mal.
Bref, je prends note de tes remarques... tout en sachant que je ne pourrais pas changer grand-chose.
Note également qu'à un moment, il faut également savoir "se lâcher" un peu. Cela a toujours été le cas sur Alsa et les questions-captcha qui parlent de kiwis vont dans ce sens de vouloir joindre l'utile à l'agréable.
A un moment, à force d'ajouter toutes les alternatives nécessaires, cela devient de plus en plus complexe et de moins en moins intuitif : si je pouvais me passer de ces captcha, je l'aurais fait depuis longtemps.
Super tutoriel. C'est un peu le tuto que j'attendais qui remédie au tableau de trois colonnes utilisé uniquement pour la mise en page.
Rapahël, je dis simplement que bloquer des robots, pour l'anti-flood ou l'antispam, via une captcha, c'est peut-être bien moins compliqué (les solutions clés en mains sont là) et on peut le gérer avec moins d'effets pervers.
Ces solutions de captacha graphique (sans excès sur le graphisme) sont économiques et efficaces. Il leur manque uniquement le contournement qui les rend accessibles:
- soit un lien vers un traitement par mail
- soit une publication différée
Il s'agit "simplement" (mot malheureux) de substituer au traitement uniquement robotisé des nuisances un traitement essentiellement robotisé, mais avec l'échapatoire "traitement personnalisé" qui sauve la mise pour les utilisateurs bloqués.
Cet échapparatoire a évidemment un coût de traitement et de déploiement. Ce coût est le coût social du spam, et il est inévitable: il faut bien que quelqu'un le paie. Mais il s'agit de savoir si les utilisateurs vont le porter seuls (solution actuelle), ou si les services en ligne vont le partager avec eux. J'aurais tendance à privilégier la répartition des coûts, pour ma part.
Cela requiert des moyens humains. Dans le cas d'Alsa, j'ai eu, grâce à toi, abondamment l'occasion d'apprécier l'efficacité et la compétence de l'équipe de modération, qui est parfaitement à même de faire la part de traitement manuel de ces problèmes. Et puis, ça les empêchera de s'endormir sur leurs lauriers :D
<flood>J'ai écrit "saucisse". Celle-là, au moins, j'ai compris et ce n'était pas trop compliqué.</>
<edit>Ah bah non, c'était pas "saucisse" qu'il voulait, malgré sa question; Je re-tente avec "écrivez "alsacreations" sans fautes" (faut de la patience, quand même, avouez...)...</>
<re-édit>Tu sais quoi ? Je fais beaucoup de fautes de typos, et je n'ajouterai pas que c'est parce que j'ai besoin de me relire après d'invitables difficultés sur mon clavier, liées à un handicap (je l'ai ajouté quand même). Ce bouzin est simplement dissuasif, voire, si j'étais démagogique, discriminatoire : chaque prévisualisation me demande une nouvelle saisie de question criptyque. Par pitié, ne la laisse que sur la première prévisualisation, quoi qu'il en soit: c'est bon, j'ai franchi l'épreuve, je suis un emm... par fonction, mais pas un robot de spam ;) </>
J'avoue que je rejoins Laurent concernant "le nombre de kiwis pour faire une omelette" ... j'ai eu le malheur de recharger la page, alors que j'avais au départ quelque chose de moins ambigu : "Combien font 18 + 4 ?" (déjà plus accessible au niveau élémentaire !)
Mais j'aurais aimé avoir aussi un avis concernant l'ordre des conteneurs dans le document. Certes, nous avons les raccourcis, mais ...
C'est un vieux débat ... mais comment se porte t-il en l'an 2007 et sur un web 2.0 ?
(Bon, ok, je retire le web 2.0 ...)
Bon, je sauvegarde ma prose, je répond "zero" et je poste ...
Merci pour ce tuto.
Mais il faut reconnaître que l'auteur évite soigneusement la principale difficulté de ce type de gabarits. A savoir les colonnes en pleine hauteur , c'est-à-dire avec un fonds de couleur allant du haut de la colonne au bas de la page.
"Mais il faut reconnaître que l'auteur évite soigneusement la principale difficulté de ce type de gabarits. A savoir les colonnes en pleine hauteur , c'est-à-dire avec un fonds de couleur allant du haut de la colonne au bas de la page."
-> Il me semble justement que toutes les pistes utiles sont évoquées en fin de tutoriel, à ce sujet, non ?
Salut Raphael (et tous les autres).
Peut-être une piste à creuser pour ton problème de captcha et d'anti-spam, le nouveau captcha baptisé reCAPTCHA. De plus, il me semble pas mal accessible car il fournit une version audio, une aide et une regénération du code si on ne le comprends pas.
recaptcha.net/learnmore.h...
Sinon, bon tutos, même si dans les exemples on ne voit pas les colonnes aller jusqu'en bas (toutes de la même hauteur)
"Il me semble justement que toutes les pistes utiles sont évoquées en fin de tutoriel, à ce sujet, non ?"
-> Oui évoquées. Et la solution des largeurs de colonne fixes en pixels ne saurait être pleinement satisfaisante. Et c'est là que se trouve LA difficulté de l'exercice.
Il me semble que sur ce point on peut déjà explorer 3 pistes :
- Utiliser des fonds de couleur globaux pour spécifier les couleurs de menu (désavantage : la hauteur de la colonne centrale doit idéalement être plus haute que la taille de fenêtre ; ce qui est généralment, mais pas toujours, le cas)
- Mélanger couleur de fonds et image de fond (globale). (désavantage : si la taille des cactères est augmentée la mise en page saute un peu mais sans gravité ; le contenu des colonnes (texte+arrière-plan) semble alors "déborder" sur le haut et rester identique au niveau inférieur)
- Abandonner les flottants et utiliser le positionnement absolu et "essayer d'utiliser" la hauteur en 100%. (désavatange : pas standard, pas pérenne, pas portable, très prise de tête...)
Perso j'utilise la 1ère solution, qui allie solidité et facilité de mise en œuvre.
Bonjour,
Je n'ai pas évité la difficulté des colonnes de même hauteur (sur toute la hauteur de la page, c'est encore un problème différent...), je me suis contenté de ne pas l'aborder. Ça n'était pas l'objet du tutoriel.
On pourrait d'ailleurs rédiger un second tutoriel qui aborderait ces subtilités.
À la fin du tutoriel, je fais un lien vers un exemple de colonnes (visuellement) de même hauteur avec les colonnes factices + sur toute la hauteur de la « page ». Ça demande de gérer pas mal de détails, et c'est effectivement limité, vu que ça impose des colonnes latérales de largeur fixe en pixels. On pourrait à la rigueur modifier un peu cette technique pour avoir une des deux colonnes en largeur fluide (en pourcentages). Mais là ça devient un traitement très spécifique et difficilement portable.
Quoi qu'il en soit, si on doit obtenir des colonnes de même hauteur et de largeur fluide, deux options :
- soit on maitrise globalement les CSS, et on pourra se pencher sur les subtilités qui permettent peut-être ce genre de chose ;
- soit on ne maitrise pas les CSS, et on aura intérêt 1) à changer de design ou 2) à utiliser un tableau.
À propos des captcha textuels : l'idée ne me semble pas si mauvaise, mais il faudrait faire le tri entre ceux qui sont globalement compréhensibles et ceux qui sont très clairement problématiques.
Les questions ayant peu de sens (combien de kiwis pour une omelette... ben ça dépend, on peut faire une omelette au kiwis si on veut), ou trop compliquées (ne pas faire des additions genre 37+41... c'est sans doute trivial pour certains -- dont moi --, mais je connais pas mal de personnes que ça perturbera), ou encore appelant des réponses différentes (j'ai répondu à une question par « zéro », et j'ai eu une erreur car il fallait taper « zero », sans accent...), ou encore faisant appel à des références culturelles (c'est qui Paris Hilton ?).
De même, supprimer le captcha en mode prévisualisation serait pas mal.
"De même, supprimer le captcha en mode prévisualisation serait pas mal."
Oui.
Cependant, je ne sais pas comment modifier le plugin actuel en conséquence :(