La présentation

J’ai complètement changé d’axe d’approche entre l’appel à proposition de Paris Web et le jour venu. J’ai retourné le sujet dans tous les sens pour arriver à transmettre le message de la manière la plus adaptée qu’il soit au public. Parce qu’il est vraiment essentiel de comprendre votre auditoire.

De ce fait, j’ai préféré laisser tomber l’atelier magistral où j’aurais été le seul à partager. L’approche choisie fût celle de l’interaction design (IxD) ; notion découverte la veille pendant la conférence de Stéphanie Troeth. L’idée étant de construire ensemble le corps de l’atelier, de produire ensemble la réflexion et d’en arriver à des conclusions plus rapidement.

Le plus amusant fût qu’on arrivait aux mêmes conclusions, et que les slides suivant la phase de design répondaient aux questions nouvellement créées.

Pour l’expérience, et le résultat produit, j’en suis satisfait

Déroulement de l’atelier

L’atelier consistait à passer en revue 3 des étapes du développement frontend : l’intégration HTML, l’habillage CSS et les interactions JavaScript. Chaque étape se divisait en 4 composants de travail :

• Production / réalisation
• Organisation / équipe
• Documentation
• Tests

Pour chacun de ces composants, toute personne dans la salle pouvait suggérer une bonne pratique, une mauvaise pratique ou un outil. Cela s’est matérialisé avec un tableau blanc découpé en 4 zones, dans lesquelles on collait des post-it.

Pour la petite histoire, n’ayant pas pensé à acheter les post-il avant d’arriver à Paris, je me suis rabattu sur le premier choix venu, en me basant sur la connaissance du terrain de David Larlet : Loisirs & Créations du Bercy Village.

C’est ainsi que je me retrouvais avec 200 post-it en forme de cœur,  de maison ou de fleur.

Un peu de gaieté pour un atelier sérieux et créatif.
D’ailleurs, parce qu’on n’a pas bossé pour rien, et que Paris Web c’est aussi la création en plus de share the love, voici la carte mentale de notre heure de travail :

Constats

Mon premier constat, en regardant la carte mentale, c’est qu’on a quand même réussi à produire un bon nombre d’éléments en 1 heure, avec un public qui n’était pas préparé et dans une configuration de salle de classe, remplie de surcroît.
La logistique s’est organisée d’elle-même, avec des contributions diverses pour ramasser les post-it, leur circulation et même la modération.

Quant au contenu en lui-même, plusieurs remarques s’imposent :

• la très grande majorité des contributions concernaient la production (c’était flagrant, face au tableau)
• par extension, il y a peu d’éléments de documentation et de tests et dans une moindre mesure, peu de travail en équipe/organisationnel (à part les classiques versionning)
• en production de CSS et de JavaScript, le nombre de mauvaises pratique équivaut ou dépasse les bonnes pratiques

En une phrase et une seule : le développement frontend, en tous cas représentatif de la population présente dans la salle, travaille dans son coin, avec ses méthodes, peu adaptables à d’autres cadres.

Et la suite ?

Mon avis c’est que si la production n’est pas forcément industrialisable au sens où on ne peut que difficilement automatiser la production du code, en revanche on peut automatiser les tests et la documentation, voire certains aspects d’organisation (diffusion automatique des commits, rapports etc.).

Une de mes hypothèses est que si le caractère individuel du travail est si marqué, c’est que nombre des méthodes, astuces et outils de travail sont basés sur des avis subjectifs. Pas étonnant que les réactions sur le mot industrialisation soient si virulentes et chargées d’émotions.

C’est une des raisons pour laquelle j’ai proposé en conclusion d’aller au-delà de nos jugements personnels pour formaliser des bonnes et mauvaises pratiques, que l’on applique ensuite à son projet si l’on est concerné. Un mélange des guidelines BBC et des bonnes pratiques Opquast en somme.

Ce que j’aimerais, c’est produire 2 livrables :

• une checklist de bonnes pratiques de développement frontend
• un livre blanc du développement frontend, comprenant en plus le processus de dialogue entre acteurs, pendant les phases projet

Ces livrables seront Open Source, libres, gratuits et créés collectivement, parce qu’on a tous des terrains d’expertise différents et complémentaires.

Share the love

Je ne manquerai pas de vous tenir informé des avancées de ces projets, qui me tiennent à coeur.
Je ne saurais que trop remercier les participants, présents lors de l’atelier Paris Web, ceux qui apporteront leur pierre à l ‘édifice (même si ça ne concerne qu’un changement de virgule dans une phrase) et ceux qui apporteront leur soutien, Elie Sloïm en tête. Il propose en effet de mettre à disposition la plate-forme Opquast en tant qu’outil de contribution.

Une idée qu’elle est bonne.

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

J’ai eu peur il y a 2 semaines en arrivant à Paris-Web 2008 : en discutant avec plusieurs personnes, il se trouve que peu d’entre elles connaissaient les frameworks CSS. Je craignais de n’attirer personne avec ce sujet lors des ateliers du samedi.

Les frameworks CSS ont été mentionnés la première fois dans la conférence Working in the Now (visualiser la présentation). Au final, on n’était pas loin de faire salle comble avec plus d’une vingtaine de participants à vue de nez.

Une petite scéance de rattrapage s’impose

Pourquoi avoir choisi ce sujet ?

J’ai lu un article sur l’importance du rythme vertical l’an dernier sur Biologeek et ça m’a sensibilisé au fait qu’on pouvait rendre la lecture d’un site tout simplement en rendant prédictible la position du texte.

Entre temps j’ai également lu l’excellent Transcender CSS d’Andy Clarke. J’y ai été sublimé par des présentations de sites totalement en grille.

Depuis je suis devenu fan de Blueprint CSS (je crois que ça s’est remarqué lors de mon intervention ). J’ai commencé à l’utiliser sur des projets personnels puis dans un cadre professionnel. J’utilisais déjà symfony comme framework PHP et jQuery comme framework JavaScript alors pourquoi pas Blueprint ?

Comme le suggérait très justement Christian Heilmann dans sa présentation, l’utilisation d’outils déjà existants est nécessaire pour réduire les coûts de production. C’était déjà un bon alibi mais je les apprécie aussi parce qu’on gagne un temps fou ! On se concentre sur le code métier, pas le reste.

La présentation

Je n’en dis pas plus, je vous laisse lire la présentation. Ayez toutefois en tête qu’en vrai elle dure facilement 1h.

Ce qu’il faut en retenir

J’ai rencontré 2 types de réactions lorsque j’ai parlé des frameworks : les enthousiastes et les réfractaires.

Je ne reviens pas sur les enthousiastes : il suffit de lire ma présentation. Les atouts les ont clairement séduit.
Je m’intéresserai plutôt aux réfractaires. Assez paradoxalement, ce n’est pas dans la salle que je les ai eu mais en dehors. Les principaux arguments étaient :

• ça rajoute des kilo-octets superflus
• on perd le contrôle de notre code
• j’utilise déjà le mini-framework d’un collègue ou qui existait dans mon entreprise avant que j’arrive

Ces arguments sont tout à fait acceptables … mais ça dépend dans quel contexte.

Exemple de mise en forme en grille

Les sites à la recherche de performances exceptionnelles, ceux pour qui un Ko supprimé économise plusieurs Go de bande-passante par jour … oui ceux-là ont un grand intérêt à réfléchir à l’adoption d’un framework, aussi compressé qu’il soit.
Je ne me fais pas de soucis pour eux : en général ils ont leur propre framework, totalement adapté à leur besoin. Cependant ça n’empêche pas d’aller prendre des idées ailleurs et de découvrir de nouveaux concepts. Puis de les intégrer.

Lorsqu’on adopte un outil de développement rapide (RAD), la conception ne se fait plus par rapport à nos habitudes mais par rapport à des principes établis. On ne fait plus forcément comme on veut mais les meilleurs frameworks disposent de fonctionnalités répondant à cette problématique. Le compressor de Blueprint en est un parfait exemple.
Il permet de construire une version de Blueprint adaptée à son besoin, inclut des feuilles de notre choix et compresse le tout en un seul fichier prêt à la mise en production.

Maintenant l’avantage d’un framework c’est qu’une communauté ou un groupe de personnes compétentes en ont la gestion. Ces mainteneurs produisent une documentation, des spécifications et un code suffisamment compréhensible à lire. Ce n’est pas forcément le cas de Joe le développeur à qui on aura demandé 36 choses en même temps.
Je fais davantage confiance à un outil éprouvé avec succès sur des milliers de projets qu’un outil développé sur un coin de bureau, malgré toute la bonne volonté de son concepteur.
C’est également un risque certes mais un bon outil délaissé aura tout de même le mérite de fonctionner … et d’avoir davantage de chances de trouver un repreneur.

Une remarque intéressante a également émergé de l’atelier : faut-il utiliser un framework CSS avant ou après que la créa graphique ait été établie ?
Je réitère ma réponse : l’idéal est que tout soit pris en charge le plus tôt possible. Autrement dit, intégrer les contraintes du framework dès la conception graphique est un gros atout. Le découpage de la maquette n’en sera que facilité et ça évitera tout bricolage.
Certains outils l’ont d’ailleurs bien compris en proposant des supports pour graphistes au format PSD, Visio, Fireworks etc.

Feuilles de dessin pour 960 Grid System

Conclusion

Quoiqu’il en soit, les frameworks CSS sont à mon avis promis à un bel avenir dès lors que les critères d’industrialisation auront débarqué au sein des agences Web.

Aujourd’hui une petite agence a tout à gagner à maîtriser de tels outils et à annoncer qu’elle développera mieux, plus vite et moins cher. Le prix ne fait pas tout : ce sont les outils et la qualité du développement. Tous les frameworks cités sont également des logiciels libres.

J’espère que cet aperçu rapide aura ouvert les yeux à certains d’entre vous. Je suis preneur de vos retours, surtout en entreprise. Ça vaut également pour celles et ceux qui ne sont toujours pas convaincu de l’intérêt des frameworks CSS

Remarque : il y avait 2 ateliers complémentaires à Paris-Web :

• Optimiser ses CSS
• Cascade et héritage : concevoir, organiser, optimiser et maintenir ses feuilles de style

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.

Tout développeur, que ce soit à l’école ou en apprenant sur le tas, écrit du code. J’espère n’avoir perdu personne à ce stade de l’explication

Inconsciemment on cherchera à utiliser un style d’écriture avec lequel on se sent à l’aise, qu’on pourra et saura relire facilement et dans le meilleur des cas, qui pourra être relu par une autre personne sans avoir à engager d’interprète.

Tout développeur tend donc à utiliser des conventions de programmation (coding standards), que ce soit en HTML, PHP, CSS, JavaScript ou même en Cobol. Et utiliser des conventions, c’est bien !

Quelle convention de nommage adopter ?

Avant de choisir une convention, encore faudrait-il savoir quelles conventions existent :

• pas de convention
• convention hongroise
• convention PEAR
• convention symfony
• convention Zend Framework
• convention WordPress (que j’abhorre)
• etc.

Autant dire qu’il y a de tout et pour tous les goûts.
Ce qu’il faut retenir d’une convention c’est qu’elle explicite des règles de développement :

• sur le nommage des éléments
• sur l’indentation des éléments
• sur les structures de contrôle (if, else, tout ça quoi)
• sur la syntaxe des commentaires
• sur la syntaxe de la documentation (le code auto-documenté c’est bon !)
• sur l’organisation des fichiers, éventuellement

C’est pour ça que partir sur une convention parfaite sur le papier mais inapplicable est une vaste fumisterie. L’idéal étant de pouvoir reprendre du code dans un projet sans avoir eu besoin de lire la documentation pour en comprendre l’organisation.

Mon conseil : essayez, choisissez mais ne prenez pas non plus trop laxiste en terme de notation.
Une chose est sure : quand on a essayé une belle

Mes conventions de nommage en PHP

J’avoue, la notation utilisée dans symfony m’a tellement plu que je la réutilise quasiment partout. Ci-dessus, une illustration montrant du code pour un plugin WordPress (en PHP 4 malheureusement …). Elle en présente un bon aperçu.

Notation

J’utilise UpperCamelCase pour le nommage des classes sauf s’il y a un préfixe qui, lui, reste en minuscule.
Exemples : class AmazonWidgetsShortcodes, class sfUploader.

Pour ce qui est méthodes de classes, j’utilise lowerCamelCase. Comme ça on sait qu’on reste dans un objet et c’est pas plus mal.

Enfin, pour les fonctions orphelines, helpers & cie, c’est tout en minuscule séparé par des underscore (un nom particulier à ça ? lowered_and_underscored ? )
Exemple : add_filter()

Indentation

Dans l’indentation il y a 2 camps : celui des espaces et celui des tabulations.

J’ai suivi celui des espaces pour une simple et bonne raison : 1 tabulation a une taille différente selon les éditeurs, que ça soit votre IDE, votre shell ou n’importe quel logiciel de texte. L’idéal est d’avoir un rendu identique dans tous les éditeurs sans paramétrage.

En revanche, là encore je suis mais j’aime, je suis sur une tabulation à 2 espaces : c’est bête mais je trouve ça plus esthétique et on arrive moins rapidement à la limite de 80 caractères.

Cette « limite » n’est que virtuelle mais ouvrez un terminal, 80 lignes par défaut. C’est plus confortable de rester en-dessous de ce nombre. Ceci dit je fais quelques exceptions, des fois

Structures de contrôle

On pourrait résumer à 1 ligne = 1 action et 2 types d’utilisation.

Tout d’abord les structures dans le code à proprement parler :

• un espace entre l’opérateur et la parenthèse ouvrante
• un retour à la ligne à chaque accolade
• pas d’espaces dans les lignes vides (résidus d’indentation)
• systématiquement les accolades, même en cas de ligne unique après l’opérateur
• opérateur ternaire quand ça reste simple, pas trop long et plus lisible

Côté templating en revanche j’utilise la syntaxe alternative de PHP à raison d’un opérateur par ligne :

<ol class="posts">
<?php foreach($posts as $post): ?>
  <li id="post-<?php echo $post->getId() ?>">
    <a href="<?php $post->getPermalink() ?>">
      <?php echo $post->getTitle() ?>
    </a>
  </li>
<?php endforeach ?>
</ol>

Syntaxe de la documentation

Enfin, pour terminer sur la partie PHP, PHPDoc est surpuissante en plus d’être simple à utiliser. Comble du bonheur, sa syntaxe est réutilisable dans d’autres langages.

PHPDoc est le principe du code autodocumenté :

1. vous commentez votre code avec la syntaxe PHPDoc
2. vous générez sa documentation avec le programme PHPDoc (en HTML, PDF etc.)

L’idéal est de documenter en même temps qu’on produit le code. Par principe on revient rarement sur son propre code juste pour le loisir de le décrire, par manque de temps ou par flemme.

Mes conventions de nommage en JavaScript

Ne vous inquiétez pas, je ne vais pas tout recommencer pour JavaScript Je suis à peu près la même logique qu’en PHP à part pour les accolades.

En effet si je conserve un comportement similaire pour les structures de contrôles (1 accolade par ligne) :

• je ne fais pas de retour à la ligne sur les accolades/parenthèse ouvrante d’une fonction/objet anonyme
• je ne fais pas de retour à la ligne après une accolade/parenthèse fermante s’il y a une virgule ou parenthèse après

var OncleTom = {
  age:      25,
  pensee:   function(){
    return this.age * Math.random()
  }
};

Mes conventions de nommage en CSS

Inutile de paraphraser ce que j’ai déjà écris dans mon article sur les bonnes pratiques de codage CSS.

Deux lectures en une oui

Conclusion

Bon au final on voit que ce n’est pas si compliqué que ça d’apporter un brin de rigueur.
On pourra même s’amuser à compléter le tout par la disposition des méthodes et fonctions d ans un fichier par ordre alphabétique (j’en connais un que ça fera sourire ).

Les vues Outline fournissent un plan du code et certains logiciels ne semblent pas disposer d’une fonction de tri. Et au cas où un jour vous n’auriez pas votre IDE favori sous le nez, ça ne mange pas de pain de fonctionner ainsi.

Que l’on travaille seul à plusieurs, et à plus fortes raison dans ce dernier cas, l’utilisation de notations et conventions est un gage de qualité. Ça rend le travail plus facilement interopérable avec d’autres développeurs, plus facile à relire, plus facile à maintenir.

Ça n’empêchera jamais des bugs ou de sortir du mauvais code mais c’est ça, c’est une autre histoire.

Enfin, j’aimerais terminer cet article en écrivant qu’il a fait l’objet d’une chaîne par le Padawan PHPiste Damien Alexandre. C’était l’occasion de faire une réponse qui passe inaperçue

Ça ne m’empêchera en revanche pas de refiler la patate chaude à NicoDePrendreUnCafé, de tenter d’insuffler de l’activité au blog de Xavier Lacot, de Spipifier Gastero Prod, d’extirper une technique ninja pyjama à remouk et pourquoi pas lire avec attention l’avis pythonien de David Larlet ?

Et just for fun, un petit coup d’électrode à un de mes futurs étudiants, Thierry Poinot.

High Performance Web Site, sous-titré Essential Knowledge for Frontend Engineers, est ce genre de livre à lire au moins une fois à défaut de le posséder. Il résume en à peu près 120 pages 14 points d’optimisation d’un site Web.

C’est d’autant plus intéressant que l’approche se base sur les mécanismes et non sur de l’optimisation de code. Ainsi dans la plupart des cas, vous n’aurez « que » du paramétrage serveur à faire.

Ce livre fait étrangement penser aux conseils de haute performance prodigués par le Yahoo! Developer Network et repris par l’extension Firefox pour Firebug, j’ai nommé YSlow.
C’est normal : ce livre est écrit par un ingénieur de Yahoo!, probablement un de ceux qui ont participé à la rédaction du guide de performances.

Pourquoi acheter High Performance Web Sites ?

On serait tenté de ne pas acheter le livre puisqu’une bonne partie de ses conseils sont repris sur le guide de haute performance cité plus haut.

Sachez toutefois que cet ouvrage va plus loin dans le détail, prend bien le temps de présenter ses tests de performance pour illustrer et de justifier l’application de leurs méthodes. La plupart des relevés de mesure sont effectués sur une dizaine de sites allant de Google à Amazon.

J’achèterais ce livre si j’étais :

• un administrateur système chargé d’héberger 1 ou plusieurs sites Web
• un technicien/webmaster en charge d’un site à plus ou moins fort trafic
• un développeur Web soucieux des performances de ses productions
• toute personne avare en kilo-octets superflus
• toute personne voulant accélérer les temps de réponse de son ou ses sites Web

Les 14 points d’optimisation

High Performance Web Sites axe son discours sur 14 points :

1. Limiter le nombre de requêtes HTTP
2. Utiliser un Content Delivery Network (CDN)
3. Utiliser une entête Expires
4. Compresser les composants avec Gzip ou Deflate
5. Placer les feuilles de style en début de page
6. Placer les scripts JavaScript en bas de page
7. Éviter les expressions CSS (Internet Explorer)
8. Placer les scripts JavaScript et les feuilles de style dans des fichiers externes
9. Réduire le nombre d’appels à des DNS différents
10. Minifier le JavaScript et les CSS
11. Éviter les redirections
12. Supprimer les doublons de scripts
13. Configurer ETags
14. Permettre la mise en cache des appels Ajax

Il prend cependant le soin de bien expliquer les mécanismes d’HTTP et les intérêts à améliorer les performances frontend.

Le livre termine sur un comparatif des 14 points sur 10 sites, notation YSLow comprise, dont Amazon, Google, CNN, eBay, Wikipédia et Yahoo!.

La mise en pratique

J’étais déjà sensibilité à presque tous les points pour avoir lu ces fameuses 14 règles en utilisant l’extension YSlow et Firebug. Cependant après la lecture du livre j’ai eu davantage de clés et des exemples probants pour me convaincre de les mettre en œuvre.

On peut appliquer la majorité des points et les points pertinents en 1 heure. En effet, tout site ne peut se permettre d’utiliser un CDN pour accélérer les temps de réponse autour du globe.

Personnellement j’ai mis en place une compression Gzip directement au niveau d’Apache au lieu d’utiliser une compression effectuée en PHP (avec Gzip aussi). J’ai couplé cet effort avec la minification JavaScript et la désactivation des ETags.

J’avais déjà au préalable externalisés mes CSS et JavaScript, placé au bon endroit (mais seulement les appels externes au DNS principal en bas de page) et sans doublon.

C’est bête à dire mais le résultat s’est vraiment senti avec des chargements de page incroyablement plus rapides. YSlow est effectivement un compagnon idéal pour la mise en application de ces éléments avec son analyse des performances et des composants.

Conclusion

J’ai dévoré High Performance Web Sites grâce à sa simplicité de rédaction, les nombreux exemples et surtout, les explications enrichissantes. Elles sont mises en application sur Yahoo! et certes, même si on peut se dire qu’on n’a pas de site de leur envergure, leurs conseils sont toujours bons à prendre.

High Performance Web Sites est un concentré de bonnes pratiques, simples à mettre en œuvre. Pourquoi s’en priver ?

Ces optimisations ne sont évidemment pas les seules à mettre en place pour que tout fonctionne bien : il faut aussi produire du code HTML propre, du JavaScript optimisé, du code application qui ne soit pas redondant.

C’est un bon début et des pratiques à généraliser.

J’ai tenu ma première conférence vendredi 29 février 2008 à l’occasion de BlogCamp Bordeaux #3. Petite conférence car il n’y avait « qu’une trentaine » de personnes face à moi. Une fréquentation plus qu’honorable si on tient compte de la jeunesse de BlogCamp France, à savoir 3 mois.

C’est l’occasion pour moi d’aborder cette session par un angle un peu différent, en parlant notamment de l’aspect présentation : où, quand, comment et surtout combien de temps. Ce sera un bon complément du résumé officiel et du wiki BlogCamp Bordeaux #3.

L’atelier BlogCamp Bordeaux #3

Cette présentation m’a pris à peu près 8h de travail, en comptant le temps de recherche de la mise en page. On utilisait en effet pour la première fois un modèle commun. Ces 8 heures ont été réparties de la sorte :

• 2 heures de recherche « artistique » et de manipulations d’OpenOffice Impress infructueuses
• 3 heures consacrées aux grosses questions (au nombre de 2)
• 3 heures consacrées aux petites questions (au nombre de 3)

8 heures de préparation pour … 45 minutes de présentation. J’avais une crainte là-dessus mais si la présentation avait duré 5 à 10 minutes de moins ça aurait été mieux. C’est noté pour la prochaine fois
Comme toujours, une présentation en direct est autrement plus parlante puisque les slides ne sont qu’un support à la discussion.

L’exercice consistait à répondre à des questions posées au préalable : de la gestion générale à du très précis ciblant la présentation d’un blog particulier. L’occasion de vulgariser au maximum des concepts tels que les sauvegardes, le référencement et les feuilles de style.

Les faits marquants de BlogCamp Bordeaux #3

Outre la razzia sur les boissons (après 1h il n’y avait déjà plus rien à boire), j’ai noté une grande mixité des participants : étudiants, salariés, patrons … tous liés au Web … ou pas. Le dénominateur commun de toutes ces personnes était clairement la curiosité de découvrir un évènement lié au Web à Bordeaux.
C’est d’autant plus satisfaisant que ces personnes en sont reparties le sourire aux lèvres, ravies d’avoir rencontré de nouveaux contacts et constaté qu’à Bordeaux, ça bougeait enfin un peu. Une progression à suivre.

Je note aussi la présence de la « Dream Team » bordelaise avec des représentants des sociétés ADDEO, Websiteburo, Clever Age mais surtout Temesis. J’espère très sincèrement que la prochaine fois on pourra davantage discuter et échanger tous ensemble sur le Web à Bordeaux.

La rumeur du jour serait qu’un blog commun aux sociétés des TIC serait en cours de création pour diffuser de l’information liée à l’économie du Web à Bordeaux. J’espère que ça se concrétisera et contribuera à dynamiser l’économie numérique de la région.

J’y songeais mais l’article «De l’ordre, que diable !» m’a incité à m’y atteler plus tôt que prévu.
Il n’y a en effet pas de méthode universelle pour programmer les CSS mais après plusieurs années d’expérience, j’ai affiné ma réflexion que je vous livre aujourd’hui.

Où l’on parlera de présentation en 1 ligne, de CSSDoc mais aussi de folding et d’indentation. En clair, tout plein de bonnes pratiques de développement en CSS qui vous feront gagner du temps, vous éviterons de la sueur et sentent bon le travail de qualité.

Halte là et retour à la ligne !

J’ai utilisé pendant un moment la technique dite du single line CSS ; à savoir 1 ligne par déclaration.
Je n’hésiterai pas une seconde à dire que je déconseille fortement cette écriture pour les raisons suivantes :

• si on souhaite gagner de la place, il y a des compresseurs (je recommande YUI Compressor): pas la peine de réaliser ce travail nous-même ;
• l’ajout de commentaires n’en est que plus compliqué : on a tous besoin de commenter certains passages cruciaux, notamment les hacks et autres fix ;
• c’est tout bonnement illisible dès qu’on s’y replonge quelques semaines plus tard : imaginez pour quelqu’un qui n’a pas écrit le code !

Les arguments avancés pour cette technique ne tiennent pas la route : on recherche avant tout la qualité et la facilité de relecture. Les quelques kilo-octets à perdre se feront par le biais de programmes. Ça ne doit certainement pas entraver le développement.

L’auto-documentation avec la syntaxe CSSDoc

Les habitués de Java connaissent JavaDoc.
Les habitués de PHP connaissent PHPDoc.
Les habitués de JavaScript connaissent JsDoc Toolkit (dérivé de JsDoc).

Il était donc tout naturel que cette syntaxe de commentaires et d’auto-documentation soit utilisable en CSS avec CSSDoc. Il n’y a pas d’inconvénient à l’utiliser, au contraire, que des avantages :

• la syntaxe permet d’harmoniser les commentaires sur les projets impliquant plusieurs développeurs ;
• sa syntaxe facilite la relecture puisqu’elle est connue et employée dans de nombreux langages, autres que les CSS ;
• l’auto-documentation du code c’est faciliter la génération d’une documentation externe en automatisant le processus ;
• documenter en même temps que l’on écrit c’est comprendre ce que l’on fait et gagner du temps en évitant une écriture a posteriori ;

La syntaxe CSSDoc est documentée, aisément reconnaissable et est supportée par les meilleurs éditeurs CSS, dont Aptana IDE :

/**
 * @author Oncle Tom
 * @lastmodified Fev, 26 2008
 * @media print, screen
 * @site http://www.oncle-tom.net/
 */
/**
 * Redéfinition des balises HTML
 *
 * @section html
 * @todo utiliser un reset.css conforme
 */
html,
*{
  margin: 0;
  padding: 0;
}

L’organisation hiérarchique

J’ai pour habitude de travailler avec une seule feuille de style par media. Comme je travaille sur des hiérarchies thématiques, leur découpage en plusieurs fichiers ne consiste qu’à du copier/coller. On peut ainsi facilement passer d’une mono-feuille à du multi-feuilles. Je ne suis pas un fervent utilisateur de ces dernières car un code bien lisible sur une seule page n’est pas problématique.
Je ne l’emploie que pour faciliter la réutilisation des CSS sur plusieurs projets partageant la même base graphique.

Concrètement, je vais d’abord organiser ma feuille pour redéfinir les éléments HTML génériques puis créer autant de sections qu’il n’y en a sur ma page (navigation, contenu, navigation de contenu, contenus annexes etc.).
Plus je m’avancerai dans la profondeur du balisage HTML et plus j’indenterai mon code. Cette indentation fait penser à celle utilisée par le langage Python.

On pourrait résumer cette convention à ceci :

• pas de tabulation, que des espaces pour avoir le même affichage peu importe les éditeurs
• 2 espaces par tabulation
• attributs classés par ordre alphabétique (même logique pour tout le monde)
• une ligne d’espace entre les définitions ; pas de ligne entre les définitions proches/liées

C’est simple et voici un exemple de résultat :

/**
 * Redéfinition du HTML
 */
a{
  text-decoration: underline;
}
  a img{
    border: none;
  }
p{
  line-height: 1.5em;
}
  p img{
    margin: 1.5em
  }
  p img.top{
    margin-top: 0;
  }
/**
 * Contenu
 */
#main-content{
  clear: both;
  width: 100%;
}
  /**
   * Articles
   */
  #articles{
    margin-bottom: 2em;
  }
    #articles h2{
      font-size: 1.5em;
      font-weight: bold;
    }

Les mieux organisés d’entre vous ajouteront un tri par fréquence d’utilisation afin d’optimiser les va-et-vient : on met en haut ce qu’on est susceptible de modifier le plus souvent, en bas ce à quoi on touchera rarement. Je ne vais pas jusque là mais ça reste envisageable, pertinent et surtout adapté aux plus chevronnés de l’optimisation.

Autres conseils et astuces

Utilisation de raccourcis

Les aficionados de l’optimisation et du gain de temps apprécieront cette méthode, s’ils ne l’utilisent pas déjà. J’ai pour habitude de placer des raccourcis dans mes sections pour faciliter l’utilisation d’une recherche via le raccourci clavier Control+F.
Je préfixe chaque raccourci d’un symbole = :

/**
 * Liens d'évitement
 * =evitement
 */

Je trouve cette méthode très pratique pour atteindre des portions de code. On évite ainsi un appel à la touche Alt Gr pour appuyer sur le # d’un ID (pour peu que l’on n’ait que des ID en tant que sections). On évite aussi les collisions de nom ou les recherches infructueuses pour cause de changement de nom de classes ou d’ID.

De la sémantique, que diable !

Je suis particulièrement attaché à cette bonne pratique d’autant plus qu’elle ne tombe pas forcément sous le sens de tout le monde : nommez vos ID et classes en fonction de leur signification, pas de leur représentation. C’est la suite logique de la séparation fond et forme du HTML et des CSS.

Mauvaise sémantique :

.rouge{
  color: red;
}
#sidebar{
  /* ... */
}
#top-links{
  /* ... */
}

Bonne/meilleure sémantique :

.important{
  color: red;
}
#alternate-navigation{
  /* ... */
}
#main-links{
  /* ... */
}

#sidebar pourra être renommé différemment selon son contenu, selon que l’encart contienne des éléments de navigation supplémentaires, des informations utilisateur (#user-content) ou encore des widgets (#widgets).
En conservant votre HTML intact et en jouant sur les CSS, la #sidebar peut en effet se retrouver tout en bas, à l’horizontale. Aurez-vous toujours envie de l’appeler pareil ? Pas forcément. Un bon nommage est un nommage qui se conserve peu importe l’aspect de la présentation.

Du choix de la langue

Cette bonne pratique s’applique aussi bien aux CSS qu’à d’autres langages. Il faut partir du principe qu’il ne faut pas mélanger les langues dans le code, tant dans les commentaires que dans le nommage des classes et ID. Choisissez-une langue et restez avec.
Certaines contraintes peuvent faciliter le choix de la langue : le travail avec une équipe internationale ou la redistribution du code. Dans ce cas l’anglais sera à 99% votre langue de prédilection.

Il n’y a pas de choix idéal : certains préféreront le tout français, d’autres le tout anglais. L’essentiel est que ce choix soit motivé par des arguments objectifs, pas une préférence personnelle.

Recours au folding

J’en parle succintement mais le folding consiste à utiliser votre éditeur CSS pour masquer une partie de code. Eclipse propose par exemple de masquer toutes les définitions et tous les commentaires : leur contenu n’est révélé qu’en le dépliant.

Je ne suis pas un fervent utilisateur de cette pratique bien que je respecte son utilisation. Je trouve qu’en utilisation les précédentes astuces (hiérarchie + recherche) on s’y retrouve très bien.

Conclusion

Ma méthodologie n’est pas parfaite, peut être perfectible et ne conviendra pas à tout le monde, par goûts ou par habitudes. Ces dernières sont cependant à combattre pour améliorer son travail. Quoi de mieux qu’un code propre, bien documenté et où l’on trouvera facilement ce que l’on cherche ?

C’est ce qui importe. Il y a autant de façons de coder qu’il n’y a de développeurs. Le tout est d’être ouvert aux améliorations possibles, aux méthodes existantes et à l’intérêt de leurs utilisations. Je trouverai peut-être cet article obsolète dans 1 an mais il aura été un point de passage.

J’espère qu’il le sera au moins en partie pour vous, développeur en herbe ou féru des pseudo-classes

Si seulement TiBo avait imaginé que son blog@bordeaux avait semé les germes de BlogCamp France … et pourtant c’est le cas.

Je vais évangéliser en faveur de cette association toute fraîche de promotion des blogs auprès des blogueurs … mais aussi ceux qui ne le sont pas (encore). Je vais également tâcher d’expliquer les motivations de mon implication et pourquoi ça vaut bien quelques cernes marquées. Il y a des tabous à lever … et des bonnes pratiques à apporter

BlogCamp, qu’est-ce que c’est ?

BlogCamp est un rendez-vous mensuel entre blogueurs dans l’esprit des BarCamp bien connus des technophiles. La seule différence est que dans un BlogCamp on parle blog life et pas forcément que de nouvelles technologies et d’Internet. Tous les blogueurs ne sont en effet pas des professionnels du Web (si, si).

Le décor est planté, reste à le comprendre.

Quand on constate que les 2/3 des blogs se paraphrasent entre eux, que les blogs sont associées à des récits puérils (y compris jusqu’au niveau des entreprises) et qu’à Bordeaux il manquait un tissu social numérique, l’idée de BlogCamp est née. L’idée d’une réunion conviviale où les outils et les connaissances seraient mis à disposition du public, blogueurs ou pas. L’essentiel étant d’être curieux et intéressé par ce phénomène auréolé de stéréotypes.

BlogCamp, le rendez-vous des blogueurs … et de ceux qui ne le sont pas

Les stéréotypes parlons-en. Ils gravitent autour de 2 expressions phares :

• Je suis blogueur
• Blogosphère

Le blogueur est une personne comme vous et moi : normale. Le blogueur n’est pas un être surnaturel ou un superhéros venu de Krypton pour sauver l’internaute lambda d’un ennui mortel. Être blogueur c’est avant tout une idée de partage, aussi maladroite soit son expression.

Ça rejoint d’ailleurs très bien l’idée que l’on forge de la blogosphère : fermée de l’extérieur, en circuit fermé de l’intérieur. En clair ça sent le moisi. Comment inciter les gens bien intentionnés et peu connaisseurs de se lancer dans un blog en pensant qu’il faut être fort et avoir de bonnes relations ?

C’est pour ça que BlogCamp s’adresse à celles et ceux qui ont un blog ou qui n’en ont pas mais qui souhaiteraient en avoir un.

Le contenu et les conversations au cœur des rendez-vous

BlogCamp cherche à créer du contenu en diffusant des bonnes pratiques, en dispensant des ateliers techniques et en réservant du temps aux échanges entre participants. Un soin tout particulier est apporté pour intégrer les nouvelles têtes afin de les mettre à l’aise.
Chaque mois ce sont des conférences, avec des intervenants extérieurs ou pas, pour éduquer les esprits :

• les blogs ne sont pas des sapins de Noël : la dizaine de widgets des barres latérales n’ont pas à exister
• l’identité d’un blog ça se construit : nous donnons les pistes à explorer
• le référencement d’un blog peut être facilité avec un minimum de bonnes pratiques

Bien d’autres concepts sont à aborder et leur orientation dépendra des sensations perçues lors des différentes interventions. L’idée est que tout participant y trouve son compte, apprenne des choses et mûrisse dans son approche du blog. Le kikoolol de SkyBlog a suffisamment hanté les consciences.

BlogCamp, le concept déclinable clés en main

La face cachée de BlogCamp c’est la réflexion dans sa conception : tout a été pensé pour que le concept soit facilement déclinable et facilement reproductible dans une autre ville de France.
BlogCamp c’est aussi une solution packagée clés en main avec nom de domaine, hébergement, emails, ressources (wiki, diaporamas, cartes de visite etc.) et toute la synergie médiatique. Quelques détails sont encore à régler mais en l’espace de quelques minutes, un nouveau BlogCamp peut se créer en France en un minimum d’efforts.

Pour cela, BlogCamp repose essentiellement sur du logiciel libre et des standards ouverts. Internet est né grâce à cette ouverture, les blogs doivent poursuivre sur cette voie.

La troisième session de BlogCamp Bordeaux se tiendra le vendredi 29 février 2008 à 19h00. J’espère y rencontrer un maximum de personnes désireuses d’en savoir plus sur les blogs et leur utilisation.
Profitez-en, c’est gratuit et c’est pas votre pouvoir d’achat qui rechignera

Le Web sémantique.
Cette expression est sur toutes les lèvres de ceux qui préparent l’Internet de demain. Moteurs de recherche, services de pointe, secteur marchand … après avoir indexé du contenu, ils aimeraient désormais le comprendre. Comprendre pour mieux cibler, mieux profiler et mieux servir.

Malgré cet aspect futuriste teinté de recherche et de développement, le concept de Web sémantique est pourtant vieux comme … le Web. Tim Berners-Lee y pensait déjà lorsqu’il accouchait d’Internet sur ses petites tablettes.

Si les hommes arrivent à comprendre les hommes, les ordinateurs ne comprennent que ce pourquoi ils ont été programmés. Le Web sémantique a été imaginé pour palier à ce problème, pour expliquer le sens du contenu, pour lier les contenus entre eux tout en décrivant ces relations.

En ce sens, les formats RDF et OWL figurent comme les étendards du concept. RDF décrit les ressources tandis qu’OWL établit des liens entre eux en leur donnant un sens. Ces relations sont nommées ontologies et permettent donc de transformer un Web de données anonymes en un Web sémantique. Un Web où humains et ordinateurs comprennent et échangent.

Les microformats sont nés du constat de complexité de mise en œuvre du couple RDF/OWL et d’un besoin de simplicité.

Les microformats

Tantek Çelik et Adam Rifkin dévoilent le concept des microformats en 2004 après 2 années d’expérimentation. Ils ne s’en cachaient pas : ils souhaitaient démocratiser et implanter la sémantique au cœur du Web en s’affranchissant au maximum de contraintes techniques.
C’est ainsi qu’au lieu de créer un énième format de fichier les microformats se greffent sous la forme d’attributs (X)HTML pour tenter de donner du sens au contenu.

Il existe plusieurs spécifications de microformats :

• hAtom (syndication de contenus, basé sur Atom) ;
• hCalendar (dates et évènements, basé sur iCal) ;
• hCard (représentation d’entité, basé sur vCard) ;
• hResume (CV, mélangeant hCard et hCalendar notamment) ;
• geo (emplacement géographique) ;
• XFN (relations entre individus) ;
• XOXO (description de contenus) ;
• et de nombreux motifs de conception rel-* (tags, nofollow, license, home etc.).

Intérêts et utilité des microformats

La force des microformats réside dans sa souplesse d’utilisation, leur approche métier et surtout, la réutilisation de formats existants.
Les microformats se basent sur deux attributs [HTML :

• <a rel="nofollow"> indique aux robots d’indexation des moteurs de recherche de ne pas suivre ce lien ;
• <span class="tel"> indique que cette balise neutre contient un numéro de téléphone ;
• <div class="entry"> indique que cette balise neutre contient un article (billet de blog par exemple).
  Rassurez-vous, le choix des classes n’est pas arbitraire et le wiki officiel est un bon guide. Il reprend les spécifications des formats cités précédemment tout en les agrémentant d’exemples.

Enfin, et pour achever d’attiser votre curiosité, voici un résumé des microformats en 7 points :

• ils s’adaptent au code et non l’inverse ;
• ils s’appliquent aussi bien sur des pages statiques que dynamiques ;
• ils aident à structurer la page ;
• ils n’ont quasiment aucun coût de mise en place ;
• ils aident et aideront à la bonne indexation du contenu dans les moteurs de recherche ;
• ils offrent des perspectives d’interaction et de navigation intelligente pour les visiteurs d’une page microformatée ;
• ils sont un socle pour réutiliser le contenu (cf. « Outils agrégeant les microformats »).

Cas pratique : offrir une carte de visite en visitant une page Web

Prenons par exemple le cas des fichiers vCard. Nos carnets d’adresses en raffolent car ils contiennent des informations de contact : nom, prénom, adresse, numéro de téléphone, email etc.
Il n’est pas rare de recevoir des emails contenant une vCard en pièce-jointe. Un clic dessus et les informations de l’expéditeur se retrouvent dans notre carnet d’adresses.

Les microformats proposent la même chose mais au format Web avec le microformat hCard. Outre la ressemblance de nom, on retrouve dans sa spécification tous les éléments de vCard (nom, prénom, adresse etc.).
La seule différence se trouve dans la représentation. Nous n’avons plus affaire à un fichier séparé (comme ça aurait été le cas avec RDF et OWL)
mais bel et bien à du texte présent sur une page Web.

Si ce code était placé sur une page Web accessible au public, n’importe quel outil gérant les microformats serait capable d’en extraire les données et pourquoi pas, de lancer une recherche sur
Google Maps pour obtenir les coordonnées GPS de l’adresse.

<div class="vcard">
  <a class="fn org url" href="http://www.clever-age.com/">Clever Age</a>
  <div class="adr">
    <div class="street-address">37, boulevard des Capucines</div>
    <span class="postal-code">75002</span>
    <span class="locality">Paris</span>
    <div class="country-name">France</div>
  </div>
  <div class="tel">
   <span class="type">Téléphone</span> +33 1 53 34 66 10
  </div>
  <div class="tel">
    <span class="type">Fax</span> +33 1 53 34 65 20
  </div>
  <div>Email: <span class="email">commercial@clever-age.com</span></div>
</div>

Outils proposant des microformats

Les industriels et les leaders du Web contribuent à diffuser les microformats en les adoptant progressivement. Cette adoption apporte une valeur ajoutée à leurs services et facilite la vie des utilisateurs.
Concrètement, ils microformatent leur contenu pour enrichir leur présentation et faciliter les interactions avec d’autres services.

Voici une liste non-exhaustive de services proposant des contenus microformatés :

• Blogs (WordPress) ;
• Cartographie (Google Maps, Yahoo ! Local) ;
• Emploi JobiJoba) ;
• Outils sociaux (Flickr, Del.icio.us, Ma.gnolia) ;
• Réseaux sociaux (LinkedIn, Ziki).

Outils agrégeant les microformats

L’utilisation la plus intéressante des microformats reste indéniablement l’agrégation. Vous pourrez ainsi construire un flux RSS à partir d’une page statique ou explorer
des photos en rapport avec la page visitée.

Technorati porte l’étendard des microformats. Ses différents services, utilisables en appelant une simple URI, permettent d’agréger des cartes de visites (vCard) ou encore des calendriers (iCal) pour générer des fichiers réutilisables dans votre carnet d’adresse ou votre gestionnaire de temps.

Jobster propose une utilisation intéressante des microformats. Ce site de recherche d’emploi vous évite l’écueil de l’énième ressaisie de CV. En lui fournissant l’URL de votre profil public LinkedIn, il en extrait toutes les données pour en générer un CV en ligne.

Les navigateurs Web jouent également le jeu. Firefox 2 (avec son extension Operator) ou encore Firefox 3 et le futur Internet Explorer 8 proposent des outils intégrés.
Sur chaque page visitée, ils en extraient tous les contenus microformatés possibles et proposent différentes interactions possibles.

D’autres outils plus confidentiels s’efforcent de défricher le terrain, notamment les agrégateurs de flux RSS/Atom et autres transformateurs XHTML/microformats :

• hatom2rss ;
• hAtom2Atom ;
• atom2rss ;
• X2V.

Conclusion

Il est de plus en plus facile de microformater les contenus, d’interagir avec et de les republier. Leur faible coût d’intégration et la rapidité
d’apprentissage sont d’autres atouts pour intéresser vos intégrateurs HTML, vos programmeurs ou même vos décisionnels.
La publication de microformats de LinkedIn et leur utilisation par Jobster pour préremplir automatiquement le CV sans ressaisie est le cas de figure idéal.
Ces pratiques ont pour vocation d’être généralisées, de quoi nous faciliter la vie.

Nous verrons dans une prochaine partie des bonnes pratiques d’intégration des microformats à des contenus déjà existants. Ce sera d’ailleurs l’occasion
de remarquer que sémantique, respect des standards et accessibilité génèrent une incroyable synergie.

Pour en savoir plus

• Présentation des microformats en mars 2006 au SXSW Interactive ;
• En route vers le Web sémantique ;
• Les 10 prochaines tendances du Web.

1. [1] Il en existe en réalité 3 mais l’attribut rev n’est employé qu’une fois. Difficile d’en déduire une généralité.

Je rédige sur ce blog depuis bientôt 3 ans, depuis plus de 5 ans sur Emu Nova et depuis quasiment 10 ans si on remonte à mon ancien site perso et mon site consacré à Star Wars. Ah l’époque des .fr.st .
Ce bagage m’a permis d’affiner mon écriture sur le Web mais je cherchais à l’améliorer. C’est précisément à ce moment qu’Olivier Ertzscheid offre la dernière préface issue de sa plume et qu’Élie Sloïm recommande un obscur livre : l’écrit Web.

J’apprécie ces hommes, entre autre, pour leur bonne parole donc il n’en fallait pas davantage pour me procurer cet ouvrage.

Pourquoi le lire ?

L’écrit Web se destine à toute personne désireuse de perfectionner son écriture. Et plus particulièrement l’écriture sur le Web.
Combien d’entre vous ou parmi vos connaissances n’ont jamais dis que lire sur un écran c’est fatiguant, les livre c’est mieux ? Une bonne majorité. Et c’est bien parce qu’on ne lit pas de la même manière un livre qu’un écran d’ordinateur qu’on doit impérativement adapter son écriture à un lectorat volatile, contraint par la technologie et difficile à capter.

L’écrit Web dispense ses bonnes pratiques pour mieux écrire sur le Web en suivant 6 grands axes :

1. organiser l’information
2. structurer son texte
3. adapter son style
4. soigner les microcontenus
5. penser indexation et référencement
6. bloguer

J’ai volontairement grassé les 4 axes les plus intéressants. Ils m’ont permis de conceptualiser beaucoup de pratiques que j’appliquais inconsciemment … et d’en découvrir d’autres.
L’idée générale n’est pas d’apprendre à écrire mais de réapprendre. Les raisons sont simples :

• on lit moins vite sur un écran d’ordinateur ;
• on lit en profondeur et non à plat, grâce aux liens hypertextes (qui ralentissent aussi la lecture).

Organiser et structurer

En partant de ces principes là, il faut donc songer à réorganiser ses textes voire ses sites Web d’une part pour faciliter la vie de ses lecteurs (occasionnels ou pas) mais aussi pour capter plus facilement leur attention. Que faites-vous devant un gros pavé de texte ou un site mal organisé ? Vous zappez. Alors pensez qu’on fait de même avec ce que vous écrivez .

En fin de compte tout contenu, que ce soit une page ou du texte, s’organise en suivant le principe de la pyramide inversée à l’image du triangle d’or d’une page Web si cher aux référenceurs. On commence par l’essentiel pour terminer sur du détail. Ça vaut également pour l’ordre des listes à afficher (chronologiques, géographiques, thématiques etc.).

Contrairement au papier où la lecture se fait à plat, on peut et on doit se servir de la navigation hypertexte pour désengorger les pavés de textes susceptibles de décourager la lecture. C’est ce qu’entend l’auteur par navigation en profondeur.
Plutôt que d’accueillir un visiteur avec beaucoup de texte, mieux vaut donc plusieurs boites aux titres informatifs présentant le contenu en une poignée de lignes.

Autre conseil judicieux, respecter les 5W (ou QQOQP en français) :

1. Qui ? (Who)
2. Quand ? (When)
3. Où ? (Where)
4. Quoi ? (What)
5. Pourquoi ? (Why)

En y songeant lors de la rédaction et en respectant l’ordre, on se retrouve à construire des phrases informatives, bien structurées et plaisantes à lire. Cumulez avec la pyramide inversée et c’est le gros lot : votre lecteur sait tout et tout de suite.

Comment mieux écrire pour le Web

Maintenant que l’on connaît l’ordre de rédaction, écrivons mieux. Écrivons court en suivant les principes 1 idée par phrase et sujet, verbe, complément. La lecture n’en est que fluidifiée. Si en plus il n’y a pas de fautes d’orthographe et que le style reste naturel, alors on touche presque au but.

Une des particularités du Web c’est la republication du contenu. On peut écrire un article pour un site mais le retrouver affiché sur d’autres sites, sur son téléphone portable, un agrégateur voire sur le même site mais sans son contenu (dans une liste par exemple).
Cette particularité est une bonne raison pour donner des titres explicites. Ils pourront ainsi être compris déconnecté de leur contexte. L’écrit Web propose des exemples clairs et compréhensibles vous aideront à mieux en comprendre les subtilités.

La construction des liens hypertexte était indispensable et mérite vraiment d’être lue par toute personne peu familière du référencement. Au-delà de cette pratique, ce sont tout simplement la compréhension et l’accessibilité qui sont en jeu. Pas de liens sur des cliquez ici, ici ou là. Je rajouterai même qu’il ne faut pas de liens ayant le même libellé pointant vers des URL différentes.
Tout comme le libellé du lien décrit le contenu vers lequel il pointe, il vaut mieux englober plusieurs mots (plus facile à cliquer) et qu’ils soient soulignés surtout ! Combien de chartes graphiques je reçois sans aucun lien soulignés ; j’outrepasse systématiquement cette mauvaise pratique du graphiste, dans le contenu en tous cas.

Conclusion

J’ai énormément apprécié et appris de ce livre, surtout les parties structurelles et organisationnelles. La pyramide inversée et les bonnes pratiques de rédaction sont des gros « plus » que j’ai rarement retrouvé ailleurs … ou tout du moins, pas concentré en si peu de pages.
Il se lit très bien et rapidement. J’ai prévu de l’offrir à quelques collaborateurs rédacteurs qui seront susceptibles d’en tirer des leçons et ainsi améliorer leur qualité rédactionnelle. Un bon investissement.

J’ai en revanche moins appris (voire rien du tout) sur les 2 derniers chapitres concernant le référencement et les blogs. Étant donné la quantité d’informations à traiter sur ces sujets, le contenu du livre était forcément un peu léger mais pas dénué d’intérêt pour les néophytes.
Ces parties étaient néanmoins plus techniques et à mon avis plus difficiles à comprendre pour des personnes survolant l’informatique.

Si vous ne saviez pas quoi faire de vos étrennes, que vous rédiger pour le Web et que le marketing vous intéresse, il y aura sûrement de bonnes idées à prendre

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

Concevoir un site Internet dans les règles de l’art demande de multiples compétences : architecture technique, programmation, graphismes, intégration, ergonomie et du bon sens. Transcender CSS : sublimez le design Web ! s’intéresse à l’aspect esthétique au travers des CSS.

Ou comment CSS, sémantique, intégration XHTML, microformats, sources d’inspirations et approche du design en grilles sont indispensables pour tirer partie du meilleur du Web.

Transcender CSS : sublimez le design Web ! est un ouvrage paru en France en août 2007 aux éditions Eyrolles ; en novembre 2006 dans le monde anglophone. Le livre est broché sur 360 pages ce qui en fait un livre imposant et propice à de riches illustrations d’excellente qualité. Andy Clarke, son auteur, s’est permis ce plaisir pour montrer au mieux qu’un site visuellement alléchant et bien structuré est un succès assuré pour capter l’attention du visiteur.

Transcender CSS ne s’adresse pas aux débutants puisqu’il ne s’attardera pas à vous expliquer les modèles de boîte ou les innombrables bugs d’Internet Explorer. Son contenu évolue toutefois en douceur de la facilité à la complexité ce qui le rend néanmoins abordable par des néophytes.

Découverte

Organiser les contenus avant tout, tel est le credo de Transcender CSS. C’est l’objectif majeur de cette première partie ; partie qui devrait être lue et transmise par tous les enseignants puisqu’elle explique comment on adapte le design au contenu et non l’inverse.

La mise en pratique du balisage XHTML est menée avec pédagogie. Vous apprendrez comment traduire une image en balises HTML de manière adaptée. Et un bon balisage c’est déjà la moitié du travail, l’autre restant son habillage. Il faut dissocier le contenu et la mise en page tout en n’oubliant pas un point essentiel : donner du sens au contenu.
Il existe de nombreuses balises XHTML qui ont chacune leur propre signification : il faut les utiliser pour donner du sens. C’est non seulement important pour le référencement mais aussi pour ancrer les feuilles de style de manière propre et efficace. Nos professeurs de français nous ont appris à utiliser des verbes riches au lieu de verbes pauvres (être, avoir, aller, prendre etc.) alors faisons de même avec les balises XHTML :

• <h1 à h6> pour afficher des titres hiérarchiques
• <p> pour des paragraphes de textes (les images sont du texte)
• <ul/ol/li> pour des listes de contenus
• <q/cite/blockquote> pour des citations de textes
• <pre/code/kbd> pour des saisies de texte au clavier ou des extraits de code
• <span/div> dans les autres cas ; ce sont des balises neutres vides de tout sens

Et d’aborder dans la foulée les microformats. Ça a été ma première surprise car je ne m’attendais pas à les retrouver dans ce livre. Un duo de page les aborde et montre (un peu trop succinctement) que microformater du contenu n’a rien d’impossible, surtout quand la structure XHTML est bonne dès le départ.

Processus

Transcender CSS s’intéresse à une approche industrielle du processus de création. Autrement dit : comment proposer efficacement une interface graphique à un client/décideur sans investir trop de temps. Nous savons tous qu’il y a toujours du changement, mineur mais surtout majeur, et qu’il est difficile de chambouler toute une feuille de style pour repositionner des éléments en conservant une cohérence.

C’est là que l’approche par la méthode de la boîte grise prend tout son sens. Elle définit à l’aide de boîtes grises l’agencement des contenus de la page. Une boîte, un contenu et le charme opère. Les classiques story-board s’en approchent.
Cette méthode peut se compléter à l’aide de symboles pour représenter des éléments annexes (textes, formulaires etc.) mais est surtout très facilement réalisable à partir d’un logiciel de présentation de type OpenOffice Impress ou Microsoft Powerpoint.

Une fois les bases de la structure mise en place, l’heure est venue de présenter une maquette statique. Autrement dit du HTML et des CSS. Les ajustements resteront possibles puisque la première partie du livre a expliqué comment mettre en œuvre une structure pérenne et libre de mise en forme.
Transcender CSS recommande fortement, et je suis on ne peut plus d’accord, d’utiliser de manière poussée les extensions indispensables de Firefox que sont Firebug et Web Developer.
J’y consacrerai un billet mais les éditeurs intégré modifiant à la volée votre page sont des outils précieux offrant des gains de développement mésestimés.

L’ouvrage poursuit sur des bonnes pratiques d’organisation de son code au sein même des feuilles de style. Des pratiques qui permettent de retrouver facilement ses petits sans avoir à chercher inutilement. Des pratiques qui suggèrent également de bien coder pour mieux réutiliser son travail dans d’autres projets. Si vous estimez votre travail, pourquoi le recommencer intégralement lors du projet suivant ?

Inspiration

Cette troisième partie a été mon deuxième choc pendant la lecture. C’est la partie dans laquelle j’ai le plus appris car elle explore des aspects finalement peu abordés dans les ouvrages liés aux CSS.

J’ai commencé à mieux percevoir l’intérêt et l’ingéniosité du rythme vertical grâce à la divine proportion. Qui aurait cru que les maths se cachaient aussi subtilement dans le design Web ? Certainement pas moi. Retenez bien le nombre 1,62 (φ) car c’est le nombre d’or qui régira avec majesté les designs CSS les plus réussis.
En français, il s’agit de la règle des tiers. Au lieu de choisir arbitrairement la taille des contenus, divisez les espaces en largeurs proportionnelles, elles-mêmes divisibles par 1,62 etc. La clarté en résultat est tout simplement saisissante.

Tout ceci nous amène à parler du design par grille. Vous venez de suivre le lien ? Vous aurez probablement remarqué, consciemment ou pas, que la page est découpée en 8 colonnes de largeur identiques. Certains contenus occupent davantage de place mais devinez-quoi ? Cela correspond toujours à un certain nombre de colonnes, pas une largeur hasardeuse.
Cette lubie n’est pas si excentrique que cela puisqu’elle nous provient directement des … journaux papiers. Qui aurait cru que le New York Times aurait pu inspirer les meilleurs designers du Web ? Et pourtant, on ne regardera plus les journaux de la même manière en observant leur structure à 6 ou 8 colonnes. Du nombre d’or en veux-tu en voilà.

Andy Clarke termine ce chapitre sur les sources d’inspirations. Là non plus il n’y a pas de frein à l’imagination puisque tout est susceptible de catalyser créativité : architectures d’immeubles, coupures de presse, publicités de magazines, affiches diverses et variées. Vous l’aurez compris, tous les supports visuels facilement agrégeables.

Transcendance

Cette partie termine en apothéose Transcender CSS. Nous savons intégrer, nous savons structurer et nous savons imaginer alors maintenant il va falloir sublimer. Au prix du livre, ça serait dommage que notre côté créatif n’aie pas pris du galon

Il n’y a d’ailleurs qu’un point sur lequel j’ai du mal à adhérer : cette adhésion au positionnement absolu/relatif et le dénigrement déguisé des flottants. Si les positionnements relatifs permettent de forcer le positionnement d’un bloc, c’est en revanche une solution beaucoup moins flexible dans la majorité des cas. Cette technique oblige, à mes yeux, de connaître les tailles des éléments à positionner. C’est parfois impossible, surtout si on veut pouvoir s’affranchir de largeurs fixes pour profiter de designs élastiques.
Je comprends néanmoins que c’est une pratique appréciable pour les designs en grilles.

De très nombreux cas pratiques abondent dans cette partie. Ces exemples stimulent l’imagination avec des mises en pages (et des variantes) convaincantes, attractives et on ne peut plus déclinables dans le monde réel. Réel ou presque puisqu’ils se basent sur des navigateurs valides uniquement.
C’est l’occasion d’aborder le génie de Dean Edwards avec IE7, la librairie Javascript ultime pour Internet Explorer. Cette librairie permet de mettre à niveau Internet Explorer 5 et Internet Explorer 6 au niveau d’Internet Explorer 7. Ce n’est certes pas la panacée mais ce n’est plus l’enfer truffé d’incertitude que l’on haït tant.

Transcender CSS conclut sur une quarantaine de pages avec les CSS 3 en mêlant exemples pratiques et des comparaisons entre CSS 2 et CSS 3. J’ai été ravi de voir en pratique l’affichage multi-colonnes sans jouer avec les flottants, l’habillage d’un bloc avec plusieurs bordures en images (sans balises superflues) et surtout l’Advanced Layout.
L’Advanced Layout est probablement l’avancée la plus attendue car elle permet de s’affranchir des positions absolues pour repositionner du contenu sur la page simplement. Et de retrouver les notions de grilles puisque des régions sont définies dans la feuille de style. Au designer de déplacer un contenu dans le flux sans le faire quitter.

Autant dire que les designs bâtis sur CSS 3 seront riches en créativité. Et ce n’est pas l’initiative Goto CSS3 qui dira le contraire

Conclusion

Cet ouvrage m’a énormément plu pour 2 raisons :

• j’ai failli croire que je n’allais rien apprendre
• le contenu est ouvert vers l’avenir

En effet plutôt que de nous dire quoi faire, Transcender CSS explique comment mieux faire. C’est véritablement appréciable car en lisant le livre on adapte son contenu à ses besoins. Ses pages sont généreusement émargées de conseils, d’astuces et de ressources qui enrichissent la perception de la conception du design Web. Je me suis d’ailleurs surpris à relire le livre mais uniquement ses marges de peur d’avoir raté un lien essentiel …

Vous le savez tout aussi bien que moi, le gros problème des ouvrages réside dans des cas pratiques difficilement réutilisables au quotidien. Transcender CSS a l’intelligence de proposer des recettes pour mieux aborder la conception des sites, des sources d’inspiration jusqu’aux secrets du découpage en grilles. Qui eût cru que la presse papier avait encore de belles leçons à donner au Web ?

Transcender CSS ne livre pas clé en mains des solutions mais vous aidera à y voir plus clair, à comprendre pour mieux réagir. En soi c’est ce que j’attends d’un livre à 30€. Une valeur sure.

Je vous livre ici les clés de ma réussite, a priori inédite puisqu’entièrement basée sur de la communication, de la présence et de l’image de marque. J’ai utilisé tous les outils à ma disposition pour me mettre en valeur. Et je peux vous dire qu’il y a des reconsidérations à faire sur des outils Internet soit disant inutiles

Anticiper et convertir sa propre démotivation

Période estimée : avril/mai 2007

Que ce soit en amour ou au travail, je commence à croire au fameux cycle des trois ans : un an pour s’adapter, un an pour performer, un an pour transformer. Cette dernière année est la plus marquante puisqu’elle déterminera le renouvellement du cycle.

Apprendre et améliorer font partie de mes leitmotiv liés au travail (et même en dehors d’ailleurs). J’avoue cependant que plus particulièrement depuis le début de cette troisième année, j’ai ressenti un fort besoin d’apprendre. Ce nouveau besoin est entré en conflit avec une certaine lassitude au travail et une envie de changer pour m’épanouir davantage.

Avant d’avoir envie de baisser les bras, j’ai converti ce raz-le-bol général en volonté de changer. J’ai donc décidé d’utiliser Internet pour me mettre en valeur : blog, réseaux sociaux, micro-blog et rencontre de personnes issues du milieu.

Définir ses cibles et ses objectifs

Période estimée : mai 2007

C’était donc décidé, j’allais changer de travail. Avant de me lancer tête baissée dans une simple recherche d’emploi, j’ai pris le temps de jeter un coup d’œil dans le rétroviseur, d’analyser mon parcours et ainsi deviner dans quelle direction je me rendais.

Etant développeur Web sensibilisé à bien des causes (logiciels libres, accessibilité, validité du code, sécurité, bonnes pratiques etc.), mon domaine de prédilection est Internet. Internet c’est bien mais c’est vaste alors quelles sont les composantes que j’aimerais retrouver ? Du développement bien sûr, être entouré de personnes meilleures que moi capables de m’aider à formaliser des connaissances et des lacunes, du conseil et de la formation.

Ce besoin dessine plusieurs structures d’entreprises susceptibles de me plaire et d’être intéressée par mon profil :

• l’agence Web : l’entreprise a priori idéale pour mes compétences ;
• la SSII : l’organisation la plus carrée mais pas forcément la plus cool ;
• la start-up : un rêve de gosse depuis l’apparition de la première bulle Internet

La problématique à résoudre : trouver les meilleures d’entre elles, montrer le meilleur de moi-même et croiser les doigts pour avoir eu de raison de placer la barre aussi haut.

Se créer une présence en ligne : CV, blog, veille et réseaux sociaux

Période estimée : juin à juillet 2007

L’avantage d’Internet, c’est la facilité avec laquelle circule l’information.
L’inconvénient d’Internet, c’est que l’information circule facilement donc forcément, beaucoup d’informations circulent. Difficile de s’y (faire) repérer à ce moment là.

Le CV est la pièce maîtresse qui doit résumer ma vie, mon expérience et mes aspirations. En lisant mon CV le recruteur doit comprendre d’où je viens, ce que je connais, ce que j’ai apporté et éventuellement ce vers quoi j’aimerais aller. Il est vraiment important de montrer que je ne se contente pas de mon job quotidien et que je comprends le recruteur en lui facilitant la lecture.
J’ai pour ma part essayé d’allier originalité et sobriété car si les paillettes et autres fanfreluches peuvent être tolérées, au final ça reste une question de goût et peut potentiellement causer du tort. C’est en refaisant mon CV que j’ai commencé à davantage m’intéresser aux microformats (avec hResume) et à la sémantique et de réaliser que l’interprétation des CSS de type print, c’est pas gagné.
Bilan des courses pour le CV : il est consultable en ligne, imprimable à souhait et plutôt complet à lire. Une formule gagnante vu qu’il a déjà inspiré au moins une personne.

Deuxième pièce maîtresse de ma présence en ligne : le blog. J’ai doucement réorienté celui-ci vers quelque chose de plus « pro » pour ne pas avoir honte que mon employeur tombe dessus, le lise et se fasse une meilleure idée de moi au quotidien, au travail et en dehors. Parce qu’une personne c’est davantage que ses qualités techniques, ce sont aussi ses capacités à créer une bonne ambiance au travail et à s’intégrer dans une équipe qui sont recherchées.
Pas étonnant que je retape l’esthétique du blog à la fin du mois de juillet, profitant de cette occasion pour apporter davantage de sérieux à son contenu, quitte à moins écrire.
Cette refonte a été l’occasion d’unifier ma communication en plaçant le blog comme étant une partie de mon CV, une partie de ma vie. Plus tard lors des entretiens il se trouve que plusieurs recruteurs étaient déjà tombés dessus par liens interposés, des commentaires sur d’autres blogs (d’où l’intérêt de commenter intelligemment) ou des recherches. Un point bonus puisqu’ils me connaissaient ainsi déjà avant que je les sollicite.

Dernier élément du triptyque : les réseaux sociaux. C’est à ce moment précis que j’ai trouvé une utilité réellement utile à Facebook. Ma présence sur LinkedIn était également devenue pertinente. Twitter a aussi connu un regain d’intérêt à mes yeux puisque j’ai pu suivre des personnes qui m’intéressaient et en apprendre davantage sur leur vie (infos à replacer lors d’un entretien, effet positif garanti).
Sur ces différents réseaux, dites-en un maximum sur vous sans tomber dans la naïveté mielleuse. C’est l’occasion de placer quelques détails plus communs sur vos goûts et centres d’intérêt qui n’auraient pas leur place sur votre CV.

Se créer une présence en ligne : nouer les contacts

Période estimée : juin à juillet 2007

Il y a deux moyens de nouer des contacts professionnels : en allant directement à leur rencontre et via Internet.
C’est à ce moment là que j’ai réalisé l’importance et la valeur qu’a un carnet d’adresses. Vos contacts deviendront peut-être (et je l’espère) des amis, des partenaires professionnels voire vos employeurs et quoiqu’il en soit, ils seront de bon conseil, pourront vous refiler leurs tuyaux et même vous introduire auprès d’autres personnes.

Pour aller à la rencontre de professionnels, l’avantage est aux grandes villes (Paris et Lyon notamment) car malheureusement il y aura peu de chance qu’une grosse agence ou qu’un gourou traîne au fond d’une vieille grange à la campagne (l’ADSL ne va pas si loin ). J’ai toujours pensé à emporter plusieurs CV avec moi (même si l’interlocuteur est déjà censé l’avoir). Je me suis déplacé pour discuter, exposer mes opinions, savoir comment leur travail était organisé et signaler que j’envisageais de changer de travail. Et s’ils ne recrutaient pas, c’était tout de même l’occasion ou jamais de glaner des informations : qui recrute, qui pourrait recruter et quelles sont les entreprises conseillées.

Ces contacts réels, je les ai inclus dans mon cercle de contacts en ligne. LinkedIn est un réseau social que j’estime beaucoup de par son côté qualitatif et professionnel. J’y ai moins de contacts mais je sais que je pourrai compter dessus. J’ai été agréablement surpris du nombre de Français inscrits sur ce site pourtant exclusivement consultable en anglais. Son homologue français est Viadeo mais je n’aime pas trop ce service car trop bordélique, moins bien fichu et surtout, de mauvais conseil : combien de fois ai-je reçu des mails automatique me conseillant de bosser dans la grande distribution alors que mon profil était orienté Internet ? Trop.

Facebook est LE réseau social qui grimpe, plus informel et moins « pro » mais où bon nombre de personnes sont inscrites. J’y ai repéré des amis que je connaissais, les contacts réels que j’avais ou que j’allais nouer et j’ai surtout scruté leur liste d’amis. Ca prend un peu de temps mais c’est très instructif, on découvre de nouvelles têtes et ça permet de sortir un peu des cercles de relations habituels.
Par contre évitez de céder à la tentation d’ajouter tout plein d’applications à trois sous (genre les Zombies etc.) et de spammer votre liste de contacts pour leur proposer d’adhérer à vos trouvailles. C’est pénible et ça pourrait se retourner à terme contre vous.

La recherche active d’emploi

Période estimée : août 2007

Ca y’est, je dispose d’une bonne dizaine de contacts et j’y vois plus clair dans vos objectifs. C’est le moment de commencer à démarcher activement. Toutefois mettons-nous d’accord sur une chose : démarcher ce n’est pas envoyer un CV par email et attendre une réponse ad vitam eternam. A l’heure d’Internet, sauf annonce mentionnant le contraire, oubliez le papier et passez par les emails. Vous gagnez du temps, courrez le risque du spam et économisez du papier.

Voici comment multiplier les contacts :

• publier des annonces de demande d’emploi (attention, selon les sites la qualité des contacts varie)
• démarcher les entreprises qui recrutent
• démarcher les entreprises qui vous intéressent

Systématiquement, une semaine après avoir envoyé mon email j’ai téléphoné pour prendre des nouvelles. Soyez malins en étant capable de donner la date exacte, votre adresse email d’expédition et l’objet du mail. Vos interlocuteurs trient le courrier donc ça leur facilitera la recherche tout en marquant des points sur votre organisation. Être fiable et rigoureux ça paie. Je n’ai donc pas hésité à demander de moi-même un entretien pour discuter de ma candidature : c’est plus facile d’en discuter de visu, d’afficher ma motivation et de convaincre le recruteur.

Si jamais on vous demande une lettre de motivation, surtout ne sortez pas de lettre bateau. Au contraire écrivez une lettre générique dont les parties sont modulables en fonction de l’entreprise : décrivez vos motivations, votre projet professionnel, les éléments marquants de votre parcours et ce qui vous pousse à candidater. Ne paraphrasez pas le CV, utilisez l’espace de la lettre de motivation pour écrire ce qui n’y figure pas faute de place. Vous aurez alors une lettre totalement personnalisée, adaptée à votre interlocuteur et qui vous multiplierez ainsi les chances d’attirer son attention.
Le recruteur doit sentir que vous apporterez à l’entreprise, peut-être même davantage que ce que celle-ci vous apportera. Le contrat doit être gagnant-gagnant.

Conclusion

Tout changement de travail oriente sa carrière. Pour choisir au mieux son orientation, il vaut mieux disposer d’un maximum d’entreprises intéressées par son profil, ne pas accepter la première offre venue et tout le temps réfléchir à ce que l’on veut, quitte à remettre en question ses objectifs de départ. Le tout est de ne pas regretter, de bien réfléchir et d’user de son instinct pour sentir l’entreprise qui nous conviendrait le mieux. Mieux vaut être moins bien payé et avoir un job plus intéressant que l’inverse.

Quoiqu’il en soit pendant ma recherche d’emploi j’ai toujours été très tenté de dire à mes collègues que je comptais partir, que je cherchais ailleurs. Cependant par précaution j’ai attendu le dernier moment, celui de la signature du contrat. Cela évite d’être démissionnaire aux yeux des collègues, surtout si au final je ne trouvais pas de nouvel employeur.
En contenant cette joie de changer, j’ai évité du même coup de trop me laisser aller et de trop croire que j’étais déjà parti.

J’ai passé plusieurs mois à peaufiner ma présence et j’ai signé mon contrat en moins d’un mois. En montrant que j’étais une personne déterminée, motivée et désireuse d’apprendre, j’ai pu convaincre. J’ai reconnu mes points faibles, présenté mes atouts et montré que je savais où j’allais.

Au final j’en retire une expérience enrichissante, de nouveaux contacts et surtout le plus important, un nouveau boulot qui me plaît déjà.

Lors de la refonte de ce blog, j’ai concocté un petit script JavaScript (non intrusif bien entendu) affichant et modifiant le contenu d’un bandeau sous la forme d’une classe statique reponsant sur jQuery. J’explique aujourd’hui comment ces 48 petits lignes de code (en comptant commentaires, sauts de lignes et accolades) fonctionnent, comment il est aisé de mettre en place de telles routines de manière intelligente, souple et non intrusive.

Et comme l’indique le slogan de jQuery : Write less, do more.

Le besoin

Avant de se lancer tête baissée dans le code, prenons le temps d’exprimer avec des mots ce que l’on aimerait faire.

On souhaite disposer d’une liste de liens. Lors d’un clic sur un lien de cette liste, l’encart correspondant doit s’afficher pour illustrer davantage son sens. Eventuellement, lorsque l’on reclique sur ce même lien, le visiteur est transporté sur la page en question.

J’ai grassé les mots importants de ce besoin. Vous le verrez par la suite, ils vont régir le comportement du script.

La structure HTML

Nous allons donc nous retrouver avec trois grosses parties dans le code :

• la liste de liens, une balise ul semble toute indiquée)
• une liste de textes correspondants, il n’a pas lieu d’être visible pour l’utilisateur final concerné par le code
• un bloc conteneur neutre destiné à recevoir les textes d’enrichissement de manière visuelle

Des mots au code, voici ce que donnerait la structure balisée :

<body>
<!-- (...) -->
	<div id="conteneur_cible"></div>
	<!-- (...) -->
	<ul id="liens_etendus">
		<li><a href="page1.html" class="page1">Page 1</a></li>
		<li><a href="page2.html" class="page2">Page 2</a></li>
		<li><a href="page3.html" class="page3">Page 3</a></li>
	</ul>
	<!-- (...) -->
	<div id="conteneur_source">
		<h2>Titre</h2>
		<p>Texte explicatif apportant de la cohérence aux utilisateurs dépourvus de JavaScript et d'interprétation des feuilles de style.</p>
		<ul>
			<li class="page1">Texte page 1</li>
			<li class="page2">Texte page 2</li>
			<li class="page3">Texte page 3</li>
		</ul>
	</div>
<!-- (...) -->
</body>

L’ordre de la structure importe peu mais dans tous les cas, leur position dans le flux HTML dépend avant tout de leur importance au sein de celui-ci. De manière générale, il vaut mieux disposer le contenu principal tout en haut du flux et le faire suivre par le contenu secondaire tels que les menus de navigation et les textes supplémentaires.
Je pense que le code parle de lui-même, posez vos questions en commentaires si jamais il y a besoin d’explications plus poussées.

Côté HTML tout est réglé avec ceci. Il ne restera éventuellement que du travail de stylage pour lui donner une apparence plus conviviale.
Vous remarquerez qu’il n’y a aucune mention à du JavaScript à l’intérieur de ce code et ce sera le cas jusqu’au bout. C’est tout l’intérêt de séparer fond et forme et donc, du JavaScript non intrusif.

Le code Javascript

J’ai pris la décision d’écrire ce code pour jQuery car cette bibliothèque (ou framework) est embarquée dans WordPress et réduit drastiquement la quantité de code à écrire pour produire des résultats.

Dans la pratique, le code va se charger dès que possible (c’est à dire dès que le DOM est prêt) et exécutera une méthode en se servant des paramètres prédéfinis ou passés manuellement à la classe. Le code suivant est structuré et suffisamment commenté pour le comprendre sans trop de difficulté. J’expliquerai en-dessous sa logique :

/*////////////////////////////////////////
// Classe statique 'oncletom_text_grabber'
// # Permet d'afficher un slide d'informations en cliquant sur un lien
// # C'est rigolo et en plus ça sert à quelque chose
// @ parametres (objet, optionnel) : objet de clé:valeur paramétrant le comportement
////////////////////////////////////////*/
function oncletom_text_grabber()
{
	var parametres = arguments.length == 1 && typeof arguments[0] == 'object' ? arguments[0] : {};
	//Paramétrage de la fonction
	//# permet un lancement de la classe avec un paramétrage par défaut
	parametres.source = typeof parametres.source == 'undefined' ? '#conteneur_source > ul > li' : parametres.source;
	parametres.bindto = typeof parametres.bindto == 'undefined' ? '#liens_etendus a' : parametres.bindto;
	parametres.target = typeof parametres.target == 'undefined' ? '#conteneur_cible' : parametres.target;
	/*////////////////////////////////////////
	// Méthode publique 'ot_text_caller'
	// # Récupère le contenu associé à l'attribut 'rel'
	// # Méthode à appeler sur un évènement
	////////////////////////////////////////*/
	function ot_text_caller()
	{
		//sélection de l'élément à récupérer
		var id = $(this).attr('class');
		//hop ! on vérifie c'est déjà ouvert. Auquel cas le lien redevient cliquable
		if( $( parametres.target ).attr('class') == id )
		{
			return true;
		}
		//on nettoie le contenu de la destination
		$( parametres.target ).empty();
		$( parametres.target ).attr({ 'class' : '' });
		//on remplit la destination avec le bon contenu
		//on le fait en utilisant une expression régulières pour récupérer l'élément voulu
		$( parametres.target ).fadeIn( 'slow' ).append(  $( parametres.source+"."+id ).html() ).toggleClass( id );
		//évite que le lien soit cliqué
		return false;
	}
	//On greffe les différentes méthodes
	$( parametres.bindto ).click( ot_text_caller );
}
//exécution automatique de fonctions au lancement du document
$( oncletom_text_grabber );
//FACULTATIF
//pour assigner une deuxième liste de liens, il suffirait d'écrire le code ci-contre, par exemple :
//tous les paramètres non renseignés prennent la valeur par défaut de la classe
$( function(){ oncletom_text_grabber({ 'target' : '#nouveau_conteneur_cible', 'bindto' : '#exemple_entete ol a[@rel]', 'source' : '#liste_source2' }); } );

1. Dans un premier temps, je m’applique toujours à pouvoir proposer une utilisation de la classe sans avoir à fournir de paramètre lors de son appel. C’est un côté pratique qui permet en plus de documenter les différentes options possibles. Ces options correspondent aux différents sélecteurs jQuery dont on aura besoin par la suite ;
2. Dans un deuxième temps, je déclare une méthode interne à la classe. La cascade des accolades fait qu’elle n’est accessible que depuis la classe. Cette méthode sera assignée à l’évènement onclick de tous les éléments concernés par parametre.bindto. En clair, des liens hypertextes. Le this y fait référence.
   1. On stocke dans la variable interne id le nom de la classe. En effet, la classe du lien permet de récupérer le bon texte dans el conteneur source (parametre.source),
   2. On vérifie que le conteneur cible ne porte pas le même nom de classe : si oui, on suit le lien, si non, on affiche d’abord le texte complémentaire (la suite),
   3. Le passage le plus délicat consiste à extraire ce qu’il faut et le placer où il faut. Heureusement jQuery dispose de deux fonctions magiques : append() et html(). La première rajoute du HTML à la suite du sélecteur tandis que la deuxième extrait le HTML par sélection. Le fonctionnement en chaîne de jQuery permet de réaliser tout ceci en une ligne,
   4. Pourquoi un return false; pour terminer ? Tout simplement pour éviter que le lien hypertexte contenu dans l’attribut href du lien soit suivi.
3. Dans un troisième temps, on assigne la méthode déclarée juste avant. A chaque clic de chaque élément, elle sera appelée et surtout, aura accès à tous les paramètres de la classe ;
4. Enfin, après avoir clôturé la classe, on l’exécute dès que le DOM est chargé.

Conclusion et résultat

Pour que ce code soit effectif, il faut bien évidemment l’insérer à même la page ou bien en appelant un script externe (cette méthode est recommandée justement pour dissocier fond et forme). Il faut aussi penser à inclure jQuery dans votre page sans quoi le compilateur JavaScript va tirer la tête.

Pour résumer, je résume la pensée des bonnes pratiques du JavaScript non intrusif, prouvant si besoin en était que JavaScript est loin d’être le Diable :

1. définir sa structure HTML
2. styler le HTML
3. ajouter le JavaScript en surcouche

Ainsi, on ne pénalise personne (y compris en cas d’erreur de programmation), on conserve un code lisible tout en facilitant sa réutilisation dans un autre document.