De l'ordre, que diable !

Actualitéweb

Publié par le , mis à jour le (25303 lectures)

web

Rien n'est plus énervant que d'avoir à reprendre un code abscons et illisible que l'on ne sait pas comment attaquer. A mon sens, un travail d'intégration nécessite deux qualités essentielles : de la méthode et de la rigueur. Car, autant le graphiste a pour objectif de produire un résultat créatif et parfois un peu délirant, autant l'intégrateur doit -pour sa part- produire un code propre, compréhensible et facilement modifiable par la suite.

Bien sûr, il n'existe pas une manière universelle de coder : chaque personne le fait en fonction de sa logique et de ses préférences. Néanmoins certaines clefs permettent d'obtenir une feuille de style propre et accessible à tous. Voici quelques unes d'entres elle :

Avertissement : il s'agit d'une méthodologie personnelle, reflet de la conception que j'ai d'un fichier CSS, en aucun cas d'une quelconque "règle à suivre" à tout prix.

Introduction, développement, conclusion

Bien hiérarchiser les blocs de déclarations fait partie de ces petits plus qui peuvent apparaître totalement futiles sur une feuille d'une cinquantaine de lignes... Mais qui peut se révéler terriblement utile lorsque l'on se frotte à des fichiers de 1500-2000 lignes. Là, on est vraiment content de savoir où chercher ! :)

La méthodologie est toute simple, c'est comme dans une dissertation.
Prêts pour un petit retour au lycée ?!?

  • Tout d'abord il faut introduire le sujet (où, quand, comment) en définissant les propriétés générales de la page et des éléments principaux (html, body, #conteneur_principal, etc...).
  • Ensuite on annonce la couleur en présentant le plan du développement et les principaux blocs composant la feuille de style : #header, #menu, #contenu, et autres #footer sont sommairement annoncés. Emplacement, dimensions et arrière-plan suffiront pour l'instant.
  • Puis les choses sérieuses commencent avec le morceau du roi : le développement. Il va falloir être inspiré car dans cette partie vous allez reprendre les chapitres annoncés en introduction et... les développer un par un : Où placer le logo dans #header ? Quelle couleur définir pour les liens au rollover dans #menu ? Comment spécifier les puces de liste dans #contenu ? Dois-je aligner les mentions légales à gauche ou à droite dans #footer ?
  • Enfin, on conclut en faisant preuve d'ouverture et d'initiative. En dissertation, c'est la partie qui sous-entends : j'ai déjà développé un gros morceau, mais je suis sûr(e) que d'autres éléments mériteraient qu'on s'y intéresse. En CSS, c'est pareil : on se concentre sur les pages spécifiques qui contiennent des éléments particuliers, comme par exemple la page de contact.

En rang deux par deux

Un couple par ligne, c'est bien suffisant !
La pratique démontre qu'il est plus facile de travailler avec une vision globale plutôt qu'avec une vision linéaire. Comprendre les interactions des propriétés les unes avec les autres lorsqu'on les a toutes sous les yeux, c'est quand même mieux..., non ?
Jugez plutôt :

body { margin: 0;  padding: 0 0 2em 0; font: normal 80%/1em "Trebuchet MS", Verdana, Arial, sans-serif; color: black;  text-align: center; background: #F1EFE2; }
body {
   margin: 0;
   padding: 0 0 2em 0;
   font: normal 80%/1em "Trebuchet MS", Verdana, Arial, sans-serif;
   color: black;
   text-align: center;
   background: #F1EFE2;
}

Hiérarchisez vos déclarations

Bien qu'aucun ordre ne soit clairement défini à l'intérieur d'un groupe de déclarations, la pratique m'a démontrée qu'un agencement récurrent facilitait la visualisation des comportements.
Pour ma part, j'utilise toujours le même schéma :

  1. Le positionnement => display – visibility – position – top/right/bottom/left – z-index – float – clear
    Il est suivi des caractéristiques qui y sont directement liées.
  2. Les marges et bordures => margin – padding – border
    Elles permettent de placer l'élément au sein de la page.
  3. Les dimensions => width – height – min-width/max-width – min-height/max-height
    Elles sont calculées à partir des valeurs de marges internes et de bordures.
  4. Les propriétés de texte => font – line-height – text-align – text-indent – text-decoration – text-transform – letter-spacing – word-spacing – color
    Elles découlent en partie des déclarations précédemment définies.
  5. L'arrière-plan => background
    Placé en dernier, il n'influe sur aucun élément et permet de visualiser rapidement l'élément fautif en cas de problème de rendu.

Soyez Bavard

Un jour, un monsieur a écrit : Pensez à fermer vos balises... Soyez bavards !
En CSS, c'est pareil : il ne faut pas avoir peur de commenter votre code, c'est même vivement conseillé ! Qu'il s'agisse d'annoncer les blocs principaux ou d'expliciter une déclaration, votre feuille gagnera en lisibilité et vous en temps de maintenance (ou de codage).

Par exemple le commentaire ci-dessous permet de retrouver rapidement au premier coup d'oeil la partie du code concernant le #footer parmi les nombreuses autres déclarations lors d'un survol rapide de la feuille de style.

/* -----------*/
/*    Footer  */
/* -----------*/
#footer {
  margin: 0 auto;
  padding-top: 0.5em;
  width: 807px;
  height: 3.5em;
  color: white;
  font-size: 0.95em;
  font-weight:bold;
  text-align: left;
  background: url(design/footer.png) left bottom no-repeat;
}

Ne soyez pas frileux et explicitez le pourquoi de vos déclarations. Cela évite à la relecture de se demander si la ligne incriminée est une erreur, un oubli ou un correctif intentionnel.

#colone_droite {
  float : right;
  margin-right : 38px;
  display : inline; /* Bug IE6 - double marge */
}

Voilà... :)
Je ne pense pas avoir trouvé la solution ultime pour coder des feuilles de styles parfaites, mais ces quelques règles de base fonctionnent pour moi.
Établissez les vôtres et vous verrez que ça vous simplifiera la vie !

Commentaires

100 fois sur l'ouvrage tu remettras ton travail. Il faut taper le clou pour que ça rentre.

Très bon article :p
J'essaye pour ma part de regrouper les blocs de déclaration css à la manière de CSSEdit
/* @group Titre_du_groupe */
/* @end */

comme cela les Mac-eux sont directements contents

Bonjour,

Je suis bien d'accord avec toi, on croise trop souvent des CSS hideusement codées. Toutefois ceci est très subjectif.

Par exemple, une de mes habitudes de codage diffère de la tienne. J'ai toujours passé plus de temps à rechercher un sélecteur en particulier, même s'ils sont classés par zone dans la page, qu'à lire les propriétés d'un sélecteur. Pour palier à ce problème, mes propriétés se trouvent toujours sur la ligne du sélecteur. De plus j'indente mes sélecteurs en fonction de leur hierarchie. Cela donne des lignes assez longues, mais je n'ai aucun problème pour retrouver un sélecteur dans ma page.

Un article sur ce sujet :
orderedlist.com/articles/...

Au final, il faut surtout avoir une règle de nommage et d'édition des CSS, et s'y tenir !

"Comprendre les interactions des propriétés les unes avec les autres lorsqu'on les a toutes sous les yeux, c'est quand même mieux..., non ?"

C'est tout à fait pour ça que je mets tout en ligne, perdre plus de la moitié de la largeur de l'écran en mettant une déclaration par ligne c'est le meilleur moyen de devoir scroller quand on a un éditeur de texte qui prévient le défilement horizontal par des retours à la ligne ...

Intéressant mais :
/* -----------*/
/* Footer */
/* -----------*/

3 lignes, ~30 caractères pour juste en dessous mettre :
#footer
qui indique exactement la même chose finalement.

C'est vraiment faire du zèle de commentaire !
Expliquer comment bien placer et indiquer des commentaires utiles aurait été sympa.

Au pire un simple /* footer */ suffit amplement. (Ok c'est du chipotage)


Bonjour,

Tout à fait d'accord dans l'ensemble, mais pour ma part, j'ordonne les déclarations par ordre alphabétique. Pas de logique personnelle à transmettre à un autre codeur qui pourrait avoir une approche différente, l'ordre alphabétique est universel !

Seul écart à la règle, je place les déclarations top, right, bottom ou left sur la même ligne que position.
Ex :
div {
background: #EEE;
color: #333;
position: absolute; top: 10px; left: 25px;
width: 333px;
}

Un /* footer */ passe totalement inaperçu.

Il faudrait même créer plusieurs niveau de commentaire pour bien voir quand on scrolle.

Je faisais comme Changaco au début, parce que je trouvais ça plus lisible.

Mais au final, avec des bon gros bloc de commentaire, ça passe.
Et puis, on peut compresser du css comme on compresse du javascript.

Sinon, un éditeur CSS peut macher le travail. Il peut montrer les propriétés sans le contenu etc.

Je suis moyennement d'accord pour les commentaires. Je suis partisan de la notation CSSDoc pour ensuite générer une documentation à partir de la feuille de style.

/**
* Footer
* =footer
*/

J'ai pour habitude de mettre un =(raccourci) pour faciliter les recherches avec un CTRL+F.

Idem pour la hiérarchisation : c'est bien mais pas forcément logique. L'ordre alphabétique c'est très bien aussi.

La hiérarchisation je la vois davantage dans l'indentation du code (Python style) pour décrire les niveaux de cascade.


Les méthodologies universelles ça n'existe pas ;-)

«Les méthodologies universelles ça n'existe pas»

Tout à fait. Mais il peut être intéressant de partager sa méthodologie personnelle, qui peut inspirer d'autres personnes... ou les inciter à partager la leur en commentaire. ;)

«Il faudrait même créer plusieurs niveau de commentaire pour bien voir quand on scrolle.»

C'est ce que je fais pour ma part, en gardant tout de même les commentaires sur une seule ligne pour éviter l'effet «gros bloc informe». J'ai donc deux niveaux:

/* --- GRANDE PARTIE --- */

/* Petite sous-partie */

«Sinon, un éditeur CSS peut macher le travail. Il peut montrer les propriétés sans le contenu etc.»

Pas forcément besoin d'un éditeur dédié à CSS ou spécialisé pour ça. La plupart des éditeurs de code proposent une fonction de pliage du code. Il suffit de demander à l'éditeur de tout replier, et on a à l'écran uniquement les sélecteurs CSS. Donc pas besoin d'écrire le sélecteur et ses déclarations sur une seule ligne de code. :)

Et bien pour pouvoir si retrouver dans un fichier CSS (qui potentiellement fait 2000 lignes), je préfère implémenter les sélecteurs selon ... ma structure HTML (donc avec indentation).
Ainsi vous vous y retrouverez dans le CSS sans avoir à chercher vingt ans la ligne correspondant à votre modification.
Cela nécessite toutefois de savoir coder du CSS sur une seule ligne par instruction (PSPad permet de passer d'un mode à l'autre).

perso, j'ai jamais aimé le folding dans les éditeurs, que ce soit pour les fonctions ou le css

Je n'arrête de cliquer pour déplier/replier

J'aime bien un panneau à coté qui me montre la hiérarchie de mon fichier, où je peux cliquer pour aller où je veux.
Et c'est là où on peut faire des choses, par exemple trier par ordre alphabétique au lieu de l'ordre de la page.

@FlorentV : tout à fait d'accord qu'il faut tout de même partager ses méthodes personnelles. Du coup je compte rédiger un article consacré à ma méthodologie, en espérant que ça aide ;-)

Pour ce qui est de la question sur la pertinence d'ajouter des commentaires au détriment du poids du fichier résultant, il est tout à fait envisageable de travailler en local sur une version commentée et de mettre en ligne une version allégée (les commentaires sont là pour aider la ou les personnes qui sont destinées à le modifier).
Il suffira que tous les collaborateurs en fassent de même, mais là après il ne s'agit ni plus ni moins de la capacité de travailler en groupe et non pas tout seul dans son coin ;-)


@neolao : les éditeurs sont bien souvent munis de raccourcis clavier pour agir sur le folding. Exemple avec TextMate : F1 pour plier/déplier le bloc en cours ou ⌥⌘[0-9] pour agir sur tout à 9 niveaux de hiérarchie.

Pour ma part, je fonctionne toujours ainsi pour coder mes CSS :

-en premier des propriétés communes à toutes mes CSS (qq bricoles)

-ensuite l'intégration du "squelette" de la page (navigation, header, footer, toussa)

-ensuite chaque page est détaillée

Pour peu qu'on factorise un peu les propriétés communes, ça permet de faire des CSS plutôt complexes mais qui restent légères (4 à 6 Ko pour un site complet, je trouve ça correct).

Bonjour,

Personnellement, je sépare tout :
- une feuille de style pour chaque partie du site (header, content, footer)
- une feuille de style pour les positionnements et pour les styles par partie

Et enfin une feuille de style qui importe toutes les feuilles (6 dans le cas de 3 parties).

Pourquoi?

Tout simplement parce que je trouve que c'est d'autant plus simple à gérer, surtout pour les feuilles alternatives.

Bon billet sinon, sauf le "Voilà..." à la fin ^^

Merci.

Écrire les attributs toujours dans le même ordre facilite aussi énormément le travail.

Personnellement, je met toujours en premier tout ce qui touche au positionnement (float, margin, width etc.), puis à la mise en forme (border, background, text-format etc.) et enfin ce qui spécifique à l'élément (clear, list-style-type etc.).

Parler d'organisation de la feuille de style sans jamais aucune référence à la notion de flux pourtant essentielle concernant le document html auquel elle s'applique et à l'ordre de déclaration et/ou des balises que l'on y trouve... Ben c'est dommage ? Non ;)

Penser flux, toujours, voilà la clé.

Salut,

De mon côté je préconise surtout de choisir une méthode et de s'y tenir tout au long du projet.

J'ai également pour habitude d'indenter mes déclarations comme le code html.

<body>
<div>
<p></p>
<ul>
<li></li>
<li></li>
</ul>
</div>
</body>

body {}
div {}
p {}
ul {}
ul li {}

Commentaires clos