Principes à connaître pour améliorer vos feuilles de styles

Par Hugo Giraudel

Cet article passe en revue quelques principes de base et astuces tirés de mon expérience personnelle pour apprendre à devenir meilleur en CSS. Dans cet article, je vais parler avant tout de ma propre expérience et de ce que j’ai appris sur CSS pendant près d’un an et demi de pratique intensive.

Tout d’abord, laissez-moi vous rappeler que CSS est un langage extrêmement simple. Il peut se résumer en 3 mots : sélecteur, propriété, valeur. Et c’est à peu près tout. C’est pourquoi certaines personnes n’aiment pas du tout CSS car elles ont l’impression d’être comme des enfants qui jouent aux Legos.

En effet, il suffit d’expliquer les bases de CSS à un enfant de 9 ans pour qu’il ou elle soit en mesure de créer un site web. Pas un site compliqué bien entendu, mais peut-être quelques pages avec des titres, des liens, du contenu, des images, quelque chose dans ce goût-là.

Toutefois, le fait que CSS soit un langage simple ne veut pas dire que tout le monde soit au même niveau. Certaines personnes utilisent CSS comme un chimpanzé se sert d’une fourchette, certaines personnes se débrouillent pas mal avec et d’autres peuvent faire des choses formidables.

De ce que je peux en dire, je m’amuse avec CSS depuis près de deux ans maintenant et je pratique à un niveau disons « intensif » depuis près de sept mois. Je suis encore loin de la perfection et il y a toujours des astuces que je ne connais pas ou que je ne comprends pas.

Quoi qu’il en soit, voici quelques trucs que j’ai compris au cours des mois écoulés et que j’aimerais partager avec vous. Encore une fois ce ne sont pas des bouts de code ou des astuces utiles, ce sont plutôt des principes généraux et des bonnes pratiques. Voici ce que je vais aborder :

  1. Ne pas se ruer sur le code et faire simple
  2. Apprendre les bases et quelques astuces
  3. Ne pas se répéter
  4. CSS orienté objet
  5. CSS3 : apprendre ce que l’on peut faire et ce que l’on peut utiliser
  6. Amélioration progressive et dégradation élégante
  7. Les préprocesseurs CSS
  8. Garder un œil sur l’avenir
  9. Lire le code des autres
  10. Pratiquer sans relâche

Qu’en dites-vous ? Vous êtes prêts ? Allez, c’est parti.

1. Ne vous ruez pas sur le code et faites au plus simple

Ne vous ruez pas sur le code

C’est plutôt un conseil général, qui n’est pas spécifique à CSS. Quand vous êtes sur le point de commencer à développer, réfléchissez d’abord à ce que vous allez faire. Posez-vous quelques questions :

Commencer à coder sans réfléchir peut vous faire perdre du temps. Imaginez-vous passer une heure à créer quelque chose pour vous apercevoir que c’est sans issue et que vous devez tout recommencer depuis le début ? C’est hors de question.

Passer des heures sur un diaporama en CSS pour finir avec SlidesJS ou Adaptor, c’est vraiment nul. Non pas parce que vous avez échoué, mais parce que c’était une perte de temps. Vous pourriez le payer très cher, le jour où vous serez soumis à des délais très serrés.

Faites simple

CSS est un langage simple mais les choses peuvent facilement devenir complexes. Surtout si vous voulez qu’elles le deviennent. Dans la plupart des cas, l’idée la plus simple est souvent la meilleure. Quand vous devez réaliser quelque chose, demandez-vous toujours s’il n’y a pas un moyen plus simple de le faire. Vous seriez surpris du nombre de fois où la réponse est « oui ».

Par exemple, si vous voulez coder une barre de navigation horizontale vraiment simple qui ne comporte que des liens, vous avez plusieurs façons de faire :

Choisissez le plus simple et transformez les éléments de liste en éléments en ligne. Pas besoin de hack pour nettoyer les flottants. Pas besoin de corriger l’espacement des éléments en ligne. Il y a juste besoin d’un espacement interne classique, rien de plus. Fin de chantier.

2. Connaître les bases et apprendre les astuces

Pour devenir bon en CSS ou quoi que ce soit d’autre dans la vie, vous devez connaître les bases. Vous ne deviendrez jamais un expert si vous n’êtes pas à l’aise avec les bases de la discipline.

Les bases de CSS

Quelles sont les bases de CSS ? Selon les personnes, vous aurez droit à différentes versions, c’est plus de l’ordre du ressenti, mais si vous voulez mon avis, il y a deux choses à comprendre avant tout pour vraiment se familiariser avec CSS :

Les astuces

Une fois que vous avez compris ça, vous êtes sur la bonne voie. À partir de là, vous n’aurez qu’à apprendre quelques astuces pour vous débrouiller avec les cas spécifiques. Et vous n’avez pas fini d’en croiser. Laissez-moi vous en montrer quelques-unes.

Le coup du « j’ai oublié de positionner l’élément parent »

.enfant {
    position: absolute;
    top: 0;
    left: 0;
}
 
/* Ceci a été oublié */
/*
.parent {
    position: relative; // Ou n’importe quelle autre valeur que static.
}
*/

Et c’est là que vous vous dites : « Hein ?! Mais pourquoi est-ce que mon élément est en haut à gauche de la page ? » Eh oui : vous avez oublié de définir la position de l’élément parent (relative, absolute, tout ce que vous voulez sauf static).

Le coup du « contexte d’imbrication »

.parent {
    z-index: 1;
    opacity: 0.5;
    transform: rotate(5deg);
}
 
.enfant {
    z-index: -1;
}

Tous les développeurs au monde ont bataillé au moins une fois sur le sujet de l’imbrication de boîtes. En résumé, il est tout simplement impossible d’appliquer un z-index à un enfant d’un élément (ou d’un pseudo-élément) qui possède déjà un contexte d’imbrication (déclenché soit par z-index, opacity ou transform) ; il n’y a pas d’autres possibilités. Une fois que vous maîtrisez ça, impossible de l’oublier, promis.

NB : pour plus d’information à propos de z-index et de l’imbrication CSS, je vous recommandece superbe billet de Steven Bradley.

Le coup du « J’ai oublié d’effacer le flottant »
Votre mise en page devient folle. Les blocs se baladent n’importe où. Vous pleurez sans comprendre les raisons de cet affichage étrange. Alors vérifiez vos flottants ! Dans la plupart des cas, c’est que vous avez oublié de les réinitialiser.

Note : dans le cas où un parent contient uniquement des éléments flottants, il va se réduire à moins que vous n’annulez les flottants, ou alors que vous définissiez une hauteur ou un overflow (NdT : propriété définissant les dépassements de blocs ou comment le contenu est rogné : si le contenu dépasse les dimensions d’un bloc, overflow permet de cacher le contenu, d’afficher une barre de défilement ou pas).

Je pourrais continuer pendant des heures sur ces sujets, mais ce n’est pas le but de cet article. Je dirais que CSS présente un grand nombre de cas particuliers et on en découvre encore chaque jour. Tant que vous ne vous serez pas cassé les dents dessus, vous ne saurez pas qu’ils existent ; mais ensuite, vous saurez comment les traiter.

3. DRY

DRY est l’acronyme de Don’t Repeat Yourself (Ne pas se répéter, NdT), et encore une fois ce n’est pas spécifique à CSS. Il s’agit plutôt d’une pratique répandue lorsque vous codez, quel que soit le langage avec lequel vous avez à composer.

Ainsi, l’idée principale est d’éviter de répéter les mêmes bouts de code X fois alors qu’une seule fois pourrait suffire. Dans certains langages, cela peut évoquer l’utilisation d’une fonction, mais en CSS, cela signifie utiliser une classe plutôt que cibler un élément spécifique (voir plus loin la section concernant OOCSS). Pourtant, parfois il existe une chose vraiment simple comme la mutualisation de son code (refactoring). Laissez-moi vous expliquer.

Si vous êtes en présence d’un bout de code qui est présent plusieurs fois dans votre feuille de style, il pourrait être intéressant de le mutualiser (refactoriser) afin de n’avoir plus qu’une seule occurrence. Lisez ce qui suit :

.navigation li {
    color: #333;
}
 
.navigation li a {
    color: #333;
}
 
/* Mutualisé */
 
.navigation li,
.navigation li a {
    color: #333;
}

Vous voyez ? Vous vous demandez peut-être quel est l’intérêt, puisque le résultat est le même. Il y a deux choses à prendre en compte : la performance et la facilité de maintenance.

À propos de la performance : moins de lignes de code signifie un parcours plus rapide de la CSS par le navigateur. Pour faire simple, le navigateur va appliquer la couleur aux deux règles à la fois au lieu de le faire deux fois.

À propos de la maintenance, je pense que cela parle de soi-même. En procédant de la sorte, vous avez seulement une ligne à changer alors qu’avant vous deviez en changer deux pour modifier la couleur. Qu’en est-il quand vous avez 50 fois ou 300 fois le même code ?

Plus d’informations sur DRY CSS

4. OOCSS

C’est quoi ce truc ?

OOCSS est l’acronyme d’Object-Oriented CSS (CSS Orienté Objet, NdT) . Vous avez probablement entendu parler de la programmation orientée objet. Il s’agit tout bonnement d’utiliser des « objets », généralement des instances de classes (qui se composent d’attributs et de méthodes). J’imagine que vous vous demandez quel peut être le rapport avec CSS ?

Premièrement, disons que c’est plus un concept ou une bonne pratique qu’un vrai principe. CSS ne peut pas vraiment être orienté objet sachant que ce n’est pas un langage de programmation : pas d’espace de nommage, pas de fonctions, pas de méthodes, pas de classes de programmation, aucune des instructions conditionnelles, etc. C’est pourquoi certaines personnes ricaneront quand vous parlerez d’OOCSS.

Même si je suis d’accord avec cela, malgré tout nous pouvons encore optimiser notre façon de coder les CSS pour faciliter le processus, rendre les sites Web plus rapides et améliorer la maintenabilité.

Comment faire ?

Pour le dire simplement, cela signifie utiliser des classes. Un grand nombre de classes. Pensez à votre site comme s’il possédait des « modules » ou des « composants », si vous voulez. Essayez de repérer les modèles qui se répètent pour en faire des « objets » (classes) afin de les réutiliser.

Pour être un peu plus précis, cela signifie essentiellement deux choses :

Séparer structure et apparence

Séparer la structure et l’apparence peut se révéler important : vous savez que des éléments graphiques peuvent être utilisés à plusieurs endroits sur un site web et sur plusieurs types d’éléments­­­­, n’est-ce pas ? Prenez le bout de code suivant, cela peut convenir à un bouton, à une image, ce que vous voulez :

#mon-bouton,
.ma-boite
.ma-boite img {
    border: 1px solid #444;
    border-radius: 5px;
    box-shadow: 0 0 5px rgba(0,0,0,0.1);
}

Maintenant, au lieu de ce qui précède, nous pourrions créer une classe qu’on appellerait « habillage » (skin) ou quelque chose comme ça, et l’appliquer aux éléments qui en ont besoin. Le résultat est beaucoup plus compréhensible, la feuille de style plus maintenable et une interprétation de classes plus rapide.

.habillage {
    border: 1px solid #444;
    border-radius: 5px;
    box-shadow: 0 0 5px rgba(0,0,0,0.1);
}

Séparer conteneurs et contenu

Je pense que c’est l’une des règles les plus importantes de OOCSS : coder des composants indépendants, pas des bouts de code pour un élément spécifique de votre modèle. Les choses devraient être réutilisables, quelle que soit leur place sur votre site Internet, sans les coder à nouveau. Prenons l’exemple suivant :

#principal h2 {
    color: #343434;
    font-size: 25px;
    line-height: 20px;
    border-bottom: 1px solid rgba(0,0,0,0.2);
    box-shadow: 0 1px rgba(255,255,255,0.4);
}

D’accord. Maintenant, si je veux exactement le même style sur un titre de niveau 2 placé dans le pied de page ? Ou bien mettre en forme un titre de niveau 3 placé exactement de la même manière (quelle qu’en soit la raison) ? La meilleure façon de faire consisterait à créer une classe et à donner ces styles à cette classe, pas aux éléments eux-mêmes.

Qu’en est-il du « ne jamais utiliser d’ID » ?

Quand Nicole Sullivan a découvert le concept de CSS orienté-objet, ce fut un sujet chaud. En effet CSSLint, un outil de qualité du code CSS créé par Nicholas C. Zakas et Nicole Sullivan, déconseille l’utilisation des sélecteurs d’ID.

Pour comprendre le point de vue de Nicole, il est important de comprendre que les ID peuvent poser certains problèmes de priorité, car ils ont le score le plus élevé dans ce domaine. Prenez le code suivant à titre d’exemple (à voir sur CSSWizardry - source ici) :

<!-- HTML -->
<div id="en-tete">
  <p>
    <a href="#">Foo</a>
    <a href="#">Bar</a>
  </p>
  <div class="tweet">
    <a href="#">Suivez-moi sur twitter</a>
  </div>
</div>
<div class="tweet">
    <a href="#">Suivez-moi sur twitter</a>
</div>

/* CSS */
#en-tete a { color: #f90;  }
.tweet     a { color: #000; }

Pour mettre le premier lien Twitter en noir, vous avez deux options : soit lui donner une ID, soit utiliser le lourdaud <important!>. Si #en-tete était une classe au lieu d’une ID, le problème n’aurait pas existé.

C’est en partie la raison pour laquelle Nicole Sullivan a dit « pas d’ID ».

Je finirai cette partie par la citation de Harry Roberts sur le sujet : « [...] J’ai décidé qu’une interdiction générale était l’option la plus logique. Épargnez-vous beaucoup de soucis : n’utilisez jamais d’ID dans vos fichiers CSS ».

Bien sûr, il est tout à fait possible d’utiliser des IDs qui restent parfaitement valides.

Quel est mon sentiment sur OOCSS ?

En ce qui me concerne, je ne suis pas vraiment un expert sur le sujet. D’abord parce que je n’ai jamais travaillé sur un site énorme impliquant de nombreux développeurs front-end. Ne nous leurrons pas, c’est sans doute très utile pour les sites de grande importance, mais pas forcément pour le petit site que vous faites pour votre boulanger.
Cependant, même si je n’utilise pas OOCSS dans mes projets, j’essaie de me concentrer sur les choses importantes comme la réutilisation des composants, la maintenabilité de la feuille de style, la performance et autres. Ce sont les choses sur lesquelles OOCSS se concentre, donc d’une certaine façon, je ne suis pas si loin de la logique.

Autres ressources sur OOCSS et les IDs

5. CSS3 : découvrez ce que vous pouvez faire et ce que vous pouvez utiliser

Bon, assez de concepts. Parlons de choses sérieuses. Parlons un peu de CSS3. Bien qu’en réalité CSS3 n’existe pas en tant que tel :

Contrairement à CSS2, qui est une importante spécification définissant diverses caractéristiques, CSS3 est divisé en plusieurs documents séparés appelés « modules ». Chaque module ajoute de nouvelles fonctionnalités ou étend les fonctions définies dans CSS2, sur la préservation de la rétro-compatibilité. [...] En raison de la modularisation, les différents modules sont plus ou moins stables et aboutis.

(Traduction de Cascading Style Sheets sur Wikipedia EN)

Mais entendons-nous sur le fait que nous parlons des nouvelles fonctionnalités que comprennent les navigateurs modernes.

De nos jours, CSS3 est partout : des bords arrondis aux dégradés, de la transparence aux ombres et pseudo-éléments.

Que peut-on faire ?

À mon avis, vous pouvez vous servir de CSS3 pour réduire le nombre de requêtes HTTP (images), le nombre de balises et la taille des fichiers JavaScript. Voyons cela de plus près :

Et je pourrais continuer longtemps mais je pense que vous avez compris. Ce que je veux faire passer comme message, c’est ceci : lancez-vous, et découvrez tout ce que vous pouvez faire avec CSS3. Vous devez créer une table des matières ? Sachez que vous pouvez le faire uniquement avec CSS grâce à CSS counters. Vous devez définir une bordure originale personnalisée pour un site ? Sachez qu’il existe une propriété border-image pour l’intégrer.

Vous pouvez faire un million de choses avec CSS, et c’est encore plus vrai quand il s’agit de CSS3. Il est important de savoir ce que vous pouvez faire ou pas. Malheureusement, il n’existe pas de potion magique pour cela, vous devez lire la documentation et faire des expériences. À partir de là, vous apprendrez que vous pouvez faire des calculs avec la propriété calc (), mais vous ne pourrez pas obtenir 6 colonnes d’égale hauteur sans avoir à vous battre comme un beau diable.

Apprendre ce que vous pouvez utiliser

Le plus gros problème avec CSS, c’est que tous les navigateurs ne prennent pas en charge les mêmes propriétés. Pire, certaines propriétés sont gérées de plusieurs manières différentes quand il s’agit de CSS3. Ce sera votre plus grande malédiction lors de l’expérimentation avec CSS3.

À titre d’exemple, prenez la propriété CSS3 la plus simple : border-radius (coin arrondi). Eh bien, il y a des navigateurs qui ne comprennent pas les coins arrondis (IE8 + version antérieure et Opera Mini). En fait, même Firefox et Chrome n’interprètent pas border-radius de la même façon (ou ne l’ont pas toujours fait de la même façon).

Qu’est-ce que cela signifie pour vous en tant que développeur front-end ? Cela veut dire que si vous devez afficher des coins arrondis dans tous les navigateurs, vous pouvez le faire à l’ancienne. Arrière-plans multiples + images multiples, ou alors adopter les deux solutions et servir l’une ou l’autre en fonction du navigateur.

Quand je dois faire quelque chose en CSS, voici le processus que je suis :

  1. Comment vais-je faire cela ?
  2. D’accord, je comprends. Fait-il partie de la spécification CSS2.1 ?
    1. Oui : fastoche, fin de l’histoire.
    2. Non, passez à l’étape 3.
  3. Quelle est la qualité du rendu par les navigateurs ?
    1. Bonne : fastoche, fin de l’histoire.
    2. Mauvaise, passez à l’étape 4.
  4. Est-ce une amélioration ou une fonction vitale ?
    1. C’est juste une amélioration. Je ne fais rien pour les navigateurs non pris en charge ou à la limite j’ajoute une solution de repli (fallback).
    2. Il s’agit d’une caractéristique essentielle : passez à l’étape 5.
  5. Comment vais-je le faire fonctionner dans les navigateurs non pris en charge ?

Prenons un exemple réel, d’accord ? Avec quelque chose de simple, comme un dégradé. Allons-y.

  1. Comment vais-je faire cela ?
  2. D’accord, je comprends. Fait-il partie de la spécification CSS2.1 ?
    • Non, les dégradés appartiennent à CSS3.
  3. Quelle est la qualité du rendu par les navigateurs ?
    • Pas mal, mais pas parfait. IE8 + versions antérieures ainsi qu’Opera Mini ne prennent pas en charge les dégradés CSS.
  4. Est-ce une amélioration ou une fonctionnalité vitale ?
    1. Il s’agit plutôt d’une amélioration graphique, rien de fondamental. Je vais ajouter une couleur unie comme solution de repli.
    2. C’est un élément graphique indispensable : je dois le faire fonctionner pour les navigateurs non supportés.
  5. Comment vais-je faire pour les anciens navigateurs ?
    • Je vais devoir recourir à une image d’arrière-plan.

Grâce à ce processus pas à pas, vous savez comment faire quelque chose avec CSS (si c’est faisable), si vous pouvez l’utiliser en tenant compte du support des navigateurs et comment créer des solutions de repli.

NB : souvenez-vous toujours de l’audience cible de votre site web ou de votre application. Si vous créez du contenu web pour une application iPad, vous pourrez utiliser de nombreuses propriétés CSS3 sans vous soucier des solutions de repli. Toutefois si vous créez un site pour une banque, rappelez-vous que beaucoup de gens utilisent encore IE8 ou des versions plus anciennes encore.

Fournir des solutions de repli

Selon la situation, fournir une solution de repli pour les navigateurs non pris en charge peut être soit ridiculement simple soit extrêmement pénible. En effet, il y a des cas différents. Regardons cela de plus près.

Pas de solution de repli ou une solution de repli simple

Quand il y a une amélioration de l’expérience utilisateur dont l’absence de prise en charge est sans conséquences, vous n’êtes même pas obligés de fournir une solution de repli. C’est appréciable.

Il y a aussi quelques propriétés qui sont faciles à traiter quand il s’agit de solution de repli. En général, vous devez seulement écrire deux versions de cette propriété : d’abord la solution de repli, puis la version correcte pour les navigateurs qui le supportent.

.mon-element {
    border: 1px solid #666;
    border: 1px solid rgba(0,0,0,0.3);
    background: #708090;
    background: hsl(210, 13%, 50%);
}

Dans ce cas, les navigateurs ne supportant pas rgba et hsl ne liront pas les lignes 3 et 5 ; de ce fait vous fournissez des versions alternatives aux lignes 2 et 4. Pour les navigateurs pris en charge, ils vont d’abord appliquer la version alternative, puis la remplacer par la version correcte.

Modernizr

De nos jours, on ne peut guère parler de CSS3 sans mentionner Modernizr. Il s’agit d’une bibliothèque JavaScript qui teste la prise en charge des fonctionnalités HTML5 et CSS3 au chargement de la page. Cela peut sembler lourd, mais il est bien optimisé et assez rapide.

Quoi qu’il en soit, parfois, il faut savoir précisément si le navigateur prend en charge une fonctionnalité particulière. Notamment pour fournir une version alternative nécessitant d’autres propriétés CSS.

/* Version normale */
.menu-deroulant {
    opacity: 0;
    pointer-events: none;
}
 
.declencheur:hover .menu-deroulant {
    opacity: 1;
    pointer-events: auto;
}
 
/* Solution de repli avec Modernizr */
 
.no-opacity .menu-deroulant,
.no-pointerevents .menu-deroulant {
    opacity: 1;
pointer-events: auto;
display: none;
}
 
.no-opacity .declencheur:hover .menu-deroulant,
.no-pointerevents .declencheur:hover .menu-deroulant {
    display: block;
}

Pour fournir une solution de repli de ce type, les classes ajoutées par la bibliothèque Javascript Modernizr vous seront d’un grand secours (.no-opacity [sans-opacite] et .no-pointerevents [sans-evenementpointeur]). Vous ne pouvez pas avoir les deux versions simultanément.

Quoi qu’il en soit, n’oubliez jamais de définir une solution de repli, c’est vraiment important. Les fonctionnalités majeures doivent être prises en charge par tous les navigateurs, tant les anciens que les nouveaux, et si ce n’est pas le cas partout, vous devez avertir l’utilisateur.

Donc, soit vous commencez avec une base simple et l’améliorez pour les navigateurs récents, soit vous commencez avec une base moderne et vous composez pour les navigateurs plus anciens. Voir la section suivante pour plus d’informations.

Autres ressources sur CSS3 :

6. Amélioration progressive et dégradation élégante

Ce sont deux termes dont vous avez probablement déjà entendu parler, en particulier la dégradation élégante, mais il y a une différence subtile entre les deux.

Amélioration progressive

Le principe de l’amélioration progressive est d’établir une base commune de fonctionnalités et de fonctions disponibles, et ensuite, d’améliorer l’expérience utilisateur en fonction de ce que le navigateur prend en charge.

Utiliser l’attribut HTML5 required pour avertir l’utilisateur qu’un champ est manquant dans un formulaire avant de le soumettre peut être considéré comme une amélioration progressive. Il s’agit d’une amélioration de l’expérience utilisateur rendue possible grâce au moteur natif du navigateur.

Dégradation élégante

Vous utilisez la dégradation élégante lorsque vous déclinez une version alternative ou inférieure de vos fonctionnalités au cas où elles ne sont pas prises en charge. Fondamentalement, on part du plus haut pour aller vers le plus bas.

Un exemple très simple serait l’avertissement que vous mettez entre les balises <canvas> pour informer les utilisateurs de navigateurs qui ne les prennent pas en charge qu’il y a quelque chose qu’ils ne peuvent pas voir.

<canvas>
Cette page utilise HTML5 Canvas. Veuillez utiliser un navigateur récent pour voir ce contenu. Pour obtenir un autre navigateur, allez à <a href="http://browsehappy.com/">BrowseHappy</a>
</canvas>

Quelle est la différence ?

En fin de compte, il n’y en a pas. Vous avez des fonctionnalités pour les navigateurs récents et des fonctionnalités ou des solutions de repli pour les plus anciens. C’est plutôt une question de procédure : soit vous codez pour les navigateurs modernes tout en proposant une solution de repli pour les anciens, soit vous le faites dans l’autre sens. C’est un choix.

En tout cas, je veux redire ici que l’expérience utilisateur n’est pas nécessairement la même dans tous les navigateurs. En fait, ce n’est même pas possible, puisque les moteurs des navigateurs sont différents. Quoi qu’il en soit, vous devez fournir des fonctionnalités de base pour tout le monde, mais faites-moi plaisir : améliorez votre site web ou votre application pour les navigateurs modernes. Ils sont bien conçus, ils fournissent des fonctionnalités à l’état natif : utilisez-les.

Lectures complémentaires sur l’amélioration progressive et la dégradation élégante

7. Les préprocesseurs CSS

Aaaah, les préprocesseurs… Le sujet chaud du moment. Sont-ils utiles ? Pour quoi faire ? Devrais-je en employer un ? Lequel ? Je pense que c’est l’un des sujets les plus débattus sur CSS en ce moment.

Je vais essayer d’être aussi objectif que possible dans cette partie. Permettez-moi de commencer par ceci : si vous ne voulez pas utiliser un préprocesseur, alors ne le faites pas. Ce ne sera jamais un problème. Vous ne serez pas un mauvais développeur front-end pour autant. Cela ne vous rendra pas incapable de faire certaines choses. Mais vous devriez, néanmoins, essayer de vous faire votre propre opinion à ce sujet.

Ok, j’en ai fini avec les précautions. Qu’est-ce qu’un préprocesseur, de manière générale ? Un préprocesseur est une sorte d’outil qui compile une syntaxe donnée dans une langue utilisée par un autre programme (dans le cas présent : le navigateur). Il y a des préprocesseurs pour de nombreux languages : il y a Markdown ou Jade pour le HTML. Il y a LESS, Sass et Stylus pour CSS. Il existe CoffeeScript pour JavaScript. Il y a CakePHP pour PHP et ainsi de suite.

De quoi parle-t-on ?

Un préprocesseur CSS fournit aux CSS certaines particularités à partir de langages orientés objet. Des choses comme :

Ça a l’air attrayant, non ? Peut-être que vous voulez un exemple pour comprendre la manière dont cela fonctionne. Prenons le CSS suivant pour une barre de navigation.

.navigation {
    width: 800px;
    width: calc(100%-150px);
}
.navigation li {
    color: #444;
}
.navigation li a {
    text-decoration: none;
}

Et voici maintenant la version compilée (SCSS) :

$couleur-principale: #444;
 
.navigation {
    width: (100%-150px);
    li {
        color: $couleur-principale;
        a {
            text-decoration: none;
        }
    }
}

En gros, un préprocesseur va interpréter ceci dans une version CSS standard. Ce sera exactement la même chose, sauf pour le calcul. Il lancera l’opération elle-même et affichera le résultat correspondant sans qu’il soit nécessaire d’utiliser une fonction comme calc().

Donc, vous vous retrouvez avec une feuille de style plus compréhensible (variables et imbrications) et plus facile à maintenir (variables et fonctions). C’était un exemple très théorique, mais dans un projet réel, vous sentirez la différence.

Comment le choisir ?

Il existe beaucoup de préprocesseurs CSS, chacun avec ses avantages et ses particularités. Quoi qu’il en soit, chacun d’entre eux fait plus ou moins la même chose, donc le choix vous appartient. Voici les principales options quand il s’agit de préprocesseurs CSS :

L’idéal, c’est d’apprendre à les connaître, de les tester et de voir ce qui répond le mieux à vos besoins et à votre projet. Il y a plusieurs facteurs qui entrent en jeu ; les énumérer tous serait hors de la portée de cet article, mais vous pouvez trouver quelques ressources pertinentes ci-dessous.

Mon sentiment sur les préprocesseurs CSS ?

Je ne suis pas un expert quand il s’agit de préprocesseurs CSS, mais j’en suis un partisan. Ils fournissent des fonctionnalités très utiles mais qu’on ne trouve pas dans les CSS comme les variables, les déclarations, l’imbrication et les conditions.

J’ai bricolé un peu avec LESS, et il m’a fait à peu près ce que je voulais. Ou du moins, jusqu’à ce que je commence à me lancer dans des choses un peu plus compliquées que vous avez pu lire dans mon dernier article sur CSS Loading Animations (pour les boucles + préfixes vendeurs + keyframes).

J’ai aussi jeté un coup d’œil rapide à Sass et Compass. À ma grande surprise, c’était incroyablement facile à installer et à lancer grâce à Ruby. J’avais peur, mais c’est très très intuitif, croyez-moi. En fin de compte, je suis vraiment impressionné par l’association Sass + Compass. Vous pouvez également en savoir plus sur les raisons pour lesquelles je suis passé de LESS à Sass dans cet article sur mon blog.

Quoi qu’il en soit, je suis encore tout à fait capable d’écrire des CSS classiques sans préprocesseur, et la plupart du temps c’est ce que je fais. Mais au final, je pense que nous allons tous en utiliser un, quel qu’il soit. Il nous manque vraiment certains éléments très utiles avec les CSS, et les préprocesseurs CSS sont là pour y remédier.

Lectures complémentaires sur les préprocesseurs CSS

8. Garder un œil sur l’avenir

Les langages sont en constante évolution. C’est particulièrement vrai pour les CSS. Les spécifications CSS bougent sans cesse, et les navigateurs ajoutent sans cesse de nouvelles fonctionnalités à leurs moteurs.

À ce propos, mon premier conseil serait de rester à l’écoute de ce qui se prépare. Je sais que vous ne pouvez pas être en mesure de tout utiliser dès son lancement, mais savoir quelle fonctionnalité est maintenant prise en charge par Canary Chrome, bientôt par Chrome version stable et Safari, puis par Opera, Firefox et ainsi de suite, c’est important afin de prendre du recul sur les problèmes CSS et les solutions possibles.

Ressources pour garder un œil sur l’avenir :

9. Lire le code des autres

Une des meilleures façons d’apprendre à coder est de lire du code.

Heureusement, le CSS est visible côté client, ce qui vous permet de le lire sur n’importe quel site avec un inspecteur web comme WebKit inspector, Dragonfly, Firebug, etc. De plus, l’industrie du web est très orientée vers l’open-source, ce qui signifie que les gens sont heureux de partager leurs sources avec vous.

Une autre excellente façon d’apprendre est de suivre des tutoriels. Prenez un tutoriel simple, et suivez-le étape par étape. Ensuite, essayez de le refaire à partir de zéro. S’il vous arrive d’être bloqué, jetez un coup d’œil à la solution, puis continuez par vous-même.

Lorsque vous serez à l’aise avec CSS et que vous voudrez entrer finement dans les détails, vous voudrez peut-être jeter un œil à des démonstrations et des expériences qui ne sont pas commentées ni expliquées. Les gens créent des choses tous les jours, et vous tomberez sans arrêt sur des choses que vous ne connaissiez pas encore.

À ce sujet, il y a quelques mois Chris Coyier, Tim Sabat et Alex Vazquez ont lancé CodePen, une sorte de plate-forme pour créer, partager et explorer du code (HTML, CSS, JavaScript). CodePen comprend également un tas d’outils comme les bibliothèques (jQuery, jQuery UI, MooTools, YUI, Prototype, Zepto, Dojo, Ext JS, PrefixFree, etc) et les préprocesseurs (HAML, Markdown, Slim, LESS, SCSS, Sass, CoffeeScript) si vous en avez besoin.

D’autres ressources pour trouver des exemples de code créé par d’autres personnes :

10. Pratiquez sans relâche

Vous savez ce qu’on dit à propos de l’apprentissage : on apprend en faisant. Donc, mon meilleur conseil est de continuer à pratiquer comme pour toute autre chose. Plus vous pratiquez, meilleur vous serez. La pratique ne signifie pas nécessairement faire un site web à partir de zéro. Il suffit de choisir une capture simple sur Dribbble et d’essayer de la refaire en CSS. Le résultat ne sera peut-être pas utile immédiatement, mais ce que vous avez appris vous sera utile un jour.

Et comme je l’ai dit dans la partie « Apprendre les bases et quelques astuces » de cet article, CSS est plein de cas particuliers. Vous devrez apprendre à les gérer si vous voulez écrire des CSS. Et la seule façon de connaître ces cas particuliers consiste à pratiquer, découvrir de nouveaux cas, jeter un œil à la solution, et continuer.

Je vous recommande aussi de partager votre code. Il est toujours utile d’obtenir un retour constructif, alors assurez-vous de demander aux gens de vérifier votre code une fois qu’il est presque fini. Il suffit de les déposer dans un JSFiddle, de partager et de demander des commentaires.

Sommaire et crédits

Comme cet article mentionne un tas de liens et de ressources diverses, autant les rassembler tous au même endroit :

Merci beaucoup d’avoir lu cet article. J’espère qu’il vous aidera d’une manière ou d’une autre à améliorer la façon dont vous apprenez et utilisez les CSS.

http://tympanus.net/codrops/2012/11/20/learning-principles-for-improving-your-css/

Fiche technique

À propos de l'auteur

Gobelin CSS et Hacker Sass, pyschopathe des marges, auteur de http://browserhacks.com

Articles similaires

Voici la liste des dix articles les plus récents en rapport avec cet article :

Tous niveaux

CSS

Intégration

© 2001-2024 Pompage Magazine et les auteurs originaux - Hébergé chez Nursit.com ! - RSS / ATOM - About this site