Il restait la solution du bon vieux innerHTML, non standard mais qui marche très bien et est très rapide. Mais ça ne convenait pas vraiment si je voulait insérer mon bout de code après un élément précis, ajouter des événements sur une portion précise de ce code etc.

Donc je me suis fait une petite méthode String.toDOM() qui permet de convertir une chaine de caractère en noeuds DOM.

Ce n’est encore que des documents de travail alors il manque sûrement plein de choses et il y en a sans doutes d’autres qui ne sont pas très claires, n’hésitez pas à me le signaler.

• Conventions de codage (x)HTML
• Conventions de codage CSS

C’est déjà la 3ème édition et c’est toujours du bonheur : des conférences toutes plus intéressantes les unes que les autres, des rencontres avec des gens super intéressants et bien sûr une superbe ambiance.

Évidement je ne rentre dans aucun groupe (ça serait trop facile), je pense que je me situe à peu prêt entre le pragmatique et le ninja⁽¹⁾, avec un petit côté libriste aussi.

• Os : Windows XP⁽²⁾ / Ubuntu
• Éditeur : Aptana
• Langages favoris : PHP, xHTML, CSS, Javascript⁽³⁾
• VCS : Subversion⁽⁴⁾
• Navigateur : Firefox

Et vous ?

1. Vive les claviers ergonomiques ! Et faudrai que je trouve le temps de me mettre à Dvorak
2. Et oui, je reste un joueur malgré tout.
3. Je suis dev font-end, ça se voit tant que ça ?
4. Intéressé par Git, mais ça manque encore de client desktop potable.

Par là je veux dire assigner à vos éléments une class qui désigne leur rôle et non pas leur apparence. Le rôle du CSS est de séparer le contenu de la présentation, si vous insérez dans votre contenu des class décrivant la présentation des éléments alors vous perdez le principal avantage des CSS !

Exemple, j’ai un message d’erreur (un texte en rouge) à afficher dans ma page, je lui met donc une classe .red :

.red { color:red; }

Ça marche, c'est génial. Tout se passe bien, jusqu'au jour où le client veut que le message s'affiche plutôt en orange ! Vous vous retrouvez alors avec :

.red { color:orange; }

La logique de votre code vient d'en prendre un coup. Vous pouvez aussi renommer en .orange toutes les class .rouge dans vos templates, quel temps perdu tout ça pour une couleur qui change... Alors qu'avec une simple class .error mon code serait resté logique et flexible malgré les éventuelles modifications futur.

Donc non, n'utilisez jamais de class qui décrivent l'apparence de vos éléments, même si vous vous dîtes que le style de votre élément ne changera jamais, vous pourriez être surpris !

Jamais ?

Ok, il peux y avoir des exceptions dans des cas précis.

En particulier si la personne qui doit manipuler ces class n'a pas un profil technique. Le cas que je rencontre régulièrement c'est le client qui veut aligner une image à droite dans une page, mettre un texte en bleu, etc. (et qui n'a pas accès à un outils WYSIWYG). Dans ce cas là vous pouvez lui définir quelques class utilitaires avec des noms assez explicite (parce que lui pensera apparence et pas rôle) pour qu'il puisse utiliser dans ses créations. Il y a sans doute d'autres cas particuliers où on pourrait être amené à utiliser ce genre de noms de class, si vous avez des exemples...

Google Developer Day

Comme à son habitude Google avait mis mes petits plats dans les grands avec un superbe cadre à l’ENSA (salle de jeu, coin repos, buffets, …) et bien sûr les conférences et ateliers.

Mais j’ai plutôt été déçu des ateliers, en particulier celui sur Open Social (1h présentation, 1h « démerdez-vous» ). Tandis que celui sur Android nous a gavé de code avant de nous montrer le résultat final (amha un décorticage pas-à-pas de l’application aurait été plus efficace).

Bref, je suis un peu resté sur ma faim. Dans mes souvenirs, l’édition de l’année dernière avait été beaucoup plus intéressante.

Mozilla Add-Ons Workshop

Le samedi, le MAOW avait lieu dans un lieu moins tape à l’oeil, à savoir La Cantine, mais que j’ai néanmoins trouvé beaucoup plus chaleureux. De plus, les présentations étaient vraiment intéressantes !

Pour commencé j’ai assisté à l’atelier « Votre première extension»  présenté par Paul Rouget (c’est toujours aussi impressionnant à quel point il maitrise son sujet).

Puis on a eu le droit à « Javascript pour adultes»  avec pas mal d’infos sur les nouvelles capacités présentes dans les dernières versions de javascript et une présentation de ce que sont les closures. Vraiment très intéressant, mais oubliez les nouveautés de javascript 1.7 / 1.8 si vous voulez faire autre chose que des add-ons, ça n’est pas présent dans IE (étonnant non ?)

Ensuite nous avons eu le retour d’expérience du développeur d’Adblock plus : qu’es ce qui fait qu’une extension devient populaire, comment gérer son évolution et sa communauté, etc. Là, j’avoue que j’ai faillit m’endormir (désolé).

Enfin on nous a présenté FUEL, la bibliothèque javascript intégrée à Firefox 3 qui permet de simplifier le développement d’extension aux développeurs.

Bref, en conclusion, j’ai trouvé la journée de Mozilla beaucoup plus intéressante que celle de Google (en plus le t-shirt du MAOW est plus joli ) et ça m’a plus donné envi de me (re)plonger dans les techo de Mozilla que dans celles de Google (maintenant il faut que je trouve la motivation et le temps).

En attendant, comme d’habitude, vous pouvez retrouver mes quelques photos des 2 événements sur mon compte flickr.

Je ne vais pas vous décrire en détails les fonctionnalités (des milliers d’autres blogs vont s’en charger, ne vous inquiétez pas), mais plutôt me concentrer sur ce qui nous intéresse nous les développeurs, à savoir les performances javascript, les spécificités du navigateur et les outils de développement fournis.