Utilisez-vous les frameworks et les compilateurs CSS ? N'essayent-ils pas de changer sa nature ?

[Idelways]

Utilisez-vous les compilateurs CSS ?
N'essayent-ils pas de changer la nature du langage de mise en forme ?



Bien qu'il soit relativement aisé (comparé à d'autres technologies Web) de créer ses feuilles de style en cascade (CSS), les solutions qui permettent d'optimiser et de faciliter la vie des intégrateurs se multiplient. Mais elles ne font pas l'unanimité parmi les développeurs Web.

En plus des frameworks, qui facilitent l'intégration mais imposent une architecture "grillagée" aux équipes qui les adoptent, les « compilateurs CSS » qui intègrent les notions de variables, mixins, héritages ou imbrication des sélecteurs font de plus en plus de bruit.

Si certains d'entre eux, comme Sass (précurseur des langages de feuille de style issus de l'écosystème Ruby) changent considérablement de syntaxe, d'autres, comme « Less » reprennent la syntaxe de CSS en y ajoutant, d'une manière plutôt naturelle, ce que leurs développeurs qualifient de "fonctionnalités manquantes" à ce standards Web.

Ce qui soulève des interrogations. Ces fonctionnalités « manquantes » (variables, mixins...) devraient-elles, selon-vous, être intégrées aux prochaines spécifications de CSS ? Ou leur ajout n'a pas, conceptuellement, lieu d'être dans ce qui reste après tout un langage de mise en forme, pas de programmation.

En tout cas le W3C fait la sourde oreille à ces techniques.

A vous de nous dire si c'est à tort ou à raison.


Et vous ?

Utilisez-vous des frameworks, compilateurs ou langages CSS ?
Comment voyez-vous l'avenir de CSS ?

En collaboration avec Gordon Fowler

[Kurashi]

L'ajout de variables serait vraiment bénéfique dans le sens où il permettrait une plus grande flexibilité et un maintenance aisée. Être obligé de passer par un langage serveur pour générer des variables est un peu pénible. Après, il ne faudrait pas non plus que CSS devienne une usine à gaz, mais qu'il se contente d'offrir les possibilités basiques mais intéressantes pour son utilisation et sa maintenance. M'enfin, ce n'est pas si nouveau cette histoire, si ?

Sinon, pas de compilateur CSS pour moi, je suis peut-être vieux jeu mais je préfère encore faire "à la main"

[camus3]

C'est comme les compilateurs javascripts différents développeurs viennent de différents environnements et ont différents besoins ou contraintes.
Entre développer directement en javascript ou utiliser un cross compilator chez moi ya pas photo. Cela ne change pas pour autant la nature de javascript.
Idem pour les compilateurs CSS ou les frameworks, au final on obtient une feuille de style , peu importe comment elle est générée.
Si un besoin existe pour ces outils, c'est aussi peut être parce que l'architecture même du front end html/css/javascript est mal conçue.
Il est temps de réinventer le web.Non pas en le transformant en flash bis mais en trouvant un moyen "d'abstraire" les standards en donnant du choix au développeurs sur le client comme sur le serveur.

[cahnory]

À la question si ça doit ou non être ajouté à CSS je me garderai bien de répondre. C'est tentant (en tout cas pour LESS car je n'ai testé que lui dans sa version PHP).

J'utilise personnellement LESS PHP et si ce n'est pas parfait ça permet de gagner pas mal de temps et de bien s'organiser. L'indentation sur plusieurs profondeurs réduit la lisibilité, mais en même temps, si mon éditeur prenait bien en charge ce format j'aurai une meilleur visibilité dans le code navigator (sorte de sommaire sous Panic Coda).

Il y a quelque fois où j'aurai pu me retrouver coincé mais, de la façon dont je l'utilise je peux retravailler les fichiers générés et donc repasser en "mode*normal".

Concernant l'avenir de CSS je dirait une dépendance diminué entre le code HTML et son rendu visuel via CSS. En gros de moins en moins d'élément html qui n'ont pour vocation que d'habiller la page et non présenter du contenu. De plus en plus de possibilités d'animations ne laissant à javascript "plus que" le soin de déclancher des évènements (je raccourci).

Ce qui donnerai un vrai HTML/présentation, CSS/mise en forme, JS/évènement.

[gilwath]

Le css en lui même doit rester comme il est. Mais je pense que les frameworks css par contre peut être un plus, comme l'est n'importe quel framework ( mvc si on reste dans le web ). D'ailleurs j'aimerais connaitre quelque bon framework css écrit en php( parce que Less et Sass sont à la base implémentais en ruby et que Sass est lié au haml).

[cahnory]

Comme je le dit plus haut il y a LESSPHP mais même si ça se révèle pratique, ce n'est pas encore LA solution tant attendu... un exemple tout con, on peu créer des fonctions, donc au début c'est génial puis dés que l'on veut y ajouter un peu de logique faut repasser. Pour moi la solution idéale sera une espèce de LESSPHP permettant l'utilisation de code php au sein du doc (ou à minima des fonctions).

[ricardo_bresil]

Bonjour à tous,

Moi je dis oui à ces framework, ça aide vraiment pour la maintenance et la productivité, j'utilise en plus le framework css 960 pour le positionnement et sass.

En plus sass avec Play Framework et son plugin sass c'est vraiment trop facile. Le plugin s'occupe de compiler le bazar automatiquement

[jpvincent]

générer du CSS, l'idée m'a l'air vraiment bien : ça rajoute de la flexibilité, et comme tout code si il est bien fait, ça va améliorer la maintenance

les mixins et les variables font vraiment partie de ce que je voudrais avoir comme outils de base. Par contre si on va trop loin dans les niveaux d'abstraction, on va se retrouver avec le même problème que jQuery et Javascript : ceux qui commencent par manipuler les couches hautes vont avoir du mal à rentrer dans les détails par la suite

quant à rajouter ça à la spec CSS, le W3 le fera surement de lui même si l'usage se répand... Puis prévoir 5 ans de specs ... Puis 10 ans avant de l'utiliser en production

[Camille_B]

Très franchement l'utilisation de LESS m'a changé la vie.

J'ai d'ailleurs écris un petit plugin pour SPIP facilitant le développement avec LESSphp :

http://www.spip-contrib.net/CSS-facile-avec-LESSpip

[cahnory]

Pour ceux qui utiliseraient (ou souhaiteraient utiliser) LESSPHP je me suis fait une petite feuille de fonction facilitant l'utilisation de propriété css3 :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
/* CSS3 */
@backgroundClip(@box:border-box) {
	 -o-background-clip: @box;
   -moz-background-clip: @box;
 -khtml-background-size: @box;
-webkit-background-clip: @box;
		background-clip: @box;
}
@backgroundOrigin(@box:padding-box) {
	 -o-background-origin: @box;
   -moz-background-origin: @box;
 -khtml-background-origin: @box;
-webkit-background-origin: @box;
		background-origin: @box;
}
@backgroundSize(@size:auto) {
	 -o-background-size: @size;
   -moz-background-size: @size;
 -khtml-background-size: @size;
-webkit-background-size: @size;
		background-size: @size;
}

/*	borderRadius
 *	
 *	Works on:	Chrome, FireFox 3.5+, Internet Explorer 9.0, Opera 10.5, Safari 3.0+
 *	Needs test:	Konqueror
 *
 */
@borderRadius(@tl: .5em; @tr: @tl; @br: @tl; @bl: @tr;    @p_tl; @p_tr: @p_tl; @p_br: @p_tl; @p_bl: @p_tr; ) {
	 -webkit-border-top-left-radius: @tl @p_tl;
	-webkit-border-top-right-radius: @tr @p_tr;
 -webkit-border-bottom-right-radius: @br @p_br;
  -webkit-border-bottom-left-radius: @bl @p_bl;
  
	  -khtml-border-top-left-radius: @tl @p_tl;
	 -khtml-border-top-right-radius: @tr @p_tr;
  -khtml-border-bottom-right-radius: @br @p_br;
   -khtml-border-bottom-left-radius: @bl @p_bl;
  
		 -moz-border-radius-topleft: @tl @p_tl;
		-moz-border-radius-topright: @tr @p_tr;
	 -moz-border-radius-bottomright: @br @p_br;
	  -moz-border-radius-bottomleft: @bl @p_bl;
	  
			 border-top-left-radius: @tl @p_tl;
			border-top-right-radius: @tr @p_tr;
		 border-bottom-right-radius: @br @p_br;
		  border-bottom-left-radius: @bl @p_bl;
	
}

/*	boxShadow
 *	
 *	Works on:	Chrome, FireFox 3.5+, Internet Explorer 9.0, Opera 10.5, Safari 3.0+
 *	Needs test:	Konqueror
 *
 */
 @boxShadow(@shadow) {
	   -o-box-shadow: @shadow;
     -moz-box-shadow: @shadow;
   -khtml-box-shadow: @shadow;
  -webkit-box-shadow: @shadow;
          box-shadow: @shadow;
 }
@dropShadow(@x:0; @y:1px; @blur:2px; @spread:0; @color:#000) {
	@boxShadow(@x @y @blur @spread @color);
}
@insetShadow(@x:0; @y:1px; @blur:2px; @spread:0; @color:#000) {	
	@boxShadow(inset @x @y @blur @spread @color);
}
@rotate(@deg: -22deg) {
       -o-transform: rotate(@deg);
     -moz-transform: rotate(@deg);
   -khtml-transform: rotate(@deg);
  -webkit-transform: rotate(@deg);
}

/*	transition
 *	
 *	Works on:	Chrome, FireFox 3.7+, Opera 10.5, Safari 3.2+
 *	Needs test:	Konqueror
 *
 *	@property	none | all | [property]*
 *	@duration	[time]*
 *	@function	[ease | linear | ease-in | ease-out | ease-in-out | cubic-bezier(<number>, <number>, <number>, <number>)]*
 *	@delay	[time]*
 *
 */
@transition(@property: all; @duration: .4s; @function; @delay: 0;) {
	     -webkit-transition-property: @property;
  		 -webkit-transition-duration: @duration;
  -webkit-transition-timing-function: @function;
		  	-webkit-transition-delay: @delay;
		  	
	      -khtml-transition-property: @property;
  		  -khtml-transition-duration: @duration;
   -khtml-transition-timing-function: @function;
		  	 -khtml-transition-delay: @delay;
		  	 
			-moz-transition-property: @property;
			-moz-transition-duration: @duration;
	 -moz-transition-timing-function: @function;
			   -moz-transition-delay: @delay;
		  	 
			  -o-transition-property: @property;
			  -o-transition-duration: @duration;
	   -o-transition-timing-function: @function;
				 -o-transition-delay: @delay;
		  	
				 transition-property: @property;
				 transition-duration: @duration;
		  transition-timing-function: @function;
					transition-delay: @delay;
}
@verticalGradient(@top: #FFF; @bottom: #000) {
			  @gap: ((@bottom - @top) + (@top - @bottom));
			 @base: @bottom - (@bottom - @top);
			 
  background-color: @gap / 2 + @base;
  background-image: -moz-linear-gradient(top, @top, @bottom);
  background-image: -webkit-gradient(linear,left top,left bottom,color-stop(0, @top),color-stop(1, @bottom));
            filter:  progid:DXImageTransform.Microsoft.gradient(startColorStr=@top, EndColorStr=@bottom);
        -ms-filter:  progid:DXImageTransform.Microsoft.gradient(startColorStr=@top, EndColorStr=@bottom);
}
@horizontalGradient(@left: #FFF; @right: #000) {
			  @gap: ((@right - @left) + (@left - @right));
			 @base: @right - (@right - @left);
			 
  background-color: @gap / 2 + @base;
  background-image: -moz-linear-gradient(left, @left, @right);
  background-image: -webkit-gradient(linear,left top,right top,color-stop(0, @left),color-stop(1, @right));
            filter:  progid:DXImageTransform.Microsoft.gradient(StartColorStr=@left, EndColorStr=@right, GradientType=1);
        -ms-filter:  progid:DXImageTransform.Microsoft.gradient(StartColorStr=@left, EndColorStr=@right, GradientType=1);
}

[barmic]

Je suis d'accord avec camus3, les techno directement utilisables sur le client sont absolument pas fait pour ce qu'on leur demande de faire et je pense franchement que ce n'est pas en les faisant évoluer que l'on va arriver à une bonne solution. Quand on vois les développement actuels quasiment tout passe par des framework, quasiment personne dans le monde professionnel ne veut avoir à écrire son HTML à la main, il suffit de voir le succès de GWT pour s'en rendre compte.

Pour ce qui est des CSS, je suis d'accord pour dire qui leur manque des notions que je trouve importantes comme la dérivation de classe et la déclaration de couleur par exemple.

[cahnory]

barmic, qu'entends tu par "la déclaration de couleur" ? Pour ce qui est du html faut pas non plus être caricatural, je pense que beaucoup de gens continues de coder à la main leur html, on essaie parcontre d'éviter de retaper plusieurs fois un même code via des systèmes de template (en pur php pour ma part).
Les seules éléments que, personnellement, je préfère laisser généré par script ce sont les formulaires (pour le moment une classe acceptant une définition au format json).

[__fabrice]

Oui, effectivement, la pseudo OOP avec CSS est une petite révolution.

LESSCSS est vraiment une trouvaille qui permet d'organiser son code, de le ré-utiliser facilement pour divers projets. On peut également coder avec des grids, voir ici


Fabrice

[H.Pascal]

Je risque de passer pour un idiot, mais j'ignorais complètement l'existence de "compilateur CSS". Encore une fois de plus, je me coucherais moins bête ce soir.
J'ai un peu du mal à imaginer le CSS en tant que "langage de programmation", avec des variables et héritages.
Ce serait vraiment compliquer les choses je pense, on passe d'un langage de "mise en forme" à un langage de "programmation".
Personnellement je préfère largement le CSS dans sa nature actuelle et le coder à la main, ce langage est vraiment trop simple, pas besoin de tout ça, mais ce n'est que mon avis.

[cahnory]

C'est en ça que ces solutions sont bonnes, elles ne modifient en rien la syntaxe de css et génère du css tout à fait standard. C'est un plus pour les dev qui n'altère en rien le langage. Une surcouche confortable.
Parcontre peut importe la solution elle doit être coté serveur, je ne comprend pas qu'on puisse utiliser LESSJS par exemple qui fait payer au visiteur (sans js, pas de génération du css) le confort du développeur.