Bonjour, bienvenue pour l’épisode 4 !

Beaucoup de gens y compris des devs expérimentés ont des soucis de CSS. Il y a l’attitude défaitiste qui dit que vous n’y arriverez jamais, il y a l’attitude “pas mon problème” qui refile le bébé à quelqu’un d’autre, et il y a l’attitude snob qui méprise carrément le problème. … et bien sûr il y a l’attitude qui consiste à tester, à apprendre, et à livrer de la valeur à ses utilisateurs et ses clients :)

OK, c’est dur

C’est vrai que ce n’est pas simple. De manière générale, HTML et CSS c’est dur.

Il y a eu des tas de normes qui s’empilent les unes sur les autres, mais le vrai souci était la variété des navigateurs qui ne gèraient pas tout pareil.

Ça va un peu mieux et ça va me permettre de ne pas vous parler des astuces IE6, difficiles à contourner mais qu’on connaissait bien, ou IE7, un peu mieux a priori mais que finalement on connaissait moins.

Pourquoi c’est dur ?

L’intention est louable : on veut séparer la forme et le fond.

Vous avez un contenu HTML, que j’aime visualiser comme des boîtes dans des boîtes dans des boîtes… etc.

On souhaite garder les informations d’affichage à côté pour pouvoir changer de design sans changer le code, et vice-versa.

On veut alors ajouter des informations sur ce que représentent ces boîtes, essentiellement son tag, sa classe, et son identifiant.

À partir de tout cela, vous faites un autre fichier, une CSS pour Cascading Style Sheets, Feuille de Style qui s’appliquent en Cascade (pour une fois qu’on a un nom explicite !) qui contient une liste de règles, des directives CSS.

Elles sont toutes à prendre en compte, mais pas aussi séquentiellement que du code où il y a un ordre précis, mais plutôt “toutes ensembles”.

C’est comme si tout le monde venait parler en même temps dans une conversation !

Du coup la moindre règle modifie les autres, ce que l’on appelle des “effets de bord”, et c’est exactement ce qu’on essaie d’éviter de faire quand on code.

Comment faire du sens dans ce bruit ?

Dans la vraie vie, quand vous avez des gens qui parlent ensemble, quand vous avez plusieurs consignes au travail qui semblent en conflit, vous rangez aussi par priorités.

Imaginez : on vous dit un jour de traiter tous les dossiers d’une certaine manière, mais s’ils sont bleus d’une autre. On vous dit que si un dossier traîne depuis trop longtemps, il est prioritaire. Que si le client est VIP, c’est prioritaire. Que si le patron le veut de suite, c’est ultra prioritaire.

Qu’est-ce que vous faites ? Comme tout le monde : quand tout est prioritaire, rien n’est prioritaire, et vous tentez de retrouver un ordre décent dans tout cela.

(D’ailleurs petite parenthèse : c’est pour cela que je refuse d’utiliser la directive CSS !important et que je ne la recommande pas.)

On s’arrête, on réfléchit, et on décide qu’on traitera le dossier du patron en premier, puis les VIP, puis les anciens, puis les dossiers normaux, qui passent en bas de la pile.

La règle de priorisation CSS marche pareil : qui le dit, quand est-ce qu’on le dit, mais surtout à propos de quoi on le dit.

Qui parle quand ?

Certaines pages Web n’ont pas d’information CSS. Elles sont très rares, mais il y a bien une information qui existe :

• quand vous écrivez une page HTML pure avec des titres H1 et H2, ils sont grands et en gras
• quand vous mettez une liste OL ou UL, ses éléments sont en retrait et avec un chiffre ou une puce
• quand vous utilisez une balise P pour paragraphe, il y a un espace vide autour (padding)
• les liens non visités sont bleus, les visités sont violets

On voit qu’il existe une CSS par défaut du navigateur, mais c’est la moins importante de toutes.

Ensuite, vous pouvez utiliser des CSS que vous importez via @import, link, ou dans le header, ou en ouvrant des balises

Enfin, vous pouvez utiliser le style “inline” (écrit directement dans le HTML sur l’attribut style de l’élément, mais ce n’est vraiment pas propre) : c’est le dernier à parler, il est exactement là où vous voulez l’appliquer, on considère que c’est celui qui écrase tout le reste et qui aura raison au final.

Qui parle de quoi ?

On a cinq manière d’identifier des éléments HTML, cinq sélecteurs disponibles dans nos règles CSS :

• l’élément, ou le tag, c’est le type de boîte HTML (DIV par exemple)
• la classe, précédée par un point, quelque chose que vous pouvez ajouter pour noter la similarité entre plusieurs éléments (sur mes dossiers, la couleur rouge ou bleu, écrit au marqueur ou au stylo, le fait que ce soit un client VIP…)

• l’identifiant, précédé par un dièse, quand le dossier est nommé (le cas de Mr Tartempion)

• des pseudo-sélecteurs, avec des symboles “deux points”
• et des sélecteurs par attributs (avec des crochets) depuis CSS3

Si vous utilisez ces deux derniers vous savez un peu comment ça marche, alors je vais me concentrer sur les bases : élément, classe, identifiant. En plus, on peut les enchaîner : tous les dossiers bleus à condition qu’ils soient dans une armoire, voire expressément les dossiers bleus dans une armoire bleue.

L’élément vaut un point : UL LI A vaut alors trois points. Une classe vaut dix points : UL.menu ou .menu LI valent onze points. L’identifiant vaut cent points.

On donne ainsi une “prime à la précision” : plus le sélecteur est précis, plus votre règle monte en priorité, et plus c’est elle qui aura raison.

Qui dit quoi ?

Enfin, on sait de quoi vous parler, mais il faut savoir quoi faire dessus. Vous listez des propriétés CSS que vous voulez appliquer.

Certaines s’appliqueront à tous ses enfants (toutes les boîtes dans cette boîte), d’autres non. Et tout finit par s’appliquer en même temps ! Dans la vraie vie, un humain l’oublierait probablement, mais pas un ordinateur : si une règle très peu prioritaire dit d’écrire en vert et toutes les règles plus prioritaires ne changent que la taille et les bordures de l’élément, le texte est toujours vert.

Si vous voulez changer cela, vous allez réécrire cette propriété plus tard, prendre la précédence sur ce qui a été dit avant.

On dit que le droit est le métier des exceptions, mais le développement aussi : je vous demande de faire un certain traitement, sauf dans tel cas, mais sauf dans tel cas encore plus précis, auquel cas on réécrit encore par dessus les deux règles moins importantes.

Boni

On vient de voir que c’est un sujet complexe. Il y a de plus en plus d’outils pour vous aider, c’est bien, et de pratiques à apprendre, ce qui peut porter à confusion et ajoute à la complexité ambiante. Je voulais garder l’épisode “low-tech” pour ne perdre personne et parce que je crois qu’il y a de la valeur dans les bases et l’historique.

J’avais parlé d’un épisode philosophique, l’écriture n’est pas venue aussi naturellement que je pensais, je le garde au chaud pour plus tard. De même j’hésite à faire des épisodes business, ce qui sort clairement de la ligne annoncée mais qui a également beaucoup de valeur.

De plus, à mon sens, on ne peut se contenter de faire son job, il y a toujours de vastes considérations à prendre en compte autour de votre périmètre précis, que ce soit pour progresser, pour maximiser les opportunités, ou pour deviner ce qui va vous tomber dessus et anticiper un peu.

Bref, n’hésitez pas, je suis ouvert aux commentaires sur Twitter @zen_m4 :)

Merci et à bientôt !