Je me suis posé la question de savoir combien était divisé mon temps pendant que j’intégrais. J’ai divisé en 5 parties ce temps (peut-être en oubliant des parties) et évalué grossièrement leur répartition. Je suis arrivé à ce graphique :
HTML : vers davantage de modularité
Je code toujours en XHTML 1.0 Strict, et ça m’a évité pas mal de problème de Quirksmode je me rends compte. J’utilise au maximum les balises sémantiques <p>,<ul>,<label>,<hn>,<strong>… mais je suis de moins en moins réticent à multiplier les <div> et <span>. D’un côté, c’est cool d’éviter la divite, c’est joli, c’est léger. Mais en pratique, et surtout pour les gros sites, il faut être très spécifique quant aux styles à appliquer à certains éléments. Donc je rajoute une ou deux div par ci par là pour améliorer ma productivité et surtout la flexibilité du code. Ca facilite grandement la différenciation. Et ça permet surtout de prévoir d’eventuelles évolutions de fonctionnalités, et avoir une approche plus modulaire.
A force de prôner la séparation HTML (contenu) / CSS (mise en page), on a peur de modifier le HTML, comme si c’était devenu interdit voire impossible. Je me dis que les développeurs ne sont pas bien méchants et que l’on peut leur demander des modifs HTML, avoir plusieurs classes sur un même élément au lieu de répéter son code CSS pour pas grand chose (voir plus bas).
CSS : une seule css, un reset et de moins en moins de contextualisation
C’est évidemment très lié au HTML utilisé. Depuis quelques temps, je me suis fait un fichier reset.css qui utilise le Reset CSS de Yahoo! . Par contre, ce n’est pas un fichier que j’importe à chaque fois mais un code que je copie-colle en créant ma CSS. Parce que oui, je préfère garder une seule CSS pour tout le site. Niveau lisibilité, je n’ai pas trop de problème à utiliser un seul fichier parce que j’écris chaque sélecteur CSS sur une seule ligne. Niveau productivité, répartir des propriétés sur plusieurs CSS c’est passer beaucoup de temps de l’une à l’autre, trouver où se trouve ce sélecteur, éviter les conflits… J’évite. Et le seul vrai avantage d’avoir plusieurs CSS, c’est d’en appeler certaines dans certains cas, et d’autres dans les autres cas. Je préfère mettre une class au body pour différencier les pages, c’est beaucoup mieux.
Les exceptions pour utiliser plusieurs CSS sont : un fichier pour ie6, un fichier par couleur (si il y a des thèmes par couleur) et un fichier pour le print.
Je fais encore pas mal de contextualisation (ex: .bloc table tbody td.direction ) parce que ça permet d’éviter les conflits. + de contextualisation = – de classes à créer
Appliquer le même style à des éléments HTML différents
Il y aussi le cas où vous voulez que plusieurs éléments HTML aient les mêmes propriétés CSS Dans ce cas, il y 3 choix :
- copier-coller les mêmes propriétés pour la nouvelle classe (bouh, pas bien!)
.maclasse { propriétés identiques }
.monautrelement { propriétés identiques }
.montroisieme { propriétés identiques } - mettre les éléments qui ont les mêmes propriétés à la suite
.maclasse, .monautreelement, .montroisieme { propriétés identiques } - créer une nouvelle classe et rajouter cette classe dans le HTML
.manouvelleclasse { propriétés identiques }
La première méthode est à éviter : si on veut changer une propriété (ex: la couleur d’une bordure), il faut le changer autant de fois que l’on a copié-collé.
La deuxième méthode est la plus propre : le HTML reste relativement léger (= non alourdi de classes) mais la CSS est plus longue à maintenir. C’est ce que je faisais avant.
La troisième méthode est plus “modulaire” je dirais. Un élément HTML aura par exemple : class=”.maclasse .manouvelleclasse”. On rajoute donc une classe aux éléments qui ont le même style. Mmmh. Est-ce que c’est bien ? Est-ce que l’on sépare bien la mise en page du contenu ? Plus ou moins je dirais. En fait, dans le HTML, on ajoute la classe à tous les éléments qui doivent appraître de la même façon. Et si on veut plus qu’un élément n’aie plus ces propriétés ? Il faut supprimer la classe dans le code HTML. Ah. C’est pas bien. On ne devrait plus avoir à toucher au code HTML. En théorie, c’est vrai. Mais en pratique, c’est, d’une part, très rare de vouloir changer le style d’un seul élément, et d’autre part, pourquoi n’aurait pas-t-on le droit de modifier le HTML ? Une fois livré, on ne peut plus rien faire (voir § sur le HTML) ?
Je dois préciser une chose importante : cette méthode modulaire, je l’utilise surtout pour les blocs et les gros éléments, pour les éléments qui structurent et divisent l’affichage. Il faudrait que j’envisage de faire un article avec des exemples plus éloquents. 
IE6 : 40% de perte de temps
J’ai déjà parlé de ce que l’on pourrait faire si IE6 n’existait plus. En fait, rendre un site compatible IE6, c’est du débuggage pur et simple. On doit utiliser des overflow:hidden, position:relative, display:inline… pour aucune raison valable si ce n’est faire plaisir aux internautes du siècle dernier (ou presque). Sans compter tout ce que l’on est privé de faire. Bref, une calamité.
Nommer les class/id
Dans mon souci d’avoir un code lisible, pour moi et ceux qui retoucheront aux CSS, j’essaye d’avoir des noms de class/id simples mais efficaces. Simple, ça veut dire court. Avec 4 lettres, on peut faire pas mal de choses : .bloc, .nav, .main, .side… J’ai par exemple remplacé .pagination par .page. Ou mettre .srv au lieu de .service. C’est pas très méchant et ça permet d’avoir une CSS bien plus lisible (surtout si l’on contextualise ET que l’on met tout sur une ligne).
Et si je passe autant de temps, c’est aussi pour éviter d’appeler un élément “grillade” par exemple (alors que ça n’a rien à voir avec un barbecue). J’ai vérifié, elle y est encore.
Découper les images
Dernier point : découper le PSD. On voit directement si un PSD est fait par quelqu’un qui sait intégrer ou pas. J’ai de la chance, c’est souvent le cas. Mais lorsque ça ne l’est pas, il faut voir les effets de dégradés, les superpositions, les ombres qui dépassent… qui n’ont l’air de rien graphiquement, mais qui sont une calamité à intégrer. D’ailleurs, c’est une calamité à cause d’IE6! Parce que pour IE6, il faut tout aplatir! L’ombre doit aller avec l’élement qui la fait ET avec l’élément où elle se projette. N’est-ce pas logique ? Et bien non. Vive les PNG. C’est tout.
Conclusion
J’ai essayé de faire un rapide panorama de ce que doit faire un intégrateur. On se rend compte que le grand ennemi reste IE6. Les 40% cités correspondent au temps de débuggage, mais je suis sûr qu’on peut gagner du temps dans les autres domaines (découpage, css, html) si il n’y avait pas IE6. J’ai peut-être oublié des éléments, je ne sais pas. Vous avez des idées ? Des remarques ? Des critiques ?
