Articles de la catégorie Bonnes pratiques
Les bonnes pratiques JavaScript selon Google
Cet article est une adaptation du Google JavaScript Style Guide en FR. Je n'applique pas nécessairement moi-même toutes les bonnes pratiques listées ci-dessous mais si vous ne vous êtes jamais posé la question : « Comment maintenir un code gardant l'équilibre entre lisibilité et performance avec mon équipe ou les personnes susceptibles de relire mon code » cet article peut s'avérer intéressant. Si vous avez déjà vos pratiques : c'est peut-être l'occasion (comme pour moi) d'en revoir certaines.
Les balises h1 multiples autorisées en HTML5
C'est suite à plusieurs conversations m'invitant à ne pas utiliser de multiples balises h1 dans mes intégrations HTML (et plus récemment une demande « insistante » sur le fait de ne pas le faire) que je me vois forcé de marcher sur les pas de Raphaël Goetter -qui avait déjà abordé le sujet- pour expliquer pourquoi : en plus d'être tout à fait valide, cette pratique est bénéfique.
Tout document HTML5 dispose de cloison de contenu (sectioning content) que sont article, aside, nav et section. Ces zones de contenu peuvent chacune contenir une balise header et footer (ne cloisonnant pas elles-mêmes le contenu) et de multiple éléments de titrage (heading) allant de h1 à h6.
Bien que l'utilisation de plus d'une balise h1 ai pu rationnellement laisser à débattre (même si techniquement les standards ne l'interdise pas), les recommandations et même l'interdiction d'une telle pratique ne sont plus pertinentes et rationnelles à l'heure du HTML5.
Problème de z-index et priorité d'affichage
Je rencontre souvent des personnes se plaignant de problèmes de z-index et qui les évitent ou se contente de dire que les z-index ça pose problème. Bien souvent le problème vient du fait que le développeur ne s'attend pas à ce que la priorité d'affichage des z-index fonctionnent en cascade dans le DOM. Voyez plutôt l'exemple suivant :
Classes, héritage, encapsulation vs Prototype en JS
Posons le décors, le JavaScript ne possède nativement : ni classe, ni héritage, ni encapsulation... et alors ? C'est probablement le langage le plus incompris, car je vous assure que JavaScript est un puissant langage orienté objet et qu'il permet :
- la création de nouveaux contextes d'exécution autonomes instanciés (new) avec un constructeur, des propriétés et des méthodes personnelles internes (this...) à partir d'un gabarit de construction (classe),
- de dupliquer les propriétés/méthodes dans un autre gabarit (héritage) pour ajouter ou modifier des comportements (polymorphisme) le tout depuis différents endroits dans le code (partielle et virtuelle),
- de limiter l'accès aux propriétés/méthodes au contexte d'exécution (encapsulation privée) ou les promouvoirs (encapsulation publique)...
avec effectivement d'autres mots clés et mécanismes que ceux dont vous avez l'habitude, et nottament grâce au Prototypage.
En ce qui concerne ceux qui ont déjà un bon pied dans le JavaScript, même si jusqu'à présent vous n'avez jamais réellement vu l'intérêt de créer des structures avancées (l'équivalent de classes) pour un développement côté client, il est indéniable que côté serveur (en Node.js par exemple) cela est nécessaire. Et si vous êtes plus d'un développeur Front-end sur vos sites : ça s'avère nécessaire également. Bien qu'en utilisant des bibliothèques JavaScript comme Prototype ou Mootools vous puissiez assez facilement créer des classes, je vais vous apprendre ici à comprendre la roue, vous en créer une sans l'utilisation du prototypage très simplement et cerise sur le gâteau : de jouer avec vos classes en les remplissant/appelant de la même manière qu'en jQuery !
Pour finir nous verrons en quoi le prototypage peut vous simplifier la vie et en quoi donc JavaScript n'a finalement besoin d'aucune classe, d'aucun héritage et d'aucune encapsulation.
Une Callback pour vos fonctions JS asynchrones
Vous est-il arrivé d'utiliser une fonction JavaScript en maudissant son concepteur parce qu'il avait oublié un détail important... vous permettre de faire quelque chose après l'exécution de son code ! Ça m'arrive trop souvent ces derniers temps et ça ne serait pas non plus la fin du monde si les concepteurs n'avaient pas en plus eu la bonne idée de ne fournir que la version minifiée de leur développement ! Merci pour le partage « Dude » ;)
Je vais vous raconter une histoire.
Faire des bordures en image sans la balise Table
Beaucoup de design demande que les bordures des cadres de contenu soient des images pour avoir des bords aux motifs complexes ou faire des effets d'ombre. Bien qu'il existe des propriétés CSS3 qui gèrent cela à présent, la compatibilité sur tous les navigateurs ne sera possible que si ceci est réalisé avec du CSS standard et du HTML.