Le temps d’intégration
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 ?
excellent article
je dirais qu’avec le temps et l’expérience, la part de débug IE6 rétrécit… on sait quoi éviter, comment contourner les lacunes de ce navigateur. Notre nouveau jeu au taf: intégrer TOUT le site, puis tester à la fin sous IE6! on atteint le zéro faute, parfois…
si je defais faire moi aussi mon camembert:
- pas de découpe d’img (fait par les graphistes), mais qques retouches sous gimp + découpes de qques éléments manquants (puces, …)
- une partie javascript / jquery
- une partie lorem ipsum
- “nommer les class/ID” fait en grande partie par le CMS (spip en ce qui me concerne)
voilà voilà. a+
Hello,
Je me posais justement la question ces derniers jours :
“combien de temps prennent les autres ? ”
Travaillant dans une petite boite avec une poignée de personnes qui ont chacun leur propre fonction, je n’ai pas vraiment de collègues de références en la matière
Et bien je suis +/- d’accord avec toi.
Mon temps de travail est réparti à peu près de la même façon.
Dans mon cas, je diminuerais un peu IE6 car avec une feuille de style dédié, on arrive à régler assez rapidement les différents bugs connus. Enfin, ca dépend
…
J’augmenterais le découpage en ajoutant à cette partie la phase de ‘brainstorming’. Il y a des design qui ne sont pas toujours évident, et je me suis déjà attardé plus d’une fois à prendre un crayon en main pour me faire un croquis et pensé aux “techniques” que j’allais utiliser pour le futur découpage/intégration.
Pour le nom des classes & id, j’essaye d’utiliser des noms les plus significatifs possible et tanpis si ca prend 10 lettres.
A force de rétrécir les mots, 6 mois après, on ne sait plus ce qu’on avait voulu dire …
Pour le html, j’essaye d’avoir une structure la plus propre possible, mais comme toi, je ne m’interdit pas un div de plus et même un attribut si besoin. C’est la productivité avant tout !
Pour le css, je n’ai pas encore utilisé de fichier de reset.
Je remet juste les margin & padding à zéro.
je garde tout dans une seule feuille de style structuré avec des commentaires et je fais la même chose que toi pour le reste. Ca me va très bien pour l’instant, mais je ne travaille pas sur des gros projets. Si c’était le cas, je pense que je structurerais dans des différents fichiers css (reset, nav, global, clear, …).
Voilà, il y a aussi la partie javascript.
Personnellement, j’utilise la bibliothèque jquery.
Très simple à prendre en main et cela me satisfait pleinement.
Et enfin dans mon cas, le php/mysql, mais ca , ce sera le sujet d’un autre post
Maintenant, ce que je voudrais savoir, c’est combien de temps pour faire tout ca pour un petit à moyen site. Layout web, intégration, etc … ?
@Ben
Ca m’arrive de tester IE6 uniquement à la fin (en croisant bien les doigts) mais le problème est qu’il y a quasiment toujours quelque chose de cassé, et il est difficile de déterminer d’où vient le problème. Le fait de regarder au fur et à mesure si ça fonctionne sous ie6 permet de savoir plus précisément où se situe le problème.
Pour la partie js/jquery, je n’en fais pas. Ca m’arrive d’en mettre pour avoir une expérience plus enrichissante en démo, mais c’est juste pour la démo.
@sharky
J’aurais en effet dû ajouter une partie brainstorming. Et pour le fait de rétrécir les noms des classes, il y a en effet un juste milieu à trouver entre rester lisible et rester compréhensible.
A propos du reset, j’utilisais aussi le *{ margin:0; padding:0;} pendant longtemps mais je me suis rendu compte qu’il y avait mieux. Le reset CSS de Yahoo! est plutôt bien, et pas trop long. Je le préfère à celui d’Eric Meyer.
Et en tout et pour tout, le temps d’intégration dépend de 2 choses :
- est-ce qu’il y a beaucoup d’éléments uniques ? C’est à dire des éléments qui sont n’apparaissent qu’une seule fois et qui doivent avoir leur style juste à eux. Il arrive que ces éléments s’intègrent mal avec le reste (notamment si il y a une image de fond avec ombre portée par exemple).
- est-ce que toutes les pages sont livrées au début ? Si on a tout dès le départ, on peut voir les éléments qui se répètent d’une page à l’autre (même avec de légères variations). On peut alors avoir cette approche modulaire où on regroupe dans une classe unique les propriétés qui sont identiques, et puis qu’on applique les spécificités avec une contextualisation.
Donc le temps d’intégration peut varier de 2 à 5 jours en général.
On peut grandement faire chuter le temps passer sur l’adaptation à IE6 en gardant à l’esprit les règles suivantes :
- Tous les hacks IE 6 dans un fichier CSS à part avec commentaire conditionnel (http://www.alsacreations.com/astuce/lire/48-quest-ce-que-les-commentaires-conditionnels.html)
- Si le site n’est pas commercial, utiliser le script de Dean Edwards pour purement et simplement ignorer les déficiences d’IE6 au prix d’un chargement supplémentaire pour les utilisateurs du monstre (http://24ways.org/2008/the-ie6-equation)
- Si le site est commercial, utiliser un framework CSS qui gomme 90 % des problèmes de compatibilité. Évidement, l’outil est à adapter à ses besoins, sinon on risque le syndrome de l’usine à gaz. (http://www.blueprintcss.org/)
Par ailleurs, félicitation pour ce blog, tant au niveau des articles que pour le design qui reflète bien le point de vue que tu y décris en terme d’ergonomie et d’esthétique.
Oui, je suis de cet avis aussi
Lors de mes intégrations, j’utilise le hack avec un underscore devant les propriétés. Je ne dois pas passer plus de 5min sur du IE6. Certes cela n’est pas W3C au niveau du CSS mais c’est productif.
Pour ma part au travail on utilise effectivement une css de reset ce qui me semble aujourd’hui indispensable au travail d’intégration.
En ce que concerne la part de debug IE6, nous utilisons un système d’embriquement de div qui permet d’éviter déjà un grand nombre d’écueils liés à ce navigateur (qui représente quand même 10% de l’audience de nos sites). Nous utilisons également une classe clearfix qui règle pas mal de problèmes. Après comme l’a dit Ben, ce temps a tendance à diminuer avec l’expérience des bugs rencontrables
Pour nos sites nous avons plusieurs css distinctes (aucune dédiée à IE6 ; nous essayons d’utiliser le moins possible les hacks). En fait nous découpons nos css selon leur utilité : mise en page globale, reset, png, etc. C’est par souci de clarté car nous sommes une dizaine à pouvoir potentiellement toucher à ces fichiers donc c’est rapidement le bordel, alors ça évite les débordements (même si c’est pas encore ça XD)
Pour ton histoire de png, pourquoi tu n’utilises pas les filter ?
En fait, les filter niquent souvent mon design. Parfois ça marche, parfois ça marche pas. Et je sais pas pourquoi exactement. Du coup, pour IE6, je fais des images sans arrondi souvent, et en GIF. C’est à peine moins joli, mais au moins ça casse rien du tout.