vendredi, 20 mai 2016

Techniques de développement CSS

Cet article est une traduction de CSS coding techniques écrit par Belén Albeza. Belén travaille au sein de l’équipe DevRel de Mozilla et explique ici sa méthode de travail pour le code CSS afin d’obtenir des feuilles de style claires et qui puissent être maintenues facilement. Comme les autres articles de ce blog, celui-ci est placé en licence CC-BY-SA.

Merci beaucoup à Marine, Ilphrin, Banban, Sandlayth, au traducteur anonyme ainsi qu’à goofy pour sa relecture utile :)


Ces derniers temps, nous avons pu observer de nombreuses personnes qui rencontraient des difficultés avec CSS, aussi bien des débutants que des développeurs confirmés. Certains n’apprécient pas la façon dont le langage fonctionne et se demandent s’il ne vaudrait pas mieux remplacer CSS par un autre langage (ce qui a donné naissance aux processeurs CSS) ; d’autres utilisent des frameworks en espérant écrire moins de code (nous avons vu dans un article précédent que, généralement, ce n’était pas le cas). D’autres encore abandonnent CSS pour n’utiliser que JavaScript à des fins de mise en forme.

Toutefois il n’est pas toujours nécessaire d’ajouter un processeur CSS dans vos outils de travail. Nul besoin non plus d’ajouter un framework lourd simplement pour démarrer un projet. Quant à utiliser JavaScript pour faire ce pour quoi CSS a été conçu… c’est simplement une idée épouvantable.

Dans cet article, nous allons présenter quelques conseils et recommandations afin d’écrire du code CSS de meilleure qualité et qui soit plus facile à maintenir, en utilisant des feuilles de style plus courtes, avec moins de règles. Au lieu d’être un fardeau CSS pourra s’avérer réellement utile.

Le sélecteur minimal

CSS est un langage déclaratif dans lequel on définit des règles qui permettent de mettre en forme les éléments du DOM. Dans ce langage, certaines règles sont prioritaires sur d’autres selon l’ordre dans lequel elles sont appliquées. Ainsi, les styles définis dans le document remplacent certaines règles déclarées avant.

Prenons par exemple ces fragments de code CSS et HTML :

<button class="button-warning">

 

.button-warning {
  background: red;
}
button, input[type=submit] {
  background: gray;
}

Bien que la règle .button-warning soit définie avant la règle button.input[type=submit], elle prendra la priorité sur cette seconde. Pourquoi ? Quel critère est utilisé afin de décider que telle règle surcharge telle autre ?

La spécificité

Certains sélecteurs sont plus spécifiques que d’autres. Un sélecteur d’identifiant #id aura la priorité par rapport à un sélecteur de classe .class. Que se passe-t-il lorsqu’on utilise un sélecteur qui est plus spécifique que nécessaire ? Si, par la suite, on a besoin de surcharger ces règles, il faudra utiliser un sélecteur qui soit plus spécifique. Plus tard, s’il faut aller plus loin dans le détail, il faudra… encore ajouter un niveau de spécificité. On a ici une boule de neige qui risque de se transformer en avalanche, impossible à maintenir efficacement.

Aussi, quand vous écrivez vos sélecteurs, demandez-vous toujours : quel est le sélecteur le moins spécifique qui peut fonctionner ici ?

Toutes les règles liées à la spécificité sont officiellement définies dans la spécification du W3C sur les sélecteurs CSS, la meilleure source pour retrouver tous les détails qui touchent aux sélecteurs CSS. Si vous préférez quelque chose de plus abordable, vous pouvez lire cet article sur la spécificité en CSS (N.D.T. ou cette page de MDN disponible en français).

L’ajout de nouvelles règles : c’est pas automatique

Prenons une situation classique : il y a une anomalie dans votre code CSS et vous avez trouvé l’élément du DOM qui a récupéré le mauvais style. Ensuite, vous vous apercevez que celui-ci hérite d’une propriété et que ça n’aurait pas dû être le cas.

N’ajoutez pas plus de CSS. Si l’ajout de règles devient un réflexe, votre base de code grandira un peu plus et les bugs à venir seront encore plus difficiles à diagnostiquer.

Profitez-en pour prendre du recul, utilisez les outils de développement de votre navigateur et inspectez l’élément pour voir toute la cascade. Repérez la règle précise qui applique le style indésirable et modifiez cette règle existante pour qu’elle n’ait aucune conséquence malheureuse.

Avec Firefox, vous pouvez déboguer la cascade en cliquant droit sur un élément d’une page et en sélectionnant l’option « Examiner l’élément ».

La cascade CSS via l'inspecteur

Et voilà la superbe cascade. On peut voir ici toutes les règles qui s’appliquent à un élément et l’ordre dans lequel elles sont appliquées. Les règles en haut sont les plus spécifiques et peuvent surcharger les styles déclarés par ailleurs. On peut également voir que, dans certaines règles, certaines déclarations sont rayées : cela signifie qu’une règle plus spécifique s’applique à cette propriété.

En plus de voir les règles, vous pouvez également les activer et les désactiver ou les modifier pour observer les conséquences à la volée. En bref, un outil plutôt utile pour déboguer !

Le correctif pourra être une modification d’une règle, éventuellement autre part dans la cascade. Ça peut tout à fait être une nouvelle règle. Au moins, vous saurez que c’était la bonne décision à prendre et que cette règle était nécessaire à votre code.

C’est un bon moment pour lire le code et chercher les éléments qui peuvent être refactorés. Bien que CSS ne soit pas un langage de programmation, c’est du code et, à ce titre, il devrait recevoir la même estime que celle accordée au code JavaScript ou Python : il doit être propre, lisible et refactoré lorsque c’est nécessaire.

Si tout est !important, rien n’est !important !

Ceci est implicite après les précédentes recommandations, mais puisque c’est crucial je le souligne ici : n’utilisez pas !important dans votre code.

!important est une fonctionnalité du CSS qui vous permet de briser la cascade. CSS veut dire « Cascading Style Sheets » (N.D.T pour « feuilles de style en cascade »), c’est un indice.

!important est souvent utilisé pour corriger un bug à la hâte sans avoir le temps de corriger la cascade. C’est aussi fréquemment utilisé lorsqu’on inclue un framework CSS avec des règles très spécifiques et qu’il est simplement trop compliqué de les surcharger.

Lorsque vous ajoutez !important à une propriété, le navigateur va ignorer les autre règles avec des spécificités plus grandes. On réalise le problème lorsqu’on ajoute !important à une règle qui en surcharge une autre règle, déjà marquée avec !important. Il existe un cas légitime pour utiliser !important : l’utilisation des outils de développement à des fins de débogages. Parfois, vous avez besoin de trouver les valeurs d’une propriété qui vous permettront de résoudre votre bug. Utiliser !important via les outils de développement en modifiant le CSS à la volée vous permettra de trouver ces valeurs en ignorant la cascade.

Une fois que vous savez quel CSS fonctionnera, vous pouvez retourner à votre code et regarder à quel point de la cascade il est nécessaire d’ajouter ce fragment de CSS.

Le monde ne s’arrête pas à px et %

Travailler avec les unités px (pixels) et % (pourcentages) est assez intuitif, nous allons donc nous concentrer sur les unités moins connues ou moins intuitives.

em et rem

L’unité relative la plus connue est em. 1em est équivalent à la taille de fonte de cet élément.

Imaginons le fragment HTML suivant :

<article>
  <h1>Titre</h1>
  <p>Un Anneau pour les amener tous et dans les ténèbres les lier.</p>
</article>

Et une feuille de style qui contient uniquement cette règle :

article {
  font-size: 1.25em;
}

Par défaut, la plupart des navigateurs appliquent une taille de fonte de 16 pixels à l’élément racine (ce qui peut d’ailleurs être modifié par l’utilisateur, c’est sympa et ça permet d’améliorer l’accessibilité). Le paragraphe de texte dans cet élément article sera probablement rendu à l’écran avec une taille de fonte (la propriété font-size) de 20 pixels (16 * 1.25). Qu’en est-il de h1 ? Pour mieux comprendre ce qui va se passer, ajoutons cette autre règle CSS à la feuille de style :

h1 {
  font-size: 1.25em;
}

Même si, là aussi, c’est 1.25em qui est utilisé, il faut tenir compte du fait que em est lié à l’environnement dans lequel elle est utilisée (on dit également qu’elle se « compose »). Cela signifie que si h1 était un héritier direct de body, par exemple, il aurait une taille de 20 pixels (16*1.25). Cependant, notre h1 est situé à l’intérieur d’un élément qui a une taille de fonte différente de la racine (article). Dans ce cas, le coefficient 1.25 s’utilise avec la taille de fonte donnée à la cascade et h1 sera affiché avec une taille de 25 pixels (16 * 1.25 * 1.25).

Au fait, au lieu de faire toutes ces multiplications successives de tête, vous pouvez utiliser l’onglet [Calculé] dans l’inspecteur d’éléments, il affiche la taille courante et la taille finale en pixels :

La cascade CSS via l'inspecteur

L’unité em est très souple et permet de modifier simplement, voire dynamiquement, les paramètres liés aux tailles d’élément (pas seulement font-size mais aussi line-height ou width)

Si vous appréciez l’aspect relatif de em mais que vous n’aimez pas la composition, vous pouvez utiliser l’unité rem. Celle-ci se comporte em sans composition, les valeurs sont uniquement liées aux tailles des éléments de base.

Si nous modifions notre précédent code CSS pour transformer les em en rem pour l’élément h1 :

article {
  font-size: 1.25em;
}

h1 {
  font-size: 1.25rem;
}

Tous les éléments h1 auront une taille de fonte de 20 pixels (on part du principe que la taille de base est 16 pixels), sans se soucier de savoir si le titre est dans un article ou non.

vw et vh

vw et wh sont des unités liées au viewport (N.D.T. la zone du document visible à l’écran). 1vw correspond à 1% de la largeur de la fenêtre tandis que 1vh correspond à 1% de sa hauteur. Ces unités sont incroyablement utiles si vous avez besoin d’une interface utilisateur qui occupe tout l’écran (par exemple le fond noir translucide d’une fenêtre interstitielle) et qui n’est pas toujours reliée à la taille du body.

Les autres unités

Il existe d’autres unités plus rares ou moins souples que vous rencontrerez forcément un jour. Vous pouvez en lire davantage à leur sujet sur MDN.

Utiliser les boîtes flexibles (flexbox)

Nous avons abordé ce sujet dans un article précédent sur les frameworks CSS. Le module des boîtes flexibles (ou flexbox) simplifie la création de disposition et les opérations d’alignement. Si vous ne connaissez pas les flexbox, n’hésitez pas à lire ce guide introductif.

Et oui, vous pouvez utiliser les flexbox dès aujourd’hui à moins de devoir prendre en charge les anciens navigateurs à des fins professionnelles. Actuellement, les boîtes flexibles sont prises en charge à 94% dans les navigateurs, il est grand temps d’arrêter d’utiliser tous ces div flottants, difficiles à déboguer et à maintenir. N’oubliez pas de garder un œil sur le module Grid en cours d’élaboration, ce module permettra de créer des dispositions en un clin d’œil.

De l’utilisation des processeurs CSS

Les compilateurs CSS comme Sass ou Less sont très populaires parmi les développeurs front-end. Ce sont des outils puissants qui, utilisés à bon escient, permettent de travailler plus efficacement avec CSS.

Attention à l’abus d’imbrication

We don’t need to go deeper

Une fonctionnalité souvent présente dans ces processeurs (ou compilateurs) est l’imbrication de sélecteurs. Ainsi, le code Less suivant :

a {
  text-decoration: none;
  color: blue;

  &.important {
    font-weight: bold;
  }
}

Sera traduit de la façon suivante en CSS :

a {
  text-decoration: none;
  color: blue;
}
a.important {
  font-weight: bold;
}

Cette fonctionnalité permet d’écrire moins de code et de regrouper les règles qui impactent les éléments proches au sein du DOM. C’est plutôt pratique pour le débogage.

Toutefois, on voit parfois des abus liés à cette fonctionnalité et les sélecteurs CSS obtenus finissent par refléter l’ensemble du DOM. Si on a la structure HTML suivante :

<article class="post">
  <header>
    <!-- … -->
    <p>Étiquettes : <a href="…" class="tag">non pertinent</a></p>
  </header>
  <!-- … -->
</article>

On pourra avoir une feuille de style Less comme celle-ci :

article.post {
  // … d'autres règles ici
  header {
    // …
    p {
      // …
      a.tag {
        background: #ff0;
      }
    }
  }
}

L’inconvénient ici, c’est que les sélecteurs obtenus sont extrêmement spécifiques. Or, on a déjà vu avant que c’était quelque chose à éviter. Il existe d’autres inconvénients liés à cette sur-imbrication que j’ai détaillés dans un autre article.

Bref, pour résumer : n’utilisez pas l’imbrication pour générer des règles CSS que vous ne rédigeriez pas vous-même.

Include / Extend ?

Les mixins sont une autre fonctionnalité utile des processeurs CSS et qui permettent de réutiliser des fragments de CSS. Imaginons qu’on veuille mettre en forme des boutons et que la plupart de ces boutons utilise des propriétés CSS simples. On pourrait alors créer un mixin comme celui-ci (rédigé ici en Less) :

.button-base() {
  padding: 1em;
  border: 0;
}

Puis créer la règle suivante qui utilise le mixin :

.button-primary {
  .button-base();
  background: blue;
}

Ceci générera le CSS suivant :

.button-primary {
  padding: 1em;
  border: 0;
  background: blue;
}

Comme vous pouvez le voir, le remaniement de code est très pratique !

En plus de l’inclusion d’un mixin, des options d’extension et d’héritage existent (la terminologie exacte diffère selon l’outil). Il s’agit d’une combinaison de plusieurs sélecteurs dans une unique règle.

Voyons un exemple en utilisant le mixin vu avant : .button-base :

.button-primary {
  &:extend(.button-base)
  background: blue;
}
.button-danger {
  &:extend(.button-base)
  background: red;
}

Ceci serait traduit en :

.button-primary, .button-danger {
  padding: 1em;
  border: 0;
}
.button-primary { background: blue; }.button-danger { background: red; }

Quelques articles sont partisans d’utiliser uniquement include tandis que d’autres préconisent l’usage de extend. En réalité, ils produisent chacun un CSS différent et aucun n’est intrinsèquement faux. Selon votre situation, l’usage de l’un ou de l’autre sera préférable.

Comment savoir lequel choisir ? Encore une fois, la règle générale « l’écrirais-je ainsi à la main ? » s’applique.


J’espère que cela pourra vous aider à réfléchir à votre code CSS et à écrire de meilleures règles. Comme nous l’avons déjà écrit plus haut : le CSS est du code et en tant que tel, il doit recevoir autant d’attention et de soin que le reste de votre base de code. Si vous en prenez soin, vous en tirerez de nombreux avantages.


Belén est ingénieur et développeur au sein de l’équipe Mozilla Developer Relations. Elle s’intéresse aux standards du Web, à la qualité du code, à l’accessibilité et au développement de jeux.

dimanche, 17 avril 2016

Ma méthode de travail avec Git et GitHub

Schéma du workflow

Cet article est une traduction de Documenting my git/GitHub worklow écrit par Karl Dubost. Karl participe au projet WebCompat pour veiller à ce que les sites web fonctionnent de façon égale sur les différents navigateurs et ce billet est l’occasion de présenter la méthode de travail qu’il utilise avec Git et GitHub. Les méthodes vues ici pourront être utile pour contribuer à d’autres projets, n’hésitez pas à guetter les fichiers CONTRIBUTING.md des différents dépôts. ;)


Lire la suite

mardi, 29 mars 2016

Aide aux développeurs pour les changements à venir dans le développement de modules

Cet article est une traduction de la communauté Mozfr de Developer support for changes in add-on development. Comme vous en avez peut-être entendu parler, de nombreux changements surviennent dans le développement des modules complémentaires. Fin 2017, les WebExtensions seront utilisées par Firefox  […]

Lire la suite

samedi, 5 mars 2016

Proposition de spécification pour l'API WebVR 1.0

WebVR Showcase

Cet article est une traduction de Introducing the WebVR 1.0 API Proposal écrit par Casey Yee et publié sur Hacks.

Merci beaucoup à Ilphrin et Thegennok pour la traduction ! Merci goofy pour la relecture :)


Lire la suite

samedi, 27 février 2016

La propriété background-clip et ses cas d'utilisation

Le modèle de boites

Cet article est une traduction de The background-clip Property and its Use Cases, écrit par Ana Tudor et publié sur CSS Tricks. Ana Tudor réalise de nombreuses démos sur CSS sur CodePen et via Twitter et cet article est l’occasion d’en dire un peu plus sur la propriété background-clip. Merci beaucoup à marine, Banban, Thegennok et Ilphrin pour la traduction et à Théo et goofy pour la relecture.

Lire la suite

samedi, 23 janvier 2016

Firefox et l'API Web Speech

Page about:Webspeech dans la vie conjugale

Ce billet est une traduction de l’article de Chris David Mills : Firefox and the WebSpeech API. Bien que la reconnaissance vocale ne soit pas encore tout à fait opérationnelle dans Firefox, n’hésitez pas à décortiquer les démos ! Merci à goofy pour la relecture :)

Lire la suite

samedi, 16 janvier 2016

Du nouveau pour les outils de développement dans Firefox

venkman-opt.png

Ce billet est une traduction du billet de Patrick Brosset : Revisiting Firefox’s DevTools. Merci à marine et Banban pour la traduction et à Maxime pour celle des articles MDN sur les outils de développement !

Lire la suite

samedi, 26 décembre 2015

Hors ligne et plus encore

Ce billet est une traduction du billet de Salva, Beyond Offline. Cet article est la suite du billet précédent sur les service workers. Merci à marine et Thegennok pour la traduction et à goofy pour la relecture !

Lire la suite

Recettes hors connexion pour les service workers

Page about:serviceworkers dans Firefox Developer Edition

Ce billet est une traduction du billet de David Walsh, Offline Recipes for Service Workers. Un grand merci à marine, Banban, Thegennok, LaPalice pour la traduction et à goofy pour la relecture. Bonne lecture et bonnes fêtes !

Lire la suite

jeudi, 17 décembre 2015

Enfin, on peut compiler en WebAssembly !

mamie fait du webAssembly

Ce billet est une traduction du billet publié par Alon Zakai sur hacks.mozilla.org.

Lire la suite

Les utilisateurs de Firefox sur Windows peuvent désormais regarder Netflix en HTML5

Ce billet est une traduction du billet en anglais paru sur le blog de Mozilla.

Lire la suite

lundi, 24 août 2015

ES6 en détails : l'avenir

typedarrays.png

Suite et fin de la la traduction, qui clôture la série d’articles de Jason Orendorff. L’article original se trouve ici. Vous pouvez retrouver les différents articles de la série grâce aux mots-clefs.

Merci à goofy pour la relecture :) !


Lire la suite

samedi, 22 août 2015

ES6 en détails : les modules

Suite de la traduction, qui continue la série d’articles de Jason Orendorff. L’article original se trouve ici. Vous pouvez retrouver les différents articles de la série grâce aux mots-clefs.

Merci à Banban et Ilphrin pour la traduction et merci à goofy pour la relecture :) !


Lire la suite

jeudi, 13 août 2015

ES6 en détails : les sous-classes et l'héritage

Suite de la traduction, qui continue la série d’articles de Jason Orendorff. L’article original se trouve ici. Vous pouvez retrouver les différents articles de la série grâce aux mots-clefs.

Merci à Banban et Marine pour la traduction et merci à goofy pour la relecture :) !


Lire la suite

vendredi, 7 août 2015

ES6 en détails : let et const

bogue.jpg

Suite de la traduction, qui continue la série d’articles de Jason Orendorff. L’article original se trouve ici. Vous pouvez retrouver les différents articles de la série grâce aux mots-clefs.

Merci à Banban et goofy pour la traduction et la relecture :) !


Lire la suite

vendredi, 31 juillet 2015

ES6 en détails : les classes

Suite de la traduction, qui continue la série d’articles de Jason Orendorff. L’article original se trouve ici. Vous pouvez retrouver les différents articles de la série grâce aux mots-clefs.

Merci à Jérémie et Banban pour la traduction et à goofy pour la relecture :) !


Lire la suite

dimanche, 26 juillet 2015

MDN : dix ans d'évolution

MDN-10years_twitter-avatar_400x400px.png

MDN fête ses 10 ans cette semaine. Ce billet, traduction du billet de Janet Swisher, est l’occasion de retracer l’historique de MDN et d’expliquer l’orientation du projet aujourd’hui.


Lire la suite

vendredi, 24 juillet 2015

ES6 en détails : les proxies

power-plant.jpg

Suite de la traduction, qui continue la série d’articles de Jason Orendorff. L’article original se trouve ici. Vous pouvez retrouver les différents articles de la série grâce aux mots-clefs.

Merci à Ilphrin et Banban pour la traduction et la relecture !


Lire la suite

jeudi, 16 juillet 2015

ES6 en détails : les générateurs, la suite

img1.png

Suite de la traduction, qui continue la série d’articles de Jason Orendorff. L’article original se trouve ici. Vous pouvez retrouver les différents articles de la série grâce aux mots-clefs.

Merci à goofy et Banban pour la relecture !


Lire la suite

mardi, 7 juillet 2015

ES6 en détails : les collections

Suite de la traduction, qui continue la série d’articles de Jason Orendorff. L’article original se trouve ici. Vous pouvez retrouver les différents articles de la série grâce aux mots-clefs.

Merci à Marine, Banban, Ilphrin et goofy pour la traduction et la relecture !


Lire la suite

- page 1 de 3