Cet article fait office de conventions d'architecture d'un site web orienté composant pour la partie cliente, peu importe la technologie d'implémentation finale, de manière à ce que le code soit valide, performant et maintenable par des développeurs front-end, des développeurs back-end ainsi que des pousseurs de contenu. Ces techniques étant en constantes évolution, et les problématiques évoluant au fur et à mesure de mes itérations créatives, cet article est voué à se compléter et changer.
Je viens de (re)terminer la lecture du Guide CSS Fr et j'ai eu envie d'apporter quelques modifications et ajouts à ces très bons conseils. Cet article va donc en quelque sorte constituer mes conventions en matière de création et maintenance HTML et CSS. Elles sont donc identiques à ce qui est écrit sur Guide CSS Fr à cet article prêt !
N'ayant rien à ajouter aux parties autres que « 4. Convention de nommage », je passe directement à mes propres conventions de nommage en vous sensibilisant à l'anatomie d'une page HTML.
Je finirai néanmoins par pointer du doigt une erreur, sinon la seule, en ce qui concerne la totale inutilité du préfixe .js- destiné à séparer le visuel du fonctionnel.
Note : Tous les exemples d'inclusion de fragment HTML sont tirés du framework Node.js NodeAtlas mais c'est juste à titre illustratif, c'est la même chose avec vos frameworks préférés.
Je l'ai encore croisée au détour d'un code ! J'y ai prêté attention pour la première fois sur le Framework CSS Semantic-UI car j'ai vu dans la source qu'il était impossible d'afficher une icône avec ce Framework sans utiliser la balise qui n'existe pas : la balise Icon !
Je vous la présente sans plus de suspense avec cet exemple : <i class="icon settings"></i>. Son rendu est une icône, représentant par exemple ici de quoi modifier les paramètres. Il n'y a pas de doute, l'intention première est d'afficher une icône, non pas avec la balise <img> estimée réservée à de l'affichage de contenu pure (au contraire d'une décoration), mais en remplacement de <span> qui, lui, est trop neutre.
Quoi de mieux qu'une balise qui est inline, courte, dont la seule lettre représente le début du mot « icon » et qui passe même la validation W3C ? Je vous présente la balise <i> qui a vu le jour grâce à HTML4 et signifiait « le contenu affiché est italique » et qui tenterait de faire son coming-back en tant que nouvelle icône derrière le dos du W3C !
Mais ça me pause un problème. Parlons en de cette fausse-vrai balise !
Voilà les petites bases qu'il faut rapidement se mettre en tête à propos de la différence entre les marges externes ou margins et marges internes ou paddings :
Les margins d'un élément HTML se superposent avec les margins de leur voisin, avec les margins de leur parents, avec les margins des enfants des voisins, etc. Puisqu'elles se trouvent à l'extérieur des borders, elles ne sont pas affectées par les backgrounds.
Les paddings d'un élément HTML s'additionnent ou se cumulent avec les paddings de leur voisins, avec les paddings de leur parents, avec les paddings des enfants des voisins etc. Puisqu'elles se trouvent à l'intérieur de border, elles sont affectées par les backgrounds.
Deux trois autres chose rapide sont à savoir : comme le fait qu'un élément inline ne gère pas les paddings ou qu'un margin négatif déplace les éléments contrairement au padding négatif qui ne fait rien, etc.
Mais saviez-vous que : Si les éléments deviennent flottants en continuant de prendre toute la largeur... les marges externes se comportent comme les marges internes !
Il y a des solutions simples pour gérer avec une feuille CSS l'affichage de différentes langues. Vous vous êtes peut-être déjà confronté à un problème similaire : votre super menu s'affichant en ligne est parfait dans la langue des Vulcains avec une taille de caractère mais malheureusement ne l'ai plus avec la langue des Na'vis.
Quand votre site sera déployé pour des localisations différentes, les feuilles CSS ne pourront alors pas être les mêmes et vous allez maintenir autant de fichiers différents que de localisation ? C'est ce que vous ferriez en faisant un très mauvais choix. Arrêtons-nous 5 minutes pour explorer une piste bien pratique pour assurer la maintenance d'une feuille CSS et de ces différentes localisations.
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 (Sectionneur de contenu) 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 (Titre en HTML) 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.
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 :
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.
Lire dans une autre langue