Exercice CSS : une mise en page en deux colonnes sans conteneurs neutres


Deuxième exercice de la série.

Les habitués de la mise en page avec le couple (X)HTML/CSS, pour des mises en page complexes, font souvent appel à des conteneurs « neutres », on remarque même souvent un abus de ces conteneurs.

Leur utilité principale est de délimiter les grandes zones d’information d’une page et surtout de faciliter le regroupement d’un ensemble d’autres conteneurs à un même endroit.

Il est possible, bien sur, de limiter l’usage de ces conteneurs « neutres » surtout pour des mises en page simples, mais il faut bien l’avouer, ils nous facilitent quand même bien le travail.

Donc, aujourd’hui, nous allons essayer de construire une mise en page en 2 colonnes, SANS conteneur neutre. Pas si simple qu’il y parait.

Construire une mise en page en deux colonnes sans conteneurs neutres

  • Objectif : à la fin de cet exercice, vous serez, normalement, capables, de construire une mise en page en deux colonnes, sans user de conteneurs neutres.
  • Niveau de difficulté : pas si simple
  • Difficulté détectée : Différents problèmes de rendus en fonction des navigateurs.
  • Pré requis techniques : connaitre les balises html, bases de CSS, une bonne connaissance des différents types de positionnement est un plus (des sources sont fournies en bas de page).
  • Matériel nécessaire : un simple éditeur de texte suffit.
  • Informations complémentaires : Voir l’image ci-dessous, il faut de plus que le design soit « fluide » (qu’il s’adapte à la résolution de l’écran) et que la construction résiste à au moins trois agrandissements de tailles de polices sous Firefox et à la taille maximal des polices sous IE. Votre code doit bien sur être conforme aux spécifications W3C tant pour le HTML que pour le CSS. Toutes les balises (X)HTML sont autorisées sauf balises « neutres » (comme ça par exemple, pas de <div></div> hein…).

L’exemple en image :

Mise en page en deux colonnes sans conteneur neutre

Pour information :

Je n’ai pas actuellement de version 100% compatible avec tous les navigateurs, c’est pour ça que je ne précise pas dans l’intitulé que la mise en page doit être compatible sur tous les navigateurs. Je vais travailler dessus en même temps que vous et tenter de faire évoluer mon code.

Précisez, si possible, quelles difficultés et quelles limitations vous rencontrez, pour que l’on essaie d’y remédier.

Si vous avez besoin d’informations complémentaire, n’hésitez pas à en demander.

Précisez dans les commentaires si vous avez fini l’exercice en mettant un lien vers la page, ou si vous n’avez pas d’hébergement, envoyez moi vos fichiers je les hébergerai.

Les sources :

Bon exercice.

Merci à vous de participer.

PS : ça c’est un exercice pour clb56 ;).


19 réponses à “Exercice CSS : une mise en page en deux colonnes sans conteneurs neutres”

  1. Est-ce que ce type de mise en page tient vraiment compte du balayage auquel on est habitué en termes de lisibilité de contenu ? Il semblerait que non. Les spécialistes s’accordent à dire qu’un contenu central réparti en colonnes ne favorise pas ce mode de lecture.
    Sauf peut-être Nielsen, qui tente déjà de réagir aux écrans de plus en plus grands qui garniront bientôt nos bureaux.

    Qu’en pensez-vous ?

  2. Me suis point encore penché dessus. Je m’étais réservé la fin de la soirée, mais quelques petits boulots en suspens avaient fait de l’overbooking avec mon temps libre. ;)

    Plus tard, donc (et bonne nuit).

    PS : ça n’a pas l’air bien compliqué, si ? En utilisant quelques classes bien pensées, et un peu de *****.

  3. @ muriel v :

    De toute manière, pour cet exercice, je ne pense pas que ce soit la question.

    Quelle que soit la réponse d’ailleurs, outre le but didactique, je ne vois pas d’intêret particulier à s’affranchir des conteneurs neutres.

  4. Méthodologiquement parlant il est très important de partir sans div, de la même manière qu’il est important de partir sans style.

    Les <div> ne devraient être introduits que quand un réel besoin s’en fait sentir, et en comprenant ce que l’on fait.

    L’exercice d’Aymeric est donc tout à fait salutaire je trouve.

    Sinon, je trouve que définir <div> simplement comme conteneur neutre est une erreur car on passe à coté de sa principale caractéristique et à mon sens sa vraie définition qui est d’être le conteneur block de conteneurs block. Soit donc au passage l’extrême opposé de <p> qui est lui le conteneur block arrêtant la possibilité d’imbrication des block.

    Le mystère là dedans c’est pourquoi <p> n’est pas considéré comme neutre lui aussi. Cela aurait été beaucoup plus simple je trouve.

  5. à aymeric >

    "d’un point de vue le lisibilité nous allons nous retrouver face à des designs "fluides" s’adaptant aux résolutions, mais avec des contenus qui ne suivront pas car eux seront optimisés dans une optique de lecture sur écran."

    En fait la question est beaucoup moins complexe qu’il y parait. Simplement il faut considérer les choses dans la bonne perspective. Les design fluides ne servent pas à permettre l’agrandissement d’un design mais au contraire son rétrécissement.

    Donc vive la propriété max-width et vive IE7 qui s’y est mis :-)

  6. @muriel v : en fait il ne s’agit d’une page en deux colonnes du contenu central, mais bien d’un contenu central et d’un menu vertical à droite.
    Pour la gestion des "grandes résolutions" j’ai eu l’occasion d’en parler dans un précédent billet :
    https://www.ajblog.fr/index.php/l...

    Un problème va survenir avec l’avènement des grandes résolutions, celle de l’adaptation des habitudes de rédaction. En effet, le "modèle" de rédaction classique pour internet veut que les textes soient courts et précis. d’un point de vue le lisibilité nous allons nous retrouver face à des designs "fluides" s’adaptant aux résolutions, mais avec des contenus qui ne suivront pas car eux seront optimisés dans une optique de lecture sur écran.
    Nous n’avons pas de métiers faciles. ;)

    #20cent et clb56 : je note vos réponses qui sont effectivement assez semblables. Vous ne voulez pas essayer sans les méchantes lignes vertes pas belles pour IE? ;)

    Pour ce qui est de l’approche de ce type d’exercices, clb56 a bien résumé l’intérêt, tester et comprendre les comportements sans les options de "facilité".

    Pour l’appellation, ce n’est effectivement pas optimum, mais pour le titre de l’article, ça passait mieux. ;)

    Voici ce que j’avais rédigé dans un ancien billet à propos de l’usage des <div> et leur usage pour "compartimenter des contenus", je pense que l’analogie est assez explicite :

    Je peux transporter de l’eau dans mes mains, si je sais bien faire une coupe, serrer suffisamment mes doigts parce que je sais comment se comporte l’eau. Je pourrais serrer moins fort si par exemple je transportais du sable.

    Maintenant, avec un contenant, prenons par exemple un seau, je pourrais transporter mon eau tranquillement, du moins si j’ai vérifié que mon anse (<div>) est bien accrochée et que mon fond (</div>) n’est pas troué. Et ça, c’est à peu près à la portée de tout le monde.

  7. Tu veux dire la fonctionnalité zoom je pense. Parce que zoom est par ailleurs une propriété css spécifique à IE et non standard.

  8. @clb56 : tiens ça me fait penser que j’ai pas réglé mon bug d’affichage du blog en 800×600 moi. ;)

    Pour ma part je dirais plutôt : vive la propriété Zoom et il serait temps que FF s’y mette. ;)

  9. Pour ma part, je trouve les fonctionnalités de zoom d’Opera et d’IE7 particulièrement chiantes et inefficaces (avec un avantage tout de même pour celle d’Opera). Mais bon, chacun son truc… Pour ma part, un design fluide agrémenté de max-width en EM pour gérer la longueur maximale de ligne, ça me semble tout à fait satisfaisant. Et plus largement implémenté que les fonctionnalités de zoom. ;)

    Sinon, c’était quoi la difficulté de cet exercice ? Le descriptif de l’exercice dit « Difficulté détectée : Différents problèmes de rendus en fonction des navigateurs. », mais je n’en ai pas vu la trace à vrai dire. J’avais mon idée de départ, je l’ai mise en place, et paf ça marchait partout. Donc pas de commentaires conditionnels pour moi.
    web.covertprestige.info/d…

    Marche avec : Firefox 2, Opera 9, Konqueror 3.5, Internet Explorer 7, Internet Explorer 6.
    L’agrandissement du texte est ok.
    Bug avec Internet Explorer 5.x, mais j’ai eu la flemme de m’y attaquer.

    PS : Ah tiens, "background: burlywood" ne valide pas ?

  10. Au fait, pourquoi est-ce que tout le monde utilise des "clear: both" pour faire les « colonnes » ? Je suis pas sûr de saisir l’utilité de la manœuvre…

  11. à florent >

    "Pour ma part, un design fluide agrémenté de max-width en EM pour gérer la longueur maximale de ligne, ça me semble tout à fait satisfaisant."

    Bon déjà pour la gestion des largeurs de lignes par rapport au nombre de caractères je pense que la combinaison width en em et max-width en % c’est mieux.

    Mais quoiqu’il en soit il ne faut pas rêver, rien n’est aussi efficace que la combinaison zoom+fit to width d’Opera puisque là l’adaptation va jusqu’à couper les mots eux même en deux. Chose totalement impossible en css.

  12. Merci aux participants d’avoir donné leurs solutions, on remarque sans grand surprise une certaine similitude dans les codes rendus.

    Pour les "difficultés", ces exercices ne s’adressent "pas que" aux pros que vous êtes les gars, certaines choses qui vous paraissent évidentes ne le sont pas forcément pour celui qui commence à s’intéresser aux CSS. :)

    Pour le commentaire squizzé (de retour au passage), c’est normal, je subis depuis quelques jours de très lourdes attaques de spam donc j’ai remis en place les mesures "fortes". Mais j’essaie de vérifier systématiquement si il n’y a pas de vrais commentaires bloqués avant de nettoyer.

  13. Hello,

    "ces exercices ne s’adressent "pas que" aux pros que vous êtes les gars"

    Suis pas un pro, suis pas un expert, suis pas un gourou BBBbbRRRrrrr…

    :-))

    Suis juste un gros bavard qu’aime bien css et son grand copain, célibataire endurci, html.

    ;-)