Journal Positionnement CSS

Posté par (page perso) .
Tags : aucun
0
2
mar.
2005
Je viens de tester un peu le positionnement en CSS pour voir comment un gars qui n'y connaît pas grand chose en graphisme/design pouvait s'en tirer. Ce que je voulais comprendre, c'était surtout pourquoi les designers web continuaient à utiliser les tables alors que CSS fournit des propriétés de positionnement pour les divs.

Après évaluation, le positionnement des div par CSS fonctionne bien, mais cela devient vite complexe pour avoir le layout voulu et qui fonctionne sur tout les browsers (mais bon, là ce n'est pas la faute au CSS). Entre les positionnements float, absolute, fixed, ... , les différences d'interprétation des recommandations selon les navigateurs, etc. il faut reconnaître que ce n'est pas évident. Alors qu'un layout fait avec des tables (même si je reconnais que ça ne devrait pas être utilisé et que ce n'est pas fait pour) est très facile à réaliser.

D'où ma question : que pensez-vous du positionnement CSS ? Suis-je le seul à trouver ça très (trop ?) complexe ? N'y aurait-il pas moyen dans une future version de la recommandation de simplifier tout ça ?
  • # C'est une façon de penser

    Posté par (page perso) . Évalué à 4.

    J'ai été (maintenant j'ai honte) un adepte du table layout, maintenant je fais tout en css. C'est réellement une question d'habitude, et au final je pense être aussi rapide avec le css qu'avec les tables. Il faut juste un peu de temps pour intégrer les différents positionnements, après c'est que du bonheur (et le code est nettement plus joli).
    • [^] # Re: C'est une façon de penser

      Posté par (page perso) . Évalué à 3.

      Moi, je rêve de déclaration dans ce style :

      HTML :

      [div id="container"]
      [div id="leftPane"]
      [div id="searchBox"]
      ...
      [/div]
      [div id="menu"]
      ...
      [/div]
      [/div]
      [div id="rightPane"]
      [div id="navigation"]
      ...
      [/div]
      [div id="content"]
      ...
      [/div]
      [/div]
      [/div]

      CSS :

      #container {
      position: centered; /* centered in browser window */
      min-margin: 2em; /* if browser window too little, keep 2em as margin */
      width: 65em;
      height: 45em;
      }

      #leftPane {
      position: left; /* At the left in container */
      width: 12em;
      /* height automatically herited from container */
      }

      #rightPane {
      position: fill; /* fill container space */
      }

      #searchBox {
      position: top; /* At the top in leftPane */
      height: 3em;
      /* width automatically herited from leftPane */
      }

      #menu {
      position: fill; /* fill leftPane space */
      }

      #navigation {
      position: top; /* At the top in rightPane */
      height: 3em;
      /* width automatically herited from rightPane */
      }

      #content {
      position: fill; /* fill rightPane space */
      overflow:auto;
      }


      ----------------------------

      Ca permettrait de faire les layout bcp plus simplement ... Ici, pour les tailles et les positions, on s'y perd ... On ne sait plus qui hérite de qui, si les pourcents sont par rapport au parent ou au browser, ...
      • [^] # Re: C'est une façon de penser

        Posté par (page perso) . Évalué à 5.

        Je pense que si tu trouve ça si compliqué c'est que tu prends le problème à l'envers et que tu essaye de faire ce que tu faisais avec les table à l'aide de div et de css.
        On le vois très bien dans ton exemple quand tu écrit :
        [div id="rightPane"]

        Avec les tableaux tu construit des cellule et tu mets du contenu dans chacune d'elle, le contenu et la forme sont mélangés.

        Dans l'approche avec des feuilles de style, les données sont bien separées du contenu. Le contenu doit se contenter des décrire le document.

        Ensuite le rendu à l'aide de feuille de style doit se faire naturellement (à quelques exceptions près).

        C'es une erreur de se dire que les feuilles de style c'est faire des table en remplacant les td par des div. Les div doivent servir pour délimiter des grands ensemble, pas pour faire de la présentation. Ne pas oublier que les feuilles de style s'appliquent également aux autres éléments, en particulier les titres ou les paragraphes.

        Trop souvent quand on découvre le code de quelqu'un qui se mets aux css pour le rendu des pages on découvre un code ne contenant que des div et des span, ce qui est la démarche inverse de celle que devrait implliqué le xhtml+css.

        Pour caricaturer je dirais que le xhtml+css n'est pas une question de technique mais de philosophie. La technique n'est qu'une conséquence.
        • [^] # Re: C'est une façon de penser

          Posté par (page perso) . Évalué à 3.

          Ok, je comprends bien ce que tu veux dire.

          Donc, je devrais avoir un HTML comme celui ci :

          [div id="menu"]
          ...
          [/div]
          [div id="navigation"]
          ...
          [/div]
          [div id="content"]
          ...
          [/div]
          [div id="searchBox"]
          ...
          [/div]

          ------------

          Mais alors, comment dois-je écrire le CSS pour placer mes éléments comme décrit plus haut ? Comment, pas exemple, puis-je dire que content et navigation doivent remplir l'espace à droite de menu et searchBox et que navigation doit être en haut de content ?
          • [^] # Re: C'est une façon de penser

            Posté par (page perso) . Évalué à 2.

            > Donc, je devrais avoir un HTML comme celui ci :

            oui. en quelque sorte

            pour rappel DIV = DIVISION = SECTION != CELLULE ;-)

            > Comment, pas exemple, puis-je dire que content et navigation doivent remplir l'espace à droite de menu et searchBox et que navigation doit être en haut de content ?

            Cela peut se résoudre en modifiant l'ordre de tes sections, dans la limite où bien sûr cet ordre garde le contenu général du document cohérent (c'est à dire, un contenu intelligible si on le lit sans feuille de style)

            Toutefois, il manque c'est vrai des styles qui permettent de positionner des boîtes relativement à d'autres boîtes. (faisable plus ou moins avec les styles du box model XUL dans mozilla ;-)
          • [^] # Re: C'est une façon de penser

            Posté par (page perso) . Évalué à 3.

            Tu peux même remplacer ton [div id="menu] par [ul id="menu]
            Pareil pour navigation et searchbox à mon avis (aprés ca dépend ce que tu mets exactement dedans.

            En effet un menu est toujours une liste (avec eventuellement des sous listes : http://dosimple.ch/articles/Menus-dynamiques/menuHorizontal.html(...) par exemple)

            Et c'est pareil avec la plupart des elements de ta page. Il ne faut utiliser les div que lorsque tu as des elements heterogénes que tu veux rassembler.
        • [^] # Re: C'est une façon de penser

          Posté par . Évalué à 2.

          Croire qu'on peut coder son XHTML en faisant totalement abstraction de la manière dont ça sera présenté est également une erreur. A moins de faire comme dans csszengarden et mettre des id à toutes ses balises (dans ce cas c'est très modulaire, mais ça fait aussi un code très lourd :) ).

          Dans les faits, y'a toujours un compromis à faire.
          • [^] # Re: C'est une façon de penser

            Posté par (page perso) . Évalué à 2.

            En fait, je pensais qu'on féfinissait une structure de base (comme dans mon premier exemple), puis qu'on définissait les règles précises dans le CSS.

            Ce qui est différents des tables parce qu'avec elles, on finissait vite par avoir des cellules vides pour gérer le design. Tandis que dans mon exemple, c'est plutôt des éléments structurels globaux qui sont définis.

            Sinon, comment dire à searchBox qu'il hérite des propriété du leftPane s'il n'est pas défini dedans ?
          • [^] # Re: C'est une façon de penser

            Posté par (page perso) . Évalué à 2.

            Oui, en particulier l'ordre des sections est très importante dans le rendu, surtout si on privilegie le positionnement relatif comme préconisé par le w3c. Mais également d'autres artifices, c'est pour cela que je parlais d'exceptions, cela ne doit pas être la règle.

            Mais ce que j'essayais d'expliquer (peut-être mal) c'est que quand on écrit du xhtml on doit penser que c'est du xml, que ça décrit les données et non la présentation, ça doit pouvoir rester compréhensible si on le lit à haute voix.

            Je pense que le bon ordre c'est d'abbord de parler du principe, ce que j'appellais la "philosophie", commencer par les artifices n'est pas la bonne solution (à mon avis) pour comprendre comment ça marche.
  • # Les navigateurs, les normes, toussa ...

    Posté par (page perso) . Évalué à 7.

    D'où ma question : que pensez-vous du positionnement CSS ? Suis-je le seul à trouver ça très (trop ?) complexe ? N'y aurait-il pas moyen dans une future version de la recommandation de simplifier tout ça ?

    Je suis relativement d'accord avec toi. Le positionnement full CSS peut s'avérer trop complexe à mettre en oeuvre si l'on veut garder un site compatible avec des navigateurs anciens.

    J'ajouterais qu'à l'époque ou mozilla faisait 1% des visites, les défenseurs du libre disaient qu'il fallait faire attention à ces 1% qui sont tout aussi important que les 99% de IE. Aujourd'hui, je dirais : IE-5 fait 1% des visites, il est donc important de faire attention à ce que votre site passe sous IE-5. J'ajouterais meme les safari et autres IE machinetoc, dont les rendus sont bien souvent très différents des IE/Windows... et la gestion du css tout aussi exotique ...

    Partant de ce pré-requis, faire un site 100% en positionnement CSS me parait être une quasi croisade ... Bref, les normes sont belles, bien écrites (quoique) et tout, mais les navigateurs ne les respectant pas à la lettre, il faut bien (à mon avis) finir par se faire une raison sur certains points ...

    D'ailleurs, mettre 1 table générale pour le layout ne gène pas la navigabilité outre mesure, notamment pour les personnes déficientes ...

    Parallèlement, j'admire le travail effectué par les cssZenGarden & autres OpenWeb, mais qui sont bien loin des pré-requis d'entrerprise ... Allez faire comprendre à une petite pme que sont site web ne va pas lui couter 1000 euros mais 1500 parce que l'on a fait des choix éthiques, d'avenir et tout et tout, de respect des normes ... bref, il s'en fout ... (et à mon avis il a bien raison ...)
    • [^] # Re: Les navigateurs, les normes, toussa ...

      Posté par (page perso) . Évalué à 5.

      Allez faire comprendre à une petite pme que sont site web ne va pas lui couter 1000 euros mais 1500 parce que l'on a fait des choix éthiques, d'avenir et tout et tout,


      utiliser CSS, ce n'est pas pour seulement des choix éthiques. Mais aussi pour plein de bonnes raisons qui interresserait bien plus ton client. l'"avenir" en fait d'ailleurs parti :

      - poid des pages beaucoup plus faible -> moins de bande passante -> hebergement moins cher et moins de charge serveur -> plus de visiteurs simultanés possible -> moins de risque de blocage -> moins de désagrement pour l'utilisateur -> c'est bon pour l'image du client
      - design dans un seul fichier (ou quelques uns) -> facturation moins importante des modifs -> moins cher pour le client
      - en général, quand tu passes au css, tu fais du code valide -> durée de vie du site beaucoup plus longue -> pas besoin de faire de refaire le site à chaque nouveau navigateur -> moins cher pour le client

      Maintenant, je dirais que si tu lui facture un site plus cher parce que tu le fais avec CSS, c'est qu'il y a des lacunes au niveau compétence CSS. Certes, tout le monde ne s'appelle pas Zeldman ou Meyer, mais faut pas pousser non plus.

      Je dirais même que le facturer plus cher, c'est du foutage de gueule. je n'ai jamais eu de projet où le client ne changeait pas d'avis sur le design tout le long du dev. Or modifier un design en CSS est beaucoup plus rapide que basé sur un table layout -> le coût horaire est censé être moins important.

      Ceci dit, je suis d'accord sur un point : avoir un tableau (mais un seul) pour le layout général, ce n'est pas inadmissible et permet d'évacuer les problèmes de mise au point généraux pour les vieux navigateurs. (bien que, si on connait suffisement les techniques CSS, on s'en sort facilement avec du full CSS; Mais ça, seul l'expérience permet de le savoir ;-) )
      • [^] # Re: Les navigateurs, les normes, toussa ...

        Posté par (page perso) . Évalué à 4.

        Toi qui a l'air de bien connaittre CSS, j'aimerais te poser deux questions:

        - Connais tu de bons livres qui expliquent comment faire des designs en CSS (pas juste des références, mais vraiment des cas concrets de design de A à Z) ?

        - Saurais-tu écrire la CSS pour faire le design que je décris plus haut ?

        En fait, j'essaie de pousser les graphistes de ma boite à se mettre au CSS et laisser tomber les tables (et dreamweaver !!) mais j'ai besoin de leur prouver que ça peut représenter un gain de temps/clartés pour eux ...

        Merci ;-)
    • [^] # Re: Les navigateurs, les normes, toussa ...

      Posté par . Évalué à 4.

      [blockquote]J'ajouterais qu'à l'époque ou mozilla faisait 1% des visites, les défenseurs du libre disaient qu'il fallait faire attention à ces 1% qui sont tout aussi important que les 99% de IE. Aujourd'hui, je dirais : IE-5 fait 1% des visites, il est donc important de faire attention à ce que votre site passe sous IE-5. J'ajouterais meme les safari et autres IE machinetoc, dont les rendus sont bien souvent très différents des IE/Windows... et la gestion du css tout aussi exotique ...[/blockquote]

      Il ne suffit pas de regarder les "parts de visites" de chaque navigateur, mais aussi de faire des estimations sur l'évolution future de ces parts. Si on ne veut pas changer la gueule du site pendant 2-3 ans, ça peut être utile.

      Là est la différence :
      - Mozilla/Gecko peut progresser (et a progressé), car c'est un navigateur en plein développement et activement supporté. Idem pour Opera, Konqueror, Safari, ...
      - IE5 Win va forcément diminuer pour devenir marginal d'ici quelque temps (comme IE 4 en son temps), en faveur (principalement) d'IE6 (inclus par défaut dans Windows XP).
      - IE Mac va diminuer car plus développé, et Apple faisant la promotion de son propre navigateur (Safari).

      Supporter parfaitement IE5 Win/IE Mac maintenant, c'est un peu le même problème que supporter Netscape 4 il y a 2 ans (avec moins d'emmerdes quand même), ça suppose de faire des choix qu'il faudra remettre en cause à moyen terme car ils ne seront plus justifiés.
  • # Normal !

    Posté par (page perso) . Évalué à 3.

    C'est normal que tu trouves ça difficile au début ! (si ça peut te rassurer)

    Côté positionnement, j'utilise les CSS depuis qq temps, et je dois reconnaître que je trouve maintenant ce système plus simple que les tableaux "dreamweaverés".
    Pourquoi ?

    Le tout est plus logique : on ne casse pas le design en touchant à la cellule du bas qui est calibrée de telle manière pour que ça fonctionne bien avec celle du haut... (vieux raisonnement avec DW)

    J'ai qq preuves que c'est possible de faire une mise en page tout CSS :
    Mon site perso : http://dominique.hoffmann.free.fr/(...) (plusieurs CSS alternatives)
    Et qq réalisations : http://www.club-dvd.ch/index.asp(...) , http://www.carvos.com/teamquad/(...) etc...

    Les avantages :
    -plus léger
    -plus logique (point de vue code)
    -plus efficace point de vue maintenance
    -marche nickel sur tous les browsers qui respectent les standards (à peu près tous, sauf un qui fait ch... son monde)

    Les inconvénients :
    -légers pbs avec IE 6 parfois, mais pas insurmontables
    -plus gros problèmes avec IE 5.5, IE 5.0 et IE mac.

    Personnellement, j'annonce la couleur quand un client me parle de compatibilité de navigateurs : ça marche avec IE 6.0 (obligé), ça marche avec Firefox, Mozilla, Galeon, Konqueror, Camino, Safari, etc... la liste est longue (et en général, ça plaît bien au client de voir que le site sera nickel sous tous ces navigateurs, même ceux qu'il ne connaît pas), et je conclus en disant que ça risque de créer des problèmes avec IE 5.5 et inférieurs, en pointant du doigt sur le fait que ces navigateurs sont obsolètes...

    Preuve est : le dernier skin en date ajouté sur mon site perso (Firefox) m'a pris au moins... 3 heures à créer, en comptant la création du graphisme, la découpe du graphisme, et l'intégration CSS.
    • [^] # Re: Normal !

      Posté par (page perso) . Évalué à 2.

      Je suis déjà venu visiter ton site à de nombreuses reprises et c'est vrai qu'il est impressionant !!

      Je suis un convaincu des avantages du CSS, c'est juste que c'est déroutant au départ ... (surtout pour le positionnement et les tailles).

      Je rêve que les graphistes de ma boite se mettent vraiment au CSS, car en tant que développeur web, c'est un cauchemard de repasser sur les templates fait avec DreamWeaver pour les rendre dynamique ... Entre tout ces table / tr / td imbriqué, c'est un vrai labyrinthe ...

      On a commandé un bouquin hier :

      http://www.amazon.fr/exec/obidos/ASIN/2744018341/qid=1109767137/ref(...)


      Ca devrait nous aider ...

      PS : Je partage ton avis sur la tartiflette ;-)
      • [^] # Re: Normal !

        Posté par (page perso) . Évalué à 2.

        >On a commandé un bouquin hier :

        Bon choix, c'est l'un des meilleurs et mondialement connu :-)

        Y a aussi ceux de Zeldman (mais pas traduit je crois)
      • [^] # Re: Normal !

        Posté par (page perso) . Évalué à 2.

        Merci pour le site ! (y a un prochain skin en préparation, mais chut, c'est pour la semaine prochaine)

        Perso, j'ai été convaincu par les avantages des CSS, mais là où c'est le plus drôle, c'est que ces avantages se sont imposés par eux-mêmes !

        (essayez donc de faire un site skinnable à coup de tableaux, et vous verrez...)

        Quand on a l'habitude, c'est tellement plus simple...

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.