Ça m’a fait sourire. On a tous eu notre période Sass : mixins partout, variables, nesting à outrance. C’était grisant, ça donnait l’impression d’être plus « pro ». Mais le temps passe, le CSS a grandi, et beaucoup de ces artifices ne servent plus à grand-chose.

L’article raconte ce cheminement : désapprendre Sass pour réapprendre le CSS brut. Pas comme une régression, mais comme un gain de clarté. Quand tu enlèves la couche intermédiaire, tu te rends compte que ton code respire mieux, que le navigateur fait déjà pas mal de choses tout seul.

Ça m’a fait réfléchir à ma propre boîte à outils. On accumule, on optimise, on complexifie… et puis un jour on redécouvre que la simplicité, c’est aussi une forme de puissance. Peut-être qu’au fond, le vrai luxe en dev, c’est d’avoir moins à maintenir.

Un rappel utile : parfois, coder mieux, c’est surtout coder moins.

Qu’est-ce que l’imbrication de propriétés composites ?

On sait déjà que les pré-processeurs comme Sass permettent d’écrire des règles CSS imbriquées, ce qui permet d’éviter les répétitions mais aussi de coller à la structure du code HTML.

L’imbrication des propriétés composites permet de faire la même chose avec certaines propriétés CSS composées d’un prefixe, comme par exemple toutes les règles d’arrière-plan (background-color, background-image, etc) ou de polices d’écriture (font-size, font-style, etc.). Voilà à quoi ça ressemble en pratique :

See the Pen Imbrications de propriétés by Ange Chierchia (@nighcrawl) on CodePen.

Cette astuce fonctionnera avec toutes les propriétés composées d’un prefixe (margin, padding, border, background, font, etc.).

Bonne journée !

Ma grille de mise en page consistait en six colonnes et des gouttières de 20 pixels entre chaque et un conteneur de 1000 pixels de large. Afin de toujours me laisser le choix de partir sur un nombre de colonne différent, la largeur de colonne est calculée en fonction des autres variables. Voici ce que ça donne :

$columns: 6;
$gutter-width: 20px;
$container-width: 1000px;
$column-width: ($container-width - (($columns - 1) * $gutter-width))/$columns;

Mon interface devant être adaptée pour ordinateurs et tablettes, j’ai préféré utiliser les pourcentages plutôt que les pixels pour définir la taille de mon conteneur et de mes gouttières. Pour ce faire, je n’ai pas eu besoin de toucher à ma grille (que l’on verra plus tard), seulement à mes variables $gutter-width et $container-width que j’ai passé à 2% et 100%, respectivement.

Une fois mes différentes variable instanciées, j’ai pu créer les différentes colonnes de ma grille de mise en page avec une boucle @for comme celle-ci :

@for $i from 1 through $columns {
  .col-#{$i}-of-#{$columns} {
    width: ($i * $column-width) + (($i - 1) * $gutter-width);
  }
}

Une fois compilé, j’obtiens les règles CSS suivantes qui définissent la taille pour chaque colonne de la grille :

.col-1-of-6 {
  width: 15%;
}

.col-2-of-6 {
  width: 32%;
}

.col-3-of-6 {
  width: 49%;
}

.col-4-of-6 {
  width: 66%;
}

.col-5-of-6 {
  width: 83%;
}

.col-6-of-6 {
  width: 100%;
}

Pour que toutes les colonnes de ma grille de mise en page partagent les mêmes styles, je défini une classe .column que j’ajouterai à chaque bloc ayant une classe .col-X-of-6 :

.column {
  box-sizing: border-box;
  display: block;
  float: left;
  margin-right: $gutter-width;
  position: relative;
}

Une fois mes classes prévue pour les colonnes de ma grille terminées, il me reste à définir une classe .row qui contiendra au maximum six blocs .column.col-X-of-6, ainsi que ma classe .wrapper qui englobera le tout. voilà ce que ça donne :

.wrapper {
  width: $container-width;
}

.row {
  margin: 0 0 $gutter-width;

  &:before,
  &:after {
    clear: both;
    content: "";
    display: table;
  }
}

Afin que mes blocs .column restent bien dans leur « ligne » ( classe .row), il faut réinitialiser le flux avec les pseudo-classe :before et :after afin de garantir qu’aucun bloc .column ne sorte de son bloc .row parent.

Tout est presque bon maintenant. Nos colonnes ayant toutes une marge de droite défini, la dernière colonne de chaque ligne ne sera pas bien alignée avec ses soeurs. Pour remédier à ce problème, il suffit de passer la valeur de margin-right à «  pour le dernier bloc .column contenu dans un bloc .row. Vous me suivez ?

.column {
  /* nos règles précédentes */

  .row &:last-of-type {
    margin-right: 0;
  }
}

Le tour est joué, on a construit notre propre grille de mise en page CSS en toute simplicité avec Sass. Voilà le résultat !

See the Pen OyBPEm by Ange Chierchia (@nighcrawl) on CodePen.

J’espère que cet article assez basique sur la création d’une grille de mise en page avec Sass vous aura plu. À bientôt !

À l’époque je n’avais testé que LESS, que je trouvais beaucoup plus accessible, moins compliqué à mettre en place en fait. J’avais aussi acheté le bouquin de Kaelig, CSS maintenables, que je n’ai d’ailleurs toujours pas commencé, trop occupé à lire Cinquantes nuances de Grey et autres Walking Dead …

Et puis aux alentour de la mi-juillet 2013, j’ai eu en charge la conception d’une plateforme intranet pour l’association luxembourgeoise Arcus asbl. Le projet était tellement conséquent que je me suis dis que j’avais peut-être enfin l’occasion me faire la main sur un pré-processeur CSS. L’année précédente, nous avions déjà conçu le site internet et avec le recul, vu la feuille de style, on aurait déjà pu utiliser un pré-processeur, ne serait-ce que pour avoir une meilleure organisation des règles CSS et les rendre encore plus maintenables.

L’arrivée de ce nouveau projet était donc le moment idéal pour vraiment me mettre aux pré-processeurs CSS. La première fois que j’ai eu l’occasion de jouer avec un pré-processeur CSS, je m’était arrêté sur LESS que je trouvais moins difficile à mettre en place à l’époque puisqu’on pouvait l’utiliser sans installer Node.js (ou Ruby pour Sass)  ni utiliser la ligne de commande pour compiler les feuilles de styles. Un simple fichier JavaScript à ajouté et c’était fini ! malheureusement je n’avais pas du tout accroché.

Je décidais donc que cette fois-ci, il était temps de sauter le pas ! Je me suis tourné vers Sass, qui m’avait un peu fait peur à cause de sa mise en place, que je trouvais fastidieuse à l’époque (obligation d’installer Ruby, installation via ligne de commande, etc.).

Et je ne regrette pas du tout d’avoir sauté le pas ! Utiliser un pré-processeur CSS a permis à mes feuilles de styles de gagner en lisibilité, d’être plus facile et plus rapide à modifier et surtout mieux structurées, ce qui me permet de générer plusieurs feuilles de styles partageant des règles communes, sans pour autant réécrire une seule ligne. Pratique.

Ces derniers temps j’ai notamment utilisé Sass et Compass afin de générer les feuilles de styles des différents templates d’impression utilisés dans notre application IBAKUS®KYC.

Si, comme moi à l’époque, vous êtes réticent à utiliser un pré-processeur CSS, essayez Sass et Compass sur un projet d’assez grande envergure, si vous en avez l’occasion, vous verrez qu’il vous simplifierons grandement la tâche.

Je pense d’ailleurs publier ici quelques petits trucs et astuces concernant Sass dans les prochaines semaines, histoire de relancer un peu le bousin.

Ça n’engage que moi, mais je ne vois pas, à l’heure actuelle, ce que pourrait m’apporter de tels outils. D’accord, on a la possibilité de créer des semblants de fonctions afin d’éviter de  répéter 1000 fois une propriété CSS3 qui n’est pas nativement interprétée par tous les navigateurs.

Mais franchement, en 2012 a-t-on vraiment envie de s’embêter avec les IE 6-8 et autres navigateurs d’anciennes générations ? Et puis même, il y a de très bons outils qui font ça pour nous, si vraiment on veut s’embêter—notamment Prefix free de Lea Verou ou encore Prefixr.

Là où je vois l’intérêt d’un tel outil, c’est pour une famille de sites—du style du réseau Tut+—lorsque le design reste le même et que seul le code couleur change. Ça leur permet effectivement de gagner un temps fou. Je ne sais pas pour vous, mais chaque site Web que je conçois a une « mise en page » qui lui est propre. Mais même ici, si vous avez l’éditeur de texte qui va bien, un simple « chercher/remplacer » fera très bien le boulot.

Bref. En écrivant ce petit billet, j’attends surtout vos avis sur de tels outils. Dans quelle mesure utilisez vous un pré-processeur CSS ? N’avez vous pas peur d’oublier comment écrire de vraies CSS avec ces nouvelles syntaxes, à l’instar de jQuery pour le JavaScript ?