[Résolu] le "coup de gueule" s'en est allé...

Hier, j'ai décidé de me mettre à Sass et Compass...

Depuis que j'en entend parler, cet outil formidable : gain de temps et productivité, css maintenables, etc. D'ailleurs j'avais lu un livre en rapport il y a un moment déjà.

Les exemples de code pour Sass fleurissent de partout, autant rattraper le train en marche avant qu'il ne soit trop tard... Et puis je peux démarrer à partir de mon css "old school". Alors pourquoi pas ? En réalité, c'est la maintenabilité de mon code pour IE8 qui m'a fait franchir le pas : j'en ai marre de reprendre tout mon code pour IE8, les unités rem en particulier...

Pas de souci pour l'installation. Création de deux fichiers dédiés sass et css... dans le premier j'installe et je transforme mes fichier .css en .scss, la compression s'effectue à la volée comme prévue. Cool ! Auparavant, avec Sublim text 2 il me fallait appuyer sur une touche. Je vais devenir un gros flemmard... Il ne me manquera plus que de configurer Ruby pour que mon navigateur prenne en compte les modifs en temps réel et tout sera très top. Mais... ???

Ha ! Déjà mon premier bug : à la compression, est interprété une fois sur deux l'opacité des rgba par... 0. Génial. Jamais rencontré un problème aussi idiot avec Sublim Text 2.

Il est vrais que je codais en "minifi" même dans la feuille de style principale, sans le zéro avant le point, ce qui n'a jamais posé de problème aux navigateurs. Allons-y pour une heure de copier/remplacer dans mes feuilles de style...

Argh ! Le compilateur ne comprend pas mieux la syntaxe normale. M....de ! Avant de me lancer dans les modifs j'aurais pu tester ! Déjà qu'il m'avait fallut presque une heure pour trouver le bug... Deux heures de perdues pour rien...

Bon, il faudra faire attention au résultat final à la compression des fichiers... Qu'en est-il du côté de l'assistance du codage en css3 ? J'ai été échaudé, maintenant je vais tout tester : Allons-y pour la propriété border-radius dont, perso, je n'utilise plus le préfixage dans mes feuilles de style. Alourdissement inutile s'y j'en crois caniuse. Mais bon, c'est juste pour un test "simple" :

@import "compass/css3";

.btn {
    @include border-radius(10px);
}

Et maintenant je vais voir le résultat et... quoi !!! ??? :

.btn{-webkit-border-radius:10px;-moz-border-radius:10px;-ms-border-radius:10px;-o-border-radius:10px;border-radius:10px}

Tout les préfixes ! Alors que -ms-, -o- n'ont jamais eu lieu d'être ! Pour pondre une telle bêtise je n'avais pas besoin d'un préprocesseur !

Edit de 16h47 : Pour l'exemple ci dessus, ils ont du pondre une mixin généraliste du genre (trouvée sur CSSTricks) :

@mixin vendorize($property, $value) {
	-webkit-#{$property}: $value;
	-moz-#{$property}: $value;
	-ms-#{$property}: $value;
	-o-#{$property}: $value;
	#{$property}: $value;
}

Ok : je me passerais donc du support de css3 par compass...

Je comprend mieux maintenant la prolifération des codes non optimisés que je trouve sur Codepen ou sur CSS-Tricks. Sans parler des sursélections bien sûr. À ce rythme là il ne va pas rester de gros avantages à utiliser un préprocesseur...

- Les variables pour les couleurs par exemples ? Ouais bon : en copier/remplacer ça me prenais 10 secondes, donc bof...
- Vu qu'il faut contrôler le code de sortie, on oublie l'argument "gain de temps et productivité"...

Heureusement, il me reste les @mixin, @extend et @import à tester, et ces propriétés ont l'air intéressantes. Allons-y pour de nouvelles aventures...

Edit de 16h47 : je pense avoir trouvé la raison de la corruption aléatoire des fichiers css finaux : l'utilisation du compilateur Scout. Du coup, exit Scout, passage en ligne de commande :

$ sass --watch sass:css

Et hop! Miracle ! Plus de bugs !
Modifié par Olivier C (20 Jan 2014 - 23:41)

Salut,

Je suis étonné que l'on parle du mal de Compass et Sass. Perso, je l'utilise régulièrement et pas de réel souci. Par contre en ce qui concerne Scout, il n'a jamais fonctionné correctement chez moi (bug; bug et encore bug....). Je fais tout en ligne commande ou j'utilise un exécutable.
Modifié par niuxe (19 Jan 2014 - 18:09)

Au fond, ma "réflexion" reflète beaucoup de commentaires que j'ai pu lire à droite ou... encore à droite.

Je ne dit pas que les préprocesseurs sont inintéressant : depuis ce matin où j'ai écrit le premier message de ce topic j'ai passé la journée à factoriser mes fichiers à grand coup de mixins.

Mais bon, en regard d'un Sublim Text bien configuré et plugué (supplétition automatique des préfixes, minification, recherche facilité des occurrences, etc), j'ai du mal à en voir l'intérêt...

Je vais quand même m'y coller, car je ne me fait pas d'illusion : les préprocesseurs sont l'avenir. Un jour les fichiers sass, less et consorts seront directement interprétables par les navigateurs. J'en donne ma main au feu. Comme je le disais plus haut : autant prendre le train en marche avant qu'il ne soit à pleine vitesse.

C'est bon : je suis conquis à jamais par les préprocesseurs, le "coup de gueule" s'en est allé...

J'ai tiré parti de la bête... genre : codage en unité px pour IE8 et en rem pour le reste du monde, sans fallback dans la feuille principale. Et tout ça sans devoir plus jamais retoucher une feuille de style ie.css "à la main" (par contre, tant pis pour le support Opéra mini, de toute façon ce navigateur n'est compatible avec rien...). Merci SASS !

Mais je suis aussi heureux de ne pas m'être trop vite mis aux préprocesseurs. Sinon j'aurais sûrement succombé moi aussi à la facilité qu'offre ce fabuleux outil... en produisant un code horrible si l'on-y prend garde...
Modifié par Olivier C (20 Jan 2014 - 23:41)

Salut,

Olivier C a écrit :
J'ai tiré parti de la bête... genre : codage en unité px pour IE8 et en rem pour le reste du monde, sans fallback dans la feuille principale. Et tout ça sans devoir plus jamais retoucher une feuille de style ie.css "à la main" (par contre, tant pis pour le support Opéra mini, de toute façon ce navigateur n'est compatible avec rien...).

Il y a toujours moyen de servir la compatibilité avec Opera Mini. Pour ma part, pour le fallback rem / em, je me suis créé une fonction Sass réutilisable dans des mixins, comme suit (je reproduis le code de mémoire) :

@function pixel-em ($valeur, $reference: 10) {
  @return #{$valeur / $reference}em; // Une fonction pratique pour convertir les pixels en em, en tenant compte de la taille de référence
}
@mixin font-size ($valeur, $reference: 10) {
  font-size: pixel-em($valeur, $reference); // IE 8- et Opera Mini
  font-size: #{$valeur / 10}rem; // Navigateurs récents
}

Merci à toi Victor,

Si tu veux bien :

Il me reste un point assez bête à résoudre pour être réellement opérationnel : Avec Scout, je pouvais compresser les fichiers à la volée (même si je rencontrais des bugs), je n'ai pas réussi à reproduire cet effet en ligne de commande...

Pour la surveillance des fichiers et transformation scss -> css à la volée, ok :

$ sass --watch sass:css

Mais pour ajouter l'option de compression, je cale. J'ai vu l'option dans la doc : :compressed, mais je n'arrive pas à savoir ce que je dois taper concrètement dans le terminal...

C'est très simple :

sass --watch sass:css -t compressed

Sachant que si tu souhaites contrôler la génération des CSS, tu peux remplacer compressed par expanded (pour obtenir des CSS aérées, indentées et commentées).

Pour connaître les commandes Sass, rien de mieux qu'un

sass -h

ou

sass --help

Génial ! Merci pour ton aide Victor. Tu m'as bien aiguillé.

Édit :

- J'ai pu accomplir un vieux rêve. Une feuille entièrement codé en unité relative, servie en px pour IE8, et tout cela avec un minimum d'effort.

- Tout mon code css a été divisé en _bundles, appelé dans la feuille de style principale via @import de Sass. Il suffit de commenter ou non les règles en fonction des besoins. Je le faisais déjà avec mon ancien code, mais c'était beaucoup moins élégant.
Modifié par Olivier C (22 Jan 2014 - 08:02)

Salut.

Après avoir été un peu dubitatif avec les préprocesseurs je donne la raison qui a pour moi fait pencher la balance (suite à un commentaire de Raphaël ici) :

Il n'y a pas vraiment de fonctionnalité déterminante chez un préprocesseur que ne fait pas un bon éditeur de texte bien configuré (minification du style à la volée, préfixage automatique, etc).

SAUF QUE :

À la moindre mise à jour d'un de mes modules css, SASS me permet de mettre à jour toutes mes feuilles de style, pour tous mes thèmes, pour toutes mes versions dédiées aux différents navigateurs.

Alors qu'avant, pour la même opération, cela me demandait pas mal de manips de configuration. Aujourd'hui je n'ai plus à m'en soucier, la config est décidée en début de projet une fois pour toute (quel feuille partielle doit être chargée ou non, etc).

C'est cela qui pour moi a été déterminant pour pencher vers un préprocesseur.
Modifié par Olivier C (02 Mar 2014 - 08:50)