anchor.diff:  
   En dépit d'être un développeur Anglais, je passe ma vie à écrire <i>colour</i>
   au lieu de <i>color</i> Je pense que, dans un souci de cohérence, il est préférable
  -d'utiliser toujours un anglais Américain en CSS. CSS, comme avec la plupart 
  -(sinon tous) les autres langages, est écrit en anglais-US. Mélanger une syntaxe 
  -`color: red;` avec des classes comme `.colour-picker{}` peut manquer de cohérence. 
  +d'utiliser toujours un anglais Américain en CSS. CSS, comme avec la plupart
  +(sinon tous) les autres langages, est écrit en anglais-US. Mélanger une syntaxe
  +`color: red;` avec des classes comme `.colour-picker{}` peut manquer de cohérence.
   J'ai déjà proposé et défendu une écriture des classes bilingues,
   
       .color-picker,
       .colour-picker{
       }
   
  -Cependant, après avoir récemment travaillé sur un projet de grande envergure en 
  -Sass où il y avait des dizaines de variables de couleur (par exemple `$brand-color`, 
  -`$highlight-color` etc.), maintenir deux versions de chaque variable est vite devenu 
  -ennuyeux. Cela signifie également deux fois plus de travail avec des choses comme 
  +Cependant, après avoir récemment travaillé sur un projet de grande envergure en
  +Sass où il y avait des dizaines de variables de couleur (par exemple `$brand-color`,
  +`$highlight-color` etc.), maintenir deux versions de chaque variable est vite devenu
  +ennuyeux. Cela signifie également deux fois plus de travail avec des choses comme
   "rechercher et remplacer".
   
  -Dans un souci de cohérence, nommez toujours vos classes et vos variables dans les 
  +Dans un souci de cohérence, nommez toujours vos classes et vos variables dans les
   paramètres régionaux de la langue que vous utilisez.
   
  -Vous pouvez aussi vous mettre d'accord avec votre équipe de développement pour 
  -n'utiliser que de l'anglais pour vos projets. Cela vous permettra d'améliorer votre 
  +Vous pouvez aussi vous mettre d'accord avec votre équipe de développement pour
  +n'utiliser que de l'anglais pour vos projets. Cela vous permettra d'améliorer votre
   maîtrise de la langue de Shakespeare.
   
   ## Commentaires
  
positive.code: ## Anatomie d'un document CSS
  
  Peu importe le document, il faut toujours essayer de garder un formatage commun. 
  Cela signifie une cohérence des commentaires, de la syntaxe et des règles de nommage.
  
  ### Généralités
  
  Limitez vos feuilles de style avec un maximum de 80 caractères de longeur lorsque 
  cela est possible. Des exceptions peuvent être la syntaxe des dégradés ainsi que 
  les URL dans les commentaires. Il n'y a rien que nous puissions faire à ce sujet.
  
  Concernant l'indentation je préfère 2 espaces au lieu des tabulations et écrire 
  sur plusieures lignes CSS.
  
  ### Un seul fichier ou plusieurs fichiers ?
  
negative.code:  _est_ lié à un composant, c'est un enfant du constructeur `.widget`.
  Nous devrions renommer cette classe `.widget__heading`.
  
  La notation BEM est un peu laide, plus verbeuse, mais elle nous donne beaucoup
  plus de pouvoir dans le glanage d'informations sur les fonctions et sur les
  relations entre les éléments, uniquement avec leurs nom de classes. En outre, la
  syntaxe BEM sera généralement très bien compressée (gzip) puisqu'elle favorise /
  fonctionne bien avec la répétition.
  
  Peu importe si vous avez besoin d'utiliser BEM ou non, assurez-vous de toujours
  nommer vos classes judicieusement; garder un nom aussi court que possible, mais
  aussi long que nécessaire. S'assurer que les objets ou les abstractions sont très
  vaguement nommées (par exemple `.ui-list`, `.media`) pour permettre une meilleure
  réutilisation. Les extensions des objets devraient être nommées beaucoup plus
  explicitement (par exemple `.user-avatar-link`). Ne vous inquiétez pas du montant
  ou de la taille de vos classes; gzip compresse le code bien écrit _incroyablement_
  bien.
  
  ### Classes en HTML
  