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 !
Autant vous annoncer la mauvaise nouvelle tout de suite, il n'est pas possible d'utiliser les Media Queries dans l'attribut des balises HTML style. Ainsi le code suivant ne fonctionnera pas...
<div>
<img
src="image/que/je/veux/decaller/seulement/quand/elle/flotte.png"
style="@media(min-width: 768px){float:left margin:-4px 16px 8px -24px;}">
<p>J'aimerai faire flotter à gauche l'image ci-dessus uniquement sur
les grands écrans. Comme les valeurs de `margin` sont ajustées uniquement
aux propriétés de cette image (-4px 16px 8px -24px), il n'existe pas de
classe HTML-driven comme créer un `.float-left` (à l'avance) qui répondrait
exactement à mon besoin.</p>
</div>
...c'est comme ça !
Dans ce cas, comment faire pour gérer des propriétés CSS ponctuellement en utilisant les Media Queries ? Cela est très utile pour le remplissage de contenu pour ajuster des images ou encore manager des background-image.
La solution n'est pas l'attribut style des balises HTML mais la balise <style> elle même !
J'ai déjà abordé le sujet des Frameworks CSS qui surchargeaient le DOM HTML inutilement et allait à l'encontre de la philosophie du W3C (séparation du fond et de la forme) dans un précédent article où j'expliquais pourquoi, par exemple, Bootstrap est une régression pour un développement Front-end de qualité.
J'ai également expliqué comment reproduire l'équivalent de fonctionnalités utiles dans un Framework en respectant l'approche CSS-driven dans Grille CSS Responsive et Sémantique sans Framework.
Je vais ici vous démontrer que cette méthode CSS-driven peut non seulement être grandement simplifiée avec l'utilisation des préprocesseurs CSS comme Less, Sass ou Stylus, mais qu'elle permet également d'exploiter les Frameworks tel que Bootstrap de manière propre et conforme à la philosophie de séparation de la sémantique et du design.
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 !
Une solution rapide et qui fonctionne sur tous les navigateurs à partir de IE9 est le centrage vertical avec la valeur CSS3 translateY de la propriété transform.
Pour mettre cela en place, trois simples propriétés :
On place l'élément en relatif pour le repositionner par rapport à son élément parent avec position: relative;.
On déplace l'élément de la moitié de la hauteur de l'élément parent avec top: 50%;, la référence de déplacement étant actuellement son bord haut.
On re-centre l'élément non plus à partir de son bord haut mais de son centre vertical avec transform: translateY(-50%);
Et voilà !
Depuis que le Responsive Web Design a commencé son invasion, beaucoup de site ne possède plus qu'une unique version qui gère :
Cela revient souvent à inhiber des fonctionnements jugés peu utiles par les développeurs ou ergonomiquement trop instables pour être présentés sur les petits appareils et empêche alors :
Je vous propose, à travers des exemples CSS-Driven, de vous expliquer comment gérer deux versions d'affichage de vos pages avec comme toujours une seule structure HTML sémantique.
Il y a quelque temps, j'expliquais qu'il était difficile d'obtenir un travail Front-end de qualité avec des Frameworks CSS HTML-Driven. Le gros reproche que je fais à ces Frameworks est de prendre le contre pied de l'approche du W3C qui met tout en œuvre avec HTML5 et CSS3 pour complètement effacer toute trace de design dans l'architecture HTML et la rendre structurellement sémantique.
Un Framework CSS c'est vraiment pratique pour ne pas trop se mouiller et gagner du temps parait-il. On me dit d'ailleurs souvent que les systèmes de Grid c'est bien pratique. Ce que j'en pense pour ma part c'est qu'on ne peut jamais sortir des chemins battu d'un Framework lourd à moins de parfaitement connaître les mécanismes de celui-ci pour le contrer. Et dès lors qu'on est assez aguerrit pour comprendre des mécanismes menant à des « abstractions qui fuient », on est alors assez aguerrit pour s'en passer.
Sachez que l'on peut facilement se passer de Framework pour gérer une grille Responsive Web Design propre et maintenable en évitant ainsi d'horribles codes comme <div class="header col-xs-12 col-sm-6 col-sm-push-6 text-right-sm bg-info"> tout en restant maître de ce que l'on fait. Cette page CodePen en est un exemple.
Suivez-moi, je vais vous montrer !
Pourquoi je n'utilise pas Bootstrap ? Cela peut sembler une « évolution » de nos méthodes de travail front-end, mais gare au loup et attention de ne pas tomber dans un travers que le W3C tente d'enrayer au fur et à mesure des évolutions HTML et CSS.
Commençons par le commencement. Qu'est-ce que Bootstrap ? Comme pleins d'autres « Bibliothèque » ou « Framework » CSS dans la même veine, Bootstrap est un outil permettant d'augmenter la productivité des développeurs front-end le maîtrisant, dans le but de fournir le plus rapidement possible un rendu visuel ergonomique et si possible responsive.
Mon problème ne vient pas tant de sa finalité qui est louable, mais bel et bien de la mise en œuvre technique qui permet d'atteindre cette finalité. Pour être concis avant de développer : l'utilisation faites de Bootstrap est une régression pour un travail front-end de qualité.
Je ne compte persuader personne, et à défaut de convaincre, je vais au moins vous expliquer mon point de vue.
J'ai évoqué pourquoi je n'utilisais pas Bootstrap. Cependant, l'un des pré-requis pour un nouveau projet est de l'utilisé aussi j'ai retroussé mes manches pour approfondir la philosophie et j'ai déjà commencé à me casser les dents !
Aligner un texte à gauche sur version mobile puis à droite sur version desktop est chose aisé en CSS avec les Media Queries. Gérer le fait que deux colonnes côte à côte sur version desktop passe l'une sous l'autre sur version mobile l'est également avec Bootstrap. Pourtant aligner un texte à gauche sur version mobile puis à droite sur version desktop aussi facilement que la gestion des colonnes n'est pas possible...
Je vais vous présenter un petit pan de code remédiant à cela.
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.
Le « Responsive Web Design » comme son nom l’indique est le concept de « Responsive Design » adapté au Web. Il est parfois raccourci par le terme « RWD » ou simplement par « Responsive ».
Dans la majorité des cas d’utilisations, il est utilisé comme raccourci pour désigner la version Mobile d’un site web originalement conçu pour un écran d’ordinateur.
La vérité est que le Responsive Web Design n’est qu’un des nombreux concepts appliqués à un site web pour le rendre « utilisable agréablement » sur mobile tout en sachant qu’il ne se limite pas qu’aux mobiles et qu’il vaut tout aussi bien pour :
En plus du fait que Responsive Web Design ne signifie donc pas obligatoirement « version mobile », il est le porte étendard d’une liste de concept comme l’« Adaptative Web Design ». Difficile de comprendre ce dont on parle réellement quand il est question de Responsive Web Design.
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.
En CSS, tout comme avec le librairie JavaScript jQuery, il faut utiliser des sélecteurs pour cibler une balise ou un ensemble de balise :
En combinant les deux sélecteurs précédent on peut sélectionner une balise par son attribut id et son attribut class.
On peut donc cibler la balise HTML suivante :
<div id="main" class="example"></div>
avec le sélecteur CSS suivant :
div#main.example { /* ... */ }
Lire dans une autre langue