Je reviens aux sources et à mon grand dada avec l’intégration HTML au sens large du terme. J’ai choisi d’intituler cet atelier : industrialiser l’artisanat de l’intégration HTML. Rendez-vous le samedi 16 octobre 2010 à 10h50 dans les locaux de Télécom Paris pour en discuter … et maintenant, pour le préparer et en dessiner les contours.

Origine de l’atelier

Juste après l’édition 2009 de Paris-Web, je me demandais sur quoi je pourrais parler en conférence ou en atelier. Cette manifestation a le mérite d’attirer des orateurs de qualité … et ce n’est pas évident de monter sur scène en se disant : que pourrais-je apporter au public, qui ne soit pas de la redite et suscite autant d’intérêt qu’une Stéphanie Troeth, Karl Dubost ou Christian Heilmann.

Et là j’ai lu la lettre au papa Paris-Web d’Elie Sloïm. J’ai de suite pensé à un sujet lié à l’intégration HTML. Cette spécialité connaît une effervescence d’outils depuis 2008 (frameworks CSS, pré-processeurs CSS et performances Web) … pourtant les méthodes de travail restent toujours très liées au développeur, à son tempérament et à ses connaissances d’outils capables d’améliorer la productivité. Quelque chose de tout sauf normalisé, industrialisé.

Comme il s’agit également d’une pratique ayant du mal à accepter les changements – je me souviens encore des réticences liées aux frameworks, alors que dans tout langage de programmation ces outils sont perçus comme du pain béni – je me suis dis qu’il y avait quelque chose à faire.

Les axes initiaux de l’atelier

En préparant l’appel à propositions de Paris-Web, j’avais convenu que cet atelier devrait tenter de répondre aux objectifs suivants :

• dresser un état de l’art de l’intégration HTML
• offrir une large tribune à l’audience, notamment en partageant ses propres retours d’expérience
• déterminer ce dont on dispose et ce dont on manque en terme d’outillage

Par extension, je souhaitais répondre (au moins) à ces questions :

• comment bâtir des CSS indépendantes et réutilisables ?
• quand et comment utiliser un préprocesseur CSS ?
• comment dialoguer avec le graphiste ?
• comment dialoguer avec le développeur ?
• comment détecter les régressions et assurer une qualité de code en CSS ?

J’ai également repris l’historique des précédents Paris-Web pour voir que de précédents ateliers s’étaient déjà penchés sur la question de la chaine d’intégration. D’où mon souhait de ne pas forcément réinventer la roue.

Pour autant, les objectifs tout comme les questions ne sont pas figées dans le marbre. Cet article est également là pour capter vos avis et vos remarques, pour ajuster cela avant le jour de l’atelier.

Discuter, échanger, et créer

Enfin, mon évolution personnelle au long de cette année 2010 et certaines paroles de David Larlet résonnaient dans ma tête.
Un sujet de cette importance ne peut pas être magistral. Pourquoi ? Parce que tous les intégrateurs rencontrent une variété de conditions de travail différentes, et qu’il serait d’autant plus difficile d’obtenir un consensus en prodiguant cet atelier de manière magistrale.

D’où l’idée d’introduire l’atelier par un bref résumé de mes retours d’expérience sur les frameworks (existants, ou créés pour le besoin), les pré-processeurs CSS, leur combinaison ainsi que l’application de la philosophie Object Oriented CSS. Quelque chose comme 10/15 minutes maximum.

Le reste du temps serait réparti de manière équitable sur chacune des questions, et animé sous forme de discussion. Chaque participant répondrait (via des post-it, je les fournirai ) par 1 ou plusieurs réponses, positives et négatives. En gros, ce qu’il faut faire, et ce qu’il ne faut pas faire.

Cette collecte en live des post-it, affichés au tableau, permettrait de dresser une cartographie des bonnes et mauvaises pratiques, des actions à mener et dont il faut se méfier.

A défaut de parler d’une industrialisation vidant l’intégration HTML de son côté artisanal, on aurait une excellente occasion pour tous se poser ensemble les bonnes questions, et repartir avec des réponses et des idées pleins la tête.

Conclusion

Bref, si le sujet de l’intégration HTML vous préoccupe, est au centre de vos intérêts et que vous souhaitez en améliorer sa pratique professionnelle (pour une meilleure reconnaissance de celle-ci ?), je vous invite à la fois à venir à l’atelier technique du samedi (il reste quelques places ; ça ne coûte que 22€) et à réagir en commentaires. Je ferai mon possible pour adapter l’animation de l’atelier à vos problématiques et questionnements.

Cet atelier serait ainsi à l’image de Paris-Web : une grande discussion conviviale, constructive et enrichissante.
L’idée sera ensuite de concrétiser ces échanges soit par un ensemble de billets de blogs soit, si la matière le permet, en livre blanc.

Ne me demandez pas ce que je prévois pour 2011, je n’en ai aucune idée … pour l’instant

Je me décide à passer un coup de peinture sur ce blog quasiment 2 ans après le CSS Summer Refresh organisé par Alsacréations. À vrai dire, j’avais ce projet dans les cartons depuis septembre 2008 mais le plus difficile a été de trouver le talent graphique. C’était également l’occasion de dire au revoir aux navigateurs Web de seconde zone, à savoir Internet Explorer 7 et moins.

Le besoin

Mon besoin était le suivant :

• Thème graphique
  • durable et peu lassant
  • usage de transparence
  • toujours sur des tons marrons
  • inspire la modernité tout comme le côté rustique et soucieux de la nature
  • structure en grille pour intégrer avec Blueprint
• Fonctionnalités
  • intégration d’un lifestream (intégré entre temps)
  • intégration de Feedburner via son API Awareness
  • intégration d’un bandeau Flickr qui s’étend sur toute la largeur de l’écran, peu importe la résolution employée
  • utilisation du blog comme vitrine : suppression de ma dernière page HTML manuelle (autrefois accessible sur oncle-tom.net)
• Compatibilité
  • navigateurs modernes … c’est à dire rien en dessous d’Internet Explorer 8
  • intégration avec HTML 5
  • pas d’utilisation de GIF mais de PNG 6 et PNG 24
• Autre
  • soucis de performance (peu d’éléments graphiques, utilisation des sprites)

Finalement c’est Lesly qui s’est chargé de la création graphique. Vous pouvez d’ailleurs consulter la maquette graphique originale sur son portfolio. Quant à moi, j’ai réalisé toute l’intégration CSS/HTML dans WordPress.

L’intégration

Tout d’abord, qu’est ce qui a changé par rapport à la maquette ?

• les polices de caractère : hormis le titre, seules des polices standards ont été employées. J’attendrai le support des polices personnalisées en CSS 3 à moins de partir sur une solution à base de SVG (encore que j’ai des doutes sur l’accessibilité d’une telle méthode) ;
• moins d’éléments graphiques : les punaises, les effets papiers ont été supprimés. Rien que le papier et le scotch de la partie « À propos » pesaient plus de 60Ko ;
• abandon temporaire du featured content : les solutions actuelles étaient trop lourdes et j’étais trop impatient pour passer quelques heures de plus … donc c’est temporaire
• l’ajout des pages en lieu et place du fil d’ariane : j’en avais besoin pour présenter différents contenus statiques ;
• le pied de page : peu de widgets WordPress offrent un degré de personnalisation suffisant pour arriver à ce résultat. C’est donc temporisé là aussi en attendant de trouver chaussure à mon pied

Aperçu pleine page

Pour le reste je me suis fait plaisir avec notamment l’utilisation de coins arrondis (border-radius) basés sur les implémentations de Gecko et Webkit. Désolé pour les utilisateurs d’autres navigateurs car j’en ai usé et abusé afin d’éviter l’utilisation d’images.

J’ai également joué avec l’API de WordPress pour générer les vignettes des articles. Je sais bien qu’on peut définir des tailles d’images mais ça ne vaut que pour les médias nouvellement mis en ligne. J’en ai profité pour n’afficher dans le listing que l’extrait du billet. Pas l’intro, seulement l’extrait (excerpt). J’ai lu récemment un article qui parlait de la chose et ça m’a paru plus approprié. Je peux désormais écrire le texte qui me convient pour attirer la lecture vers un article sans pour autant que ça ait de répercution sur son contenu une fois affiché en pleine page.

Je suis en revanche toujours dubitatif sur l’API de WP Cron : ma tâche a beau être enregistrée et planifiée, j’ai l’impression qu’elle ne s’exécute jamais … contrairement aux recherches de mises à jour de plugins & cie. Quelqu’un a déjà joué avec et rencontré pareil problème ?
Mise à jour : j’ai résolu le problème et détaillé la marche à suivre dans l’article affichage personnalisé de ses lecteurs Feedburner. Je planifiais une fonction et non un hook. Cela fonctionnait mais ne produisait fatalement pas de résultat

Au final je n’ai même pas eu à placer la moindre ligne de JavaScript : tout est fait à partir de sélecteurs CSS. Mon seul regret : l’absence de sélecteur adjacent … « précédent ». Pour le menu du haut, je voulais pouvoir styler les éléments de menus ayant comme élément suivant une liste d’élément (<ul>).

Au final

J’ai mis à peu près 2 jours pour tout intégrer et optimiser. Je n’ai pas encore tenté l’optimisation à coup de PNG 8 grâce aux quelques Ko gagnés avec pngcrush. Il faudrait également que je réunisse quelques images dans un seul et même sprite pour gagner encore quelques dizièmes de seconde en temps de chargement.

Rapport YSlow

J’en ai profité pour tester l’utilisation de mod_expires et mod_gzip chez OVH en mutualisé (avant de tout migrer sur serveur dédié) : ça marche plutôt très bien. Si ça vous intéresse, je peux en faire un billet dédié. D’ici là, n’hésitez pas à bouquiner High Performances Web Sites qui reste une référence en la matière. J’attends d’ailleurs sa suite avec impatience : Even Faster Web Sites: Essential Knowledge for Frontend Engineers.

Quoiqu’il en soit, le fait d’avoir eu la pleine utilisation des sélecteurs CSS a été géniale : la vie est grandement facilitée. inline-block évite de nombreuses bidouilles à base de flottants. J’ai hâte qu’une version de Blueprint sorte en se basant uniquement sur les sélecteurs avancés et non des flottants pour disposer de mises en forme plus complexes tout en étant facile d’accès.

Si vous rencontrez des problèmes, surtout n’hésitez pas à les signaler, par le biais des commentaires ou par email

En attendant, je retourne sur mon projet éprouvant du moment !

J’ai enfin pu assister à mon premier Paris-Web à Paris du 13 au 15 novembres 2008 inclus. C’était bien, très bien mais que dis-je : excellent ! J’ai rarement eu aussi peu envie de rentrer chez moi après cette multitude de rencontres dans un état d’esprit des plus respectueux.

Y’a même pas de troll pendant la conférence Internet Explorer 8, c’est dire.

Les conférences en quelques mots

Les conférences de Paris-Web 2008 étaient réparties du jeudi au vendredi. Je souhaitais intituler cette partie « mes conférences préférées » mais en faisant le décompte, j’en citerais au moins 75% :

• Qualité et accessibilité Web : vers l’amélioration continue
• Travailler dans le présent
• Accessibilité, des volontaires ?
• Internationalisation
• La mode se démode, le <style> jamais
• Identité 2.0 et Web sémantique
• IE8 et les standards du Web
• Performances côté client

Stéphane Deschamps

Ce qu’il faut retenir c’est que désormais, nous sommes dans une époque où nombre d’outils sont à notre disposition. Il faut maximiser l’utilisation d’outils déjà existants et s’en servir pour bâtir nos applications, interfaces et présentations.

Il faut également qu’on en finisse avec notre approche trop technique et intégriste de travailleurs du Web : le client se fiche éperdument de la techno employée ou de la fonctionnalité en elle-même. Ce qui compte c’est ce qu’elle apporte ainsi que le résultat final.
Bien entendu, si la solution employée tient compte des performances et est facile à mettre en œuvre, c’en n’est que mieux.

Élie me faisait la remarque : il faut vendre de la qualité et pas de l’accessibilité. Il faut vendre un site qui rassure et guide le client. Si le site n’est déjà pas adapté aux individus sans déficiences, à quoi bon s’acharner à le rendre accessible ?
Mieux vaut beaucoup de sites accessibles à 60% qu’une infime proportion de sites accessibles à 99%.

Bon nombre de conseils sur l’optimisation des sites Web étaient déjà cités dans l’excellentissime livre High Performances Websites. L’équipe Exceptional Performance de Yahoo! s’est toutefois penchée à fond sur l’optimisation des images.
J’y reviendrai d’ailleurs car j’ai découvert pngnq et pngcrush. Ces 2 programmes sont d’une utilité redoutable pour compresser et optimiser vos PNG, notamment pour faciliter la transparence IE6 sans douleur.

Chris Wilson

On terminera également avec une perspective du futur.
Daniel Glazman a fait un show exceptionnel sur les nouveautés de CSS3 avec tout plein de bonnes choses. J’ai vraiment hâte qu’on puisse jouer avec … peut-être dans pas si longtemps que ça vu que les navigateurs intègrent ces nouveautés par anticipation.

De son côté, Chris Wilson (qui faisait déjà partie de l’équipe de développement de Mozaïc) a abordé les standards et Internet Explorer 8. En toute honnêteté, j’admire la bravoure de cet homme « seul » face à une assemblée pro-standards qui passe sa journée à jeter des cailloux sur Internet Explorer.
Pour avoir un peu discuté avec lui après coup, il représente une chance exceptionnelle d’enfin avoir Internet Explorer au niveau des autres navigateurs.

Si fonctionnellement je me fiche éperdument du navigateur puisque je ne l’utiliserai plus, le monde a tout à gagner à avoir un navigateur de plus à respecter les standards.
Bon courage à Chris car ça ne doit pas être évident tous les jours pour lui. Je n’ose pas imaginer les montages qu’il a dû déplacer pour imposer ce choix du respect.

Du côté des ateliers

Le samedi c’était ateliers : 2 sessions le matin et 2 l’après-midi. Je me suis d’ailleurs vite retrouvé avec des choix cornéliens puisque pour chaque horaire, il y avait 5 sujets qui se faisaient concurrence.

J’ai pour ma part assisté à :

• Rédaction Web et référencement naturel
• Validation avancée des formulaires
• Développement efficace avec les frameworks CSS
• RDFa vs Microformats

La rédaction Web était intéressante même si je n’ai pas appris grand chose et j’en profitais pour terminer mes slides. Vous retrouverez tout le contenu de cette présentation dans le livre l’écrit Web.

La validation avancée des formulaires partait d’un bon principe mais s’enfonçait inutilement dans certaines parties. À mon avis, expliquer chaque fonction (y compris celles du DOM) était une perte de temps.
Conseil : charger ses slides ne rend pas pour autant l’information digeste. C’est pas un document Word.
C’était néanmoins intéressant pour le raisonnement et la satisfaction de mettre en place son propre validateur. Toutefois en production autant utiliser de l’existant. Il y a des plugins pour tous les bons frameworks JavaScript qui se respectent.

Je passe sur l’atelier des frameworks CSS puisque je l’animais. J’y reviendrai dans un prochain article pour appuyer ma présentation et fournir des explications à ceux qui n’ont pas pu y assister.
J’étais en revanche étonné qu’ils soient si peu connus. J’ai par contre été enchanté de les voir cités à plusieurs reprises dans mes conférences préférées

Rien à redire sur RDFa vs. Microformats même si on aurait pu éjecter les microformats rapidements et plonger encore plus loin dans la pratique de RDFa. Ça sera prétexte à une suite plus technique l’an prochain

La sublime Amélie Boucher

Sans oublier les gens !

Paris-Web c’est aussi l’occasion de rencontrer la moitié de son aggrégateur et de ses followers Twitter

Et Dieu sait s’il y avait tout un tas de pointures du Web à notre disposition dans une ambiance exceptionnellement cordiale :

• Sophie Major, big boss du Yahoo! Developer Network
• Nicole Sullivan, de l’équipe Yahoo! Exceptional Performance
• Christian Heilmann et son incroyable bonne humeur pragmatique ; je suis fan !
• Daniel Glazman, du CSS Working Group ; franc, direct et j’aime ça
• Sans oublier pêle-mêle Than, Sébastien Delorme, Monique, La Lène, Amélie Boucher, Hellgy, Raphaël Goetter, Fabrice Bonny, François Hodierne, Xavier Borderie … et en oubliant très certainement plein d’autres :’(
• Et d’excellentes découvertes : Anthony Ricaud, Mathieu Pillard et toute l’équipe Paris-Web !

La brochette des meilleurs !

Conclusion

Bref, Paris-Web c’est bien. Tellement bien que l’attente de l’édition 2009 me paraît déjà insoutenable !

Je ne regrette au final qu’une chose : 3 jours ça paraît long mais ça passe teeeeeeeeeeeeellement vite en compagnie de personnes de qualité avec un programme chargé.
J’ai essayé de discuter avec un maximum de personnes, que je connaissais ou pas, mais des fois c’est très insuffisant.

Les tables rondes étaient également exceptionnelles … désolé ça frise le billet sponsorisé mais il est difficile de ne pas déborder d’enthousiasme après un tel évènement.

C’est l’effet Paris-Web. Rendez-vous est pris.

Firebug fait partie de mes extensions préférées depuis un bon moment. Je l’estime aujourd’hui même plus importante que l’extension Web Developer, c’est dire.

J’ai pourtant constaté que la plupart de ses utilisateurs la sous-exploitait en se limitant à la console pour consulter les erreurs et éventuellement à l’inspecteur HTML pour remonter rapidement dans l’arborescence des balises en 1 clic. C’est bien mais pas assez.
Firebug est tout simplement énorme ! Suffisamment énorme pour gagner un temps incroyable dans le développement d’applications JavaScript et pour mieux comprendre les incohérences des CSS dans une page, entre autre.

Je vous offre aujourd’hui mon cadeau de Noël pour gagner en productivité et maîtriser cet outil ô combien indispensable.

Le plus amusant dans l’histoire c’est que le site officiel de Firebug dévoile (succinctement certes) tous les petits plus qui simplifient la vie. Je vais m’atteler à les éplucher en fonction des domaines d’utilisation :

1. pour le HTML et les CSS
2. pour le JavaScript
3. pour gagner en performances

Firebug pour le HTML

L’inspection HTML

J’apprécie l’inspection HTML car elle me permet de retrouver simplement le code lié au visuel. Après avoir activé l’inspecteur, je survole l’élément sur lequel je veux travailler, je clique dessus et le volet Firebug se fige dessus en m’indiquant toutes ses propriétés CSS, le modèle de boîte et ses propriétés DOM. On en reparle tout de suite après.
L’inverse est également possible. C’est à dire qu’en survolant le code, la correspondance visuelle dans la page est établie. C’est rudement pratique pour repérer des éléments qui sortent du flux. Ça l’est d’autant plus que les différentes marges (internes, externes, bordures) sont elles aussi mises en surbrillance.

Le gros atout de cet inspecteur c’est également l’édition à la volée de toutes les balises ! Idéal pour tester diverses classes d’un objet ayant un impact visuel fort sur son affichage. Cet outil présente un gain de temps énorme par rapport à la modification du code dans son éditeur et un petit coup de touche F5 dans la foulée.

Il faut également retenir que toute balise est sélectionnable en cliquant sur son nom (div, h3 etc.). Cela a a pour effet de mettre à jour le panneau latéral de Firebug. Panneau latéral qui est également fort utile.

L’inspection CSS, Layout et DOM

Le panneau latéral de l’inspecteur HTML se compose de 3 onglets, tous très utiles.

Inspecteur CSS

Les propriétés CSS affichées concernent uniquement l’objet actif et c’est ce qui en fait sa force. Ce panneau indique en effet la cascade CSS en cours ce qui permet de comprendre rapidement pourquoi sa feuille de style n’est pas appliquée comme il faudrait. Elle a la bonne idée de mentionner quelle feuille de style est utilisée et quelle ligne. De quoi corriger ça dans son éditeur favori rapidement.

Ou pas. En effet l’inspecteur CSS permet, tout comme l’inspecteur HTML, de modifier les propriétés à la volée et sans fioriture. Si je précise sans fioriture c’est parce que l’éditeur à la volée de Web Developer rend parfois l’affichage de la page bancale en décalant des éléments. Là vous pouvez totalement compter sur l’éditeur intégré et ce n’est pas un luxe !
Désactiver, supprimer, modifier ou ajouter des propriétés sont quelques-unes des actions que vous pourrez effectuer à même la page.

Là encore c’est une des parties où les gains de temps sont énormes. On peut en effet modifier ses CSS et les tester tout en observant l’impact immédiat de ses modifications.

Inspecteur du modèle de boîte (Layout)

Le modèle de boîte CSS peut vite devenir pénible à gérer et plus particulièrement quand on visualise mal le cumul des différentes marges.
Dans tous les cas c’est appréciable de pouvoir constater les marges en présence et encore, de pouvoir modifier leurs dimensions à la volée. Firebug a la bonne idée de colorer les marges intérieures (padding), extérieures (margin) et les bordures (border) d’une couleur différente.

Il a également la bonne idée d’afficher une double règle millimétrée au survol du panneau layout. Très pratique dans le cas de design en grilles ou nécessitant un certain rythme de visualisation.

Inspecteur DOM

Ah l’inspecteur DOM ! S’il n’existait pas il faudrait l’inventer. Firefox proposait déjà un tel outil à la différence près qu’il était moins pratique d’utilisation.
L’inspecteur DOM m’est moyennement utile dans le cas d’une simple inspection du code HTML bien que ce soit toujours pratique de visualiser la présence ou pas d’objets JavaScript dans tel ou tel élément. C’est fortement appréciable pour la librairie Prototype étant donné les dégâts causés par son extension du DOM à gogo.

Firebug pour le JavaScript

L’inspecteur JavaScript

C’est l’autre outil indispensable de Firebug. Avec lui, c’en est fini des alert(mavariable);. L’inspecteur DOM prend avec lui toute son utilité.

J’illustre sur l’image ci-dessus l’utilisation des points d’arrêt (breakpoints). Il suffit d’un clic à gauche d’un numéro de ligne pour en placer/retirer un. Concrètement quand l’exécution du JavaScript arrivera au premier point d’arrêt, elle va se stopper.
Quel intérêt ? Observer. En agissant ainsi, vous avez la main sur toutes les variables connues au sein de votre code/fonction. Très utile pour connaître les paramètres passées à la fonction et détecter les erreurs. C’est pour cette raison que les alert() deviennent inutiles : tout est à portée de main. Vous ne pesterez plus contre un undefined mal placé

En parallèle de ça, l’inspecteur DOM est à utiliser pour visualiser d’un coup d’œil les différentes variables actives ainsi que leur arborescence. Comme tout est cliquable, l’inspecteur vous transporte sur n’importe quel objet pour en étudier le contenu.

La console Firebug alias console.*

La console Firebug est l’autre tueuse d’alert() et s’utilise de deux manières.

La plus accessible est d’interagir avec. Vous saisissez votre code, la console l’exécute et retourne le ou les résultats. Encore une fois les objets sont cliquables et navigable au travers de l’inspecteur DOM.
La console est utile pour utiliser des fonctions sorties du contexte de l’initialisation : il devient tout à fait possible de piloter des éléments après le chargement de la page. Ça évite encore une fois des F5 inutiles et consommateurs de temps.

L’autre manière d’utiliser la console c’est de ne pas l’utiliser. Ou pas de manière active tout du moins puisqu’elle est également un objet JavaScript (console) utilisable dans votre code auquel sont rattachées plusieurs fonctions au nom explicite :

• console.log() : affiche une information standard
• console.info() : affiche une information de type « information »
• console.warn() : affiche une information de type « avertissement »
• console.error() : affiche une information de type « erreur »
• console.debug() : débogue le contenu d’un objet directement dans la console

Autrement dit, si l’inspecteur ne suffisait pas, au lieu de lancer un alert(mavariable) (potentiellement dangereux dans une grande boucle qui n’a jamais cliqué 50 fois sur « OK » à cause de ça ?), il vaudra mieux utiliser console.log(mavariable). Il y a de quoi faire, surtout avec la possibilité de créer des groupes de messages et l’utilisation de la syntaxe printf.

Et top du top, en cas d’erreur JavaScript, la console affiche un petit cercle rouge qui rappelle fortement le point d’arrêt. Normal puisque c’en est un. Un clic et on évite de rechercher la ligne problématique dans le code. Encore une fois, du temps de gagné.

Firebug pour les performances

Après avoir bien développé, Firebug propose de mieux développer. L’extension magique propose quelques outils sympathiques pour rapidement déceler les problèmes, notamment de scripts trop gourmands ou à optimiser.

Le traceur réseau

Avec le traceur réseau c’est simple, tout ce qui est chargé sur la page est chronométré. Si un élément est systématiquement long à charger en tête de liste, pourquoi ne pas essayer de le déplacer dans le bas de la pile ? Je pense notamment aux appels vers des fichiers JavaScripts externes. Les appeler en bas de page permet d’éviter des gels de page. C’est ce que YSlow nous recommandera

Outre une petite prévisualisation des contenus, le traceur affiche aussi les statuts des contenus s’ils sont différent du statut 200 (found). Et de surligner ça en rouge en cas de fichier introuvable.

J’aime beaucoup le traceur pour le suivi des requêtes XHR (appels AJAX). Un clic sur un appel affiche à la fois les entêtes, les données transmises au serveur et sa réponse. Fini les requêtes AJAX qui ne produisent rien sans qu’on puisse savoir pourquoi. Le clic droit sera également un fidèle allié, notamment pour ouvrir l’appel AJAX dans un nouvel onglet. C’est plus lisible pour déboguer quand même

Le profileur JavaScript

Le profileur (profiler) JavaScript s’utilise un peu à la manière de la console : de manière active ou au travers de l’objet console.

Le profileur enregistre tout ce qui se passe entre le moment où il est enclenché et le moment où il est stoppé. Il va ainsi dénombrer toutes les appels (calls), leur durée d’exécution et leur fichier d’origine, entre autre. L’idée est bien entendu de voir ce qui consomme le plus d’appels et de temps pour savoir si ce comportement est normal ou pas. À ce stade là, difficile de pousser la granularité du profileur plus loins.

Sauf en utilisant le profileur directement dans le code comme on a déjà pu le faire pour les logs. console.profile() et console.profileEnd() seront vos amis. C’est vraiment l’idéal pour profiler l’exécution d’une fonction, voire même les portions de code exécutée en son sein.

L’extension YSlow

L’extension YSlow est une extension pour Firefox mais elle nécessite toutefois la présence de Firebug. Elle s’articule autour de trois critères.

Il y’ a d’une part la surveillance des performances. YSlow se base sur la liste des bonnes pratiques établies par Yahoo! (14 à l’heure actuelle). YSlow passe ces critères en revue et accorde une note en conséquence. Si certaines sont difficiles à tenir, c’est un bon moyen de s’intéresser à de nouvelles pratiques d’optimisation et de performances.

Le second critère est affiché dans le panneau stats. Il s’agit de la capture d’écran ci-dessus. Certes il s’agit d’un simple tableau mais dont les chiffres sont intéressants à étudier. YSlow analyse la page pour un premier et un second chargement. La différence entre les deux ? C’est que le cache est passé par là et normalement, je dis bien normalement, le second chargement se doit d’être beaucoup plus rapide.
Si ce n’est pas le cas, il y a de l’optimisation à faire et cela peut aussi signifier du côté serveur Web. Pas forcément du développement donc.

Enfin on termine sur une partie complémentaire aux stats : les composants (components). Elle distille des informations plus verbeuses que le traceur réseau de Firebug en se focalisant sur les E-Tag, la présence ou pas de compression, la date de validité du cache ainsi que la taille des objets.

Conclusion

J’espère avoir éclairé quelques lanternes sur l’utilisation de Firebug. Cette extension est suffisamment puissante pour gagner en confort de développement ; il serait dommage de s’en priver. On gagne du temps, du confort et surtout, de la qualité de développement.
À noter qu’il existe aussi Firebug Lite. Il s’agit d’un script JavaScript compatible avec les principaux navigateurs du marché mais comme le Lite l’indique, les fonctionnalités sont plutôt limitées. Seule la console JavaScript persiste.

JQuery est une formidable librairie JavaScript car elle offre une grande souplesse et une utilisation simple. Il est cependant important de bien comprendre son fonctionnement pour éviter les débordements liés à une joie mal maîtrisée.
S’il est très facile d’utiliser les sélecteurs CSS de jQuery, je constate de ci de là que leur utilisation n’est pas toujours optimale … quand elle l’est déjà un tant soit peu.

Alors on se retrousse les manches et c’est parti pour un petit cas pratique sur les sélecteurs CSS jQuery, plus une petite récap’ pour grapiller du temps et des lignes de code

Le cas pratique

J’ai pensé à une chose : plutôt que vous papillonniez en lisant cet article, j’ai fait en sorte que vous puissiez y prendre part. JQuery est très divertissant – certainement plus que votre voisine d’en face – alors tant qu’à me lire, autant optimiser la compréhension
Pour cela il vous faut 2 choses :

1. un bac à sable HTML / jQuery concocté par mes soins
2. l’inévitable extension Firebug pour bénéficier d’une console digne de ce nom (entre autre)

Principe de la sélection CSS de jQuery

Que celui qui s’est lancé corps et âme dans jQuery sans lire la documentation lâche un com’ ! Elle est suffisamment complète pour éviter la plupart des questions du genre comment je fais pour ….

Maintenant que vous avez le document en main, nous allons jouer avec jQuery pour récupérer ce que nous voulons. Les personnes n’ayant pas Firebug comprendront la logique du code sans même avoir à le regarder :

// Récupération du premier paragraphe
$('body p:first-child');
// Récupération du nœud des continents
$('ul.continents');
// Récupération de la liste des capitales
$('.capitale');
// Récupération du dernier élément du body
$('body :last');
// Compter le nombre de pays
$('.pays > li').length;

Magique non ?

Comprendre la sélection CSS de jQuery

Les résultats sont propres mais n’est pas parce que ça marche que c’est bien. La preuve, tous les exemples ci-dessus ne sont pas du tout optimisés.
Alors comment savoir si un sélecteur est optimisé ou pas ? La réponse n’est pas systématique car elle dépend exclusivement de votre rigueur et du DOM à interroger. Plus il sera touffu et plus votre sens aigü de la performance sera sollicité.

Reprenons les exemples ci-dessus pour le transposer en JavaScript old-school. C’est le meilleur moyen de sentir le piège … ou pas.

// Récupération du premier paragraphe
$('body p:first-child');
// équivaut à
document.getElementsByTagName('body')[0].getElementsByTagName('p')[0];

Il y a 2 erreurs dans cette sélection :

1. sélectionner body. getElementsByTagName() oblige à parcourir tous les nœuds du document (1000 s’il y en a 1000) alors qu’on n’en veut qu’un … et qu’il ne peut y en avoir d’un ;
2. on sélectionne ensuite tous les p du body. Autant le faire dès la première fois car là encore c’est tous les nœuds contenus dans body qui sont parcourus … y compris l’énorme liste à puces !

// Récupération du nœud des continents
$('ul.continents');
// équivaut à
var continents = [];
var el = document.getElementsByTagName('ul');
for (i in el)
{
  if (el[i].className.match(/(^| )continents( |$)/);
  {
     continents.push(el[i]);
  }
}

La sélection est ici trop générique. On voit bien que l’on est obligé de charger tous les éléments ul du DOM pour les filtrer.

// Récupération de la liste des capitales
$('.capitale');
// équivaut à
var capitales = [];
var el = document.getElementsByTagName('*');
for (i in el)
{
  if (el[i].className.match(/(^| )capitale( |$)/);
  {
     capitales.push(el[i]);
  }
}

C’est probablement la dernière chose à faire. Cassez les genoux de toute personne écrivant un tel sélecteur : il mérite d’animer le BigDill rien de plus !
Dans ce cas de figure, c’est TOUT le DOM qui est chargé (75 éléments) pour ensuite boucler sur un filtre. Cette boucle n’est pas optimisée mais ce n’est pas ce que l’on souhaite travailler aujourd’hui

// Récupération du dernier élément du body
$('body :last');
// équivaut à
var el = document.getElementsByTagName('body')[0].lastChild;

Comme dans le premier cas, le document.getElementsByTagName() charge tout le DOM pour le filtrer, ne récupérer que le premier élément et, seule opération non coûteuse, utiliser son dernier enfant.
Ce n’est pas la pire des exemples mais là encore on peut optimiser les choses.

// Compter le nombre de pays
$('.pays > li').length;
// équivaut à
var pays = 0;
var el = document.getElementsByTagName('*');
for (i in el)
{
  if (el[i].className.match(/(^| )pays( |$)/);
    {
      var continent = el[i];
      for (j in continent.childNodes)
      {
        pays += continent.childNodes[j].nodeName == 'li' ? 1 : 0;
      }
    }
  }
}

Un sélecteur par classe ne devrait être qu’un cas extrême, quand on ne peut se fier à une balise donnée. Car de manière générale, le getElementsByTagName('*') est à bannir. Charger tout le DOM est une folie furieuse.
La bonne idée ici est l’utilisation du symbole >. Cela se traduit par .childNodes et nous verrons plus bas pourquoi c’est mieux.

Et maintenant, optimisons

S’il fallait résumer l’optimisation en 3 points, voici ce que je donnerai :

1. jamais de sélecteur vague
2. toujours un ID (#<ID>) en tête de sélecteur
3. utiliser au maximum les objets natifs (firstChild, childNodes etc.) : ils évitent d’interroger tout le DOM

L’ennemi des sélecteurs CSS ce sont les boucles. Plus elles ont à brasser d’éléments, plus elles sont longues. getElementsByTagName() cache une boucle : JavaScript scanne tout le DOM pour trouver un nœud ayant un tagName correspondant.
S’il faut l’utiliser, c’est en aval d’un sélecteur ayant déjà trié une bonne partie du document.

Votre meilleur ami est getElementById(). Comme son nom l’indique il ne retourne qu’un seul élément et surtout, il est incroyablement rapide. Utilisez-le dans un maximum de cas mais attention tout de même : trop d’ID nuit à la structure du document le rendant ainsi trop rigide.
Il en est de même du parcours des objets natifs des nœuds du DOM. Cela signifie que dès que vous changer la tête de votre HTML, le JavaScript peut en pâtir.

Des fois il faudra faire quelques concessions de performances pour éviter de réécrire votre code au moindre changement … ou parce que la génération est dynamique et difficilement maîtrisable.

Grâce à ces informations, nous pouvons reprendre nos exemples mais de manière optimisée :

// Récupération du premier paragraphe
$('body p:first-child');
// version optimisée
$('#sandbox > p:first');
// Récupération du nœud des continents
$('ul.continents');
// version optimisée
$('#geoliste');
// Récupération de la liste des capitales
$('.capitale');
// version optimisée (mais fortement liée à la structure du document)
$('#geoliste > li > ul ul > li.capitale');
// Récupération du dernier élément du body
$('body :last');
// version optimisée
$('#sandbox :last');
// Compter le nombre de pays
$('.pays > li').length;
// version optimisée (mais liée à la structure du document)
$('#geoliste > li > ul > li').length;

Évitons les doublons : chaînons !

Les CSS c’est un peu fatiguant alors terminons sur une autre utilisation de jQuery parfois sous-employée à cause d’un manque de compréhension : les chaînes. jQuery renvoie des objets et permet de réutiliser/filtrer les résultats avec un seul sélecteur.

Voici un extrait de code largement optimisable :

$('#intro').addClass('jevaisdisparaitre');
$('#intro').append(' <strong>Je vais disparaître</strong>.');
$('#intro code').html('Goodbye World');
$('#intro').css('cursor', 'pointer');
$('#intro').one('click', function(){ alert("Bye bye"); $(this).remove(); });

Tout est correct sauf qu’on répète plusieurs fois le même sélecteur au lieu d’utiliser la chaîne disponible. jQuery optimise la sélection d’un élément déjà sélectionné au préalable mais n’empêche, au lieu d’interroger 5 fois #intro, nous n’allons plus le faire qu’une seule fois :

$('#intro')
  .addClass('jevaisdisparaitre')
  .append(' <strong>Je vais disparaître</strong>.')
  .one('click', function(){
    alert("Bye bye");
    $(this).remove();
  })
  .children('code')
  .html('Goodbye World');

Tout se suit jusqu’à la fonction children() qui modifie le sélecteur de départ et applique la suite de la chaîne à cette nouvelle sélection.
Une autre optimisation consiste à déplacer la déclaration CSS cursor dans la classe .jevaisdisparaitre de l’hypothétique feuille de style. Essayez de dissocier au mieux fond et forme : ça évite BEAUCOUP de modifications de code pour des ajustements esthétiques.

Conclusion

Optimiser ses sélecteurs n’est finalement pas si difficile que ça quand on comprend comment fonctionnent les rouages internes. Il est évident que les gains peuvent être minimes sur de petites pages. Il s’agit cependant d’une gymnastique à maîtriser : ce n’est pas en arrivant sur de gros volumes qu’il faudra apprendre à sélectionner proprement.

Et comme les petites rivières font les grands fleuves, ces petites économies pourraient vous sauver la vie sur des applications full-AJAX ou qui sait, quand vous travaillerez chez Netvibes