anchor.diff:  
   ## Débugage
   
  -Si vous rencontrez un problème CSS **relisez le code avant vous commencer à en 
  -ajouter encore plus** dans l'espoir de le corriger. Le problème existe en CSS et 
  +Si vous rencontrez un problème CSS **relisez le code avant vous commencer à en
  +ajouter encore plus** dans l'espoir de le corriger. Le problème existe en CSS et
   il est déjà écrit, ajouter plus de CSS n'est pas la bonne réponse !
   
  -Supprimez vos balises HTML et votre CSS jusqu'à ce que votre problème disparaîsse, 
  +Supprimez vos balises HTML et votre CSS jusqu'à ce que votre problème disparaîsse,
   ensuite vous pouvez déterminer quelle partie du code pose problème.
   
   Il peut être tentant de mettre `overflow: hidden;` pour cacher les effets
  -d'une bizarrerie de mise en page, mais `overflow` n'a probablement jamais été le 
  +d'une bizarrerie de mise en page, mais `overflow` n'a probablement jamais été le
   problème; **fixez le problème, et non ses symptômes.**
   
   ## Préprocesseurs
   
  -Sass is my preprocessor of choice. **Use it wisely.** Use Sass to make your CSS
  -more powerful but avoid nesting like the plague! Nest only when it would
  -actually be necessary in vanilla CSS, e.g.
  -
  -Sass est mon préprocesseur de choix. **Utilisez-le à bon escient.** Utiliser Sass 
  -pour rendre votre CSS plus puissant, mais évitez la spécification comme la peste ! 
  +Sass est mon préprocesseur de choix. **Utilisez-le à bon escient.** Utiliser Sass
  +pour rendre votre CSS plus puissant, mais évitez la spécification comme la peste !
   Spécifiez seulement si c'est réellement nécessaire à votre CSS, par exemple
   
       .header{}
       .header .site-nav{}
       .header .site-nav li{}
       .header .site-nav li a{}
  -
  -Would be wholly unnecessary in normal CSS, so the following would be **bad**
  -Sass:
   
   Serait tout à fait inutile dans des conditions normales CSS, le SASS est **mauvais** :
   
  
positive.code: 
  ## `!important`
  
  Il est correct d'utiliser `!important` sur des classes d'assistance uniquement. 
  Vous pouvez aussi faire de la prévention en ajoutant `!important`
  dans le cas où vous savez que la règle sera **toujours ** prioritaire, par exemple 
  `.error {color: red !important;}`.
  
  Utiliser `!important` pour sortir d'une situation périlleuse, n'est pas conseillé. Retravaillez votre CSS et essayez de lutter contre ces problèmes en
  [réusinant](http://fr.wikipedia.org/wiki/R%C3%A9usinage_de_code) vos sélecteurs. Garder vos sélecteurs courts en évitant les IDS vous 
  aidera énormément.
  
  ## Nombres magiques et absolus
  
  Un nombre magique est un nombre qui est utilisé parce que « ça fonctionne ». Ceux-ci 
  sont mauvais parce qu'ils travaillent rarement pour un motif réel et ne sont 
  généralement pas à l'épreuve du temps ou flexible. Ils ont tendance à fixer des 
  symptômes et non des problèmes.
  
  Par exemple, utiliser `.dropdown-nav li:hover ul{ top:37px; }` pour déplacer une liste déroulante avec `:hover` est mauvais, puisque 37px est un nombre magique. 37px grâce à un coup de chance puisque `.dropdown-nav` arrive à être 37px de hauteur.
  
  Au lieu de cela, vous devez utiliser `.dropdown-nav li:hover ul{ top:100%; }`. 
  quelque soit la hauteur de `.dropdown-nav`, dans la liste déroulante aura toujours 
  100% de déplacement par rapport à la hauteur.
  
  Chaque fois que vous codez en dur un certain nombre réfléchissez-y à deux fois, 
  si vous pouvez l'éviter en utilisant de mots-clés ou «alias» (`top: 100%` signifie 
  «tout le chemin depuis le sommet») ou &mdash;encore mieux&mdash; pas de mesures 
  du tout, alors vous devriez probablement.
  
  Chaque mesure codée en dur que vous définissez est un engagement que vous ne 
  pourriez pas nécessairement vouloir conserver.
  
  ## Styles conditionnel
  
  Les feuilles de style IE peuvent, généralement, être totalement évitées. La seule 
  fois où une feuille de style IE peut être nécessaire est de contourner le manque 
  flagrant de fonctionnalité (Une correction des PNG par exemple).
  
  En règle générale, toutes les règles de mise en page et le modèle de boîte _devraient_
  
negative.code: 
  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.
  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
  "rechercher et remplacer".
  
  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
  maîtrise de la langue de Shakespeare.
  
  ## Commentaires
  