Discussion :

[Arkante]

Bonjour,

UPDATE : Mon explication dans ce post ne semblait pas assez clair, je l'ai donc refaite : cf ce post plus bas. Ne prenez pas en compte ce qui est en citation dans ce post. Merci

J'essaye de revoir ma manière d'utiliser le css pour l'améliorer. Je suis preneur de tout avis, de tout commentaire et si vous avez des liens ou projets qui ressemblent à ce que je veux, merci de partager.

Ce que je cherche c'est le meilleur compromis entre :
- performance (serveur)
- puissance (fonctionnalités)
- respect des standards
- travail d'équipe efficace (incluant des développeurs et des non développeurs)

Performance
Sélecteurs :
Simplifier les sélecteurs selon ces recommandations (notamment prendre en compte la lecteur droite-gauche des sélecteurs).
http://www.stevesouders.com/blog/200...css-selectors/
https://developer.mozilla.org/en/Writing_Efficient_CSS

Compression
Script qui parse le css en le réduisant (réunit les fichiers en un plus efface les espaces et commentaires). exemple : CSS Tidy

Cache
Comment gérer la mise en cache d'un fichier css de manière efficace?

Pour faire savoir qu'un fichier a été mis à jour par exemple, j'ai trouvé une astuce qui consiste a passer des variables GET bidons après le nom du fichier css (style.css?v=1) pour faire croire que c'est un nouveau fichier. Vous en pensez quoi ?


Puissance
Là j'ai regardé des choses comme SASS pour Ruby. Ou encore ca. Ca donne une bonne idée de la puissance que l'on peut donner au css. On peut enrichir le css d'une couche logique.

La grosse limite étant que pour quelqu'un qui ne développe pas, c'est très obscur. De plus, est-ce performant ? La différence est-elle notable par rapport à un fichier css simple ?

Ainsi, selon vous quelle serait le plus performant entre :

1. Un surcouche qui parse le css en production (l'utilisateur final charge un css dynamique). Possibilité de caching ?
2. Une surcouche juste pour faciliter le développement (incluant les mêmes fonctions que le précédant) mais qui génère au final un css propre en production. (l'utilisateur final charge un css statique).

Est-ce que vérifier si le fichier css demandé existe avant de le charger est lourd de conséquence en performance ? L'idée étant de savoir s'il est plus rentable de générer tout le tps le css ou de créer plusieurs css au gré de demandes des utilisateurs. Par exemple (bidon), un site qui pourrait changé de couleur, si une couleur n'a jamais été demandée le css est créé. Ca commence à faire bcp de fichiers css (000.css, fff.css, 010101.css ...).


Respect des standards
Un article qui illustre bien la question :
http://jeffcroft.com/blog/2009/may/2...-concepts-css/

Faut-il utiliser des ID sémantiques ? Alors deux possibilités :

1. Si css seul (sans surcouche PHP) : Répétition de code css entre deux éléments d'id différente mais de styles proches
2. Si css avec PHP : possibilité d'associer un ID à des styles (cf l'article cité précédemment)

Faut-il utiliser des classes, qui perdent du coup en sémantique. Voir ca et ca.


Travail d'équipe efficace
C'est à peu près évident que c'est l'OOCSS (je sais que ce n'est pas de l'OO mais bon) qui l'emporte non ?

Merci beaucoup à tous ceux qui prendront le temps de m'aider.

[Xunil]

Je ne vais pas répondre à tout, mais bon..

Performance ?
Moi pas avoir bien saisi le rapport entre performance et fichier css

Un fichier css n'est rien d'autres qu'un fichier texte et généralement très léger en poids, et le faire interpréter par php pour faire une compression ne fera à mon sens que surcharger le travail du serveur pour pas grand chose.
Compression du html oui, css non.

Cache ?
idem, je ne vois aucun intérêt à mettre en cache un vulgaire fichier de quelques octets :\
Surtout que les navigateurs le font très bien.

Puissance ?

Et pour le respect des standards, pour ma part je m'en tape un peu le coquillard pour le css, parce que bon entre css1, css2, css3, cssz, on a pas fini de s'arracher les cheveux, attention je ne dis pas que je créé des fichiers css torchons, mais que si j'ai un avertissement/erreur du validateur pour une propriété proprio d'un navigateur, ou d'une propriété css d'une version supérieure, cela ne me fait ni chaud ni froid.

[franculo_caoulene]

Concernant, le serveur, il suffit de bien le configurer. Pour ça tu peux suivre les recommandations de yahoo, qui sont de configurer le serveur afin de retourner le fichier compressé au format gzip et de définir les ETag qui te permettent de retourner une réponse HTTP 304. Le gain risque d'être minime, car en général il est centralisé donc commun à tout le site (ou à de grandes parties).

Concernant la puissance, il faudrait que tu éclaircisses ta demande. Pourquoi cherches-tu à avoir quelque chose d'aussi performant et polyvalent? C'est rarement compatible.

Concernant l'écriture du CSS plus particulièrement, la recherche de performance amène à plus de spécificité et donc moins de maintenabilité, à mon avis. Si tu minimises les sélecteurs au maximum en multipliant les classes, tu surchargeras tous les document (X)HTML de plusieurs octets. De plus, tu parles de CSS orienté objet (façon extension de classe), mais, sans tester, logiquement le chargement de deux classes n'est-il pas plus lent que le chargement d'une seule? Ce n'est vraiment pas si simple.
Personnellement, jusqu'à maintenant je privilégie la maintenabilité en utilisant sémantique, hiérarchie et héritage. Même si je lis de plus en plus que c'est "contre-performant".

Produits-tu un nouveau yahoo ou google? Que cherchez-tu à produire? Est-ce vraiment nécessaire? Les performances doivent d'abord s'opérer coté serveur : bonne configuration et bonne programmation.

[Arkante]

Merci pour vos réponses, je vais essayer d'éclaircir ma démarche.


SITUATION 1 : HTML sémantique
Le but est donc de respecter les standards qui veulent que l'on nomme un objet pour ce qu'il représente et non comment il est représenté. Mais cela implique des répétitions du CSS, le code n'est pas réutilisable.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
<div class="infobox"></div>
<div class="errorbox"></div>

On peut imaginer que ces deux classes ont des styles en communs, mais aucun moyen de le faire valoir. La solution serait de rajouter un div au-dessus, mais c'est plus sémantique, et inutile qui plus est.


SITUATION 2 : sémantique mais pas trop
C'est ce que certains appellent l'OOCSS, ils signent l'arrêt de mort de l'id car il ne permet pas de réutiliser le code. Ils font de la factorisation, ca rend le code plus réutilisable. Tout marche par module.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
<div class="info box"></div>
<div class="error box"></div>

Maintenant, on a trois classes, .info est le PGDC des deux éléments et .error et .info sont leurs éléments spécifiques.


QUE CHOISIR ?
La situation 1 est bien pour le HTML pas pour le CSS, et inversement pour la situation 2. D'un point de vue pragmatique on préfèrera la situation 2 en faisant attention aux bien nommer ses classes.

MAIS, il y a des limites tout de même. Ce n'est pas de l'OO. Tout est certes modulaires, mais il n'y a pas d'héritage à proprement parler (mixins).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
.box {}
.error { extend : .box; }

Ca serait pourtant parfait, car dans ce cas ce serait totalement sémantique, on pourrait faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<div class="error"></div>

C'est là qu'intervient les surcouches logiques. exscale propose de mapper les classes entre-elles.

Donc on arrive à un compromis : le CSS est propre en developpement (ce n'est plus vraiment du CSS), on peut lui appliquer des principes de l'OO, il est plus propre, plus maintenable. Le HTML est parfaitement sémantique. Et lors du passage en production, on optimise le code (par exemple avec un CSSTidy qui réduit la taille du css) et génère le CSS.

Tant qu'à faire on peut pousser le vice plus loin. Deux solutions sont très intéressantes en modifiant la manière d'écrire le CSS, et qui compile à la fin un fichier CSS : Saas et Less. Je vous invite a regarder, Less présente rapidement les possibilités d'une surcouche.

DONC, tout est parfait on adopte ca pour le développement. Et pour la production ? Et bien, si on se contente du CSS, on perd les variables (si ce n'est pas utile dans tous les projets, ca peut être très utile d'avoir un css dépendant de l'heure, ou même qui laisse la possibilité à l'utilisateur de personnalisé son interface).

Il faut donc que la surcouche soit présente sur le serveur. Et c'est la qu'intervient la performance. Pour mettre du PHP (Saas et Less sont pour Ruby), il faut remplacer le css par un fichier php (cf cet article). On ne peut se payer le luxe de générer le css à chaque page, il faut le mettre en cache (ce qu'il fait dans son code).

- Si l'utilisateur choisit sa couleur, ca fait une infinité de fichiers css. Faut-il les générés à la demande et les mettre en chache OU généré le fichier une fois pour toute, au risque d'avoir bcp de fichiers ? Il ne faut pas négliger que chaque génération du CSS implique de parser le code (remplacer les variables, faire les opérations, rétablir les héritages, réduire le code a la CSSTidy).

CONCLUSION
Je voulais avoir des avis, pour savoir si vous utilisiez des solutions comme celles-ci. Quels expériences vous en avez...

Je ne suis pas convaincu encore qu'une solution est parfaite. Ce qui est sûr c'est que le match se joue entre la SITUATION 2 (toute simple quitte à mettre du PHP au cas par cas dans les projets qui en ont besoin) et celle de la surchouche évoluée. Je fais un tableau pour récapituler les avantages :




Merci pour vos retours d'info !

[burnzedy]

Bonsoir,

je suis pas un expert mais d'après ce que j'ai vu récemment (notamment avec Drupal et Wordpress) on est souvent plus proche de la solution 2 mais plutot "sémantique mais vraiment pas trop".

Par exemple dans drupal, beaucoup de thèmes utilisent des classes soit sémantiques (la fonction), soit contextuelles (quelle type de page, le navigateur, quel utilisateur, js activé? ...), soit formelles (redButton), soit de positionnement (clear-left, align-center) et en général un peu tout à la fois!

Quand on regarde les frameworks css, c'est un peu pareil, il y a des feuilles de style pour la typo, une autre pour le placement, une pour le reset d'autre pour monter des "layouts/grids" rapidement etc...

Le problème des framework c'est qu'il faut apprendre à les utiliser et que ça corresponde au type de site que l'on conçoit au jour le jour...

A mon avis le plus simple est encore de faire comme sur les cms (drupal etc..) c'est à dire de se faire son propre mini-framework en planifiant bien les besoin en css en amont pour se faciliter la tache. Car de toute façon tout dépend du / des sites en dev.

Après pour ce qui est du Less c'est à toi de voir, c'est peut être intéressant pour le dev, pour générer les feuilles de styles (mais c'est une étape en plus, qui peut etre automatique j'imagine..) et sur un site en production, à mon avis c'est beaucoup de travail (pour le serveur par ex.) pour pas grand chose à moins que le fait de générer des css à la volée soit primordiale (mais c'est aussi possible en php/jquery ou autre).

Sinon pour en finir, un des problème de performance des css est que souvent on a 10 feuilles css... Dans ce cas tout regrouper en une seule feuille est ce qui fera gagner le plus en performance (mieux vaut une grosse css que 10 petites).

Après tout dépend de ce que tu veux faire.. et il faut voir si quelqu'un pourra nous donner son avis sur les "surcouche"...

[franculo_caoulene]

Pour répondre directement à ta question, je n'utilise pas des choses du genre de Less.

Sincèrement, contente toi de la "SITUATION 2 : sémantique mais pas trop". En jetant un œil à Less on se rend compte que tout ce dont tu as besoin peut être fait avec du CSS propre.

Les variables : Ou plutôt des constantes! Soit tu suis le principe de l'extension de classe à l'extrême et tu te fais une classe pour cette variable au risque de démultiplier les classes. Soit tu la mets simplement en commentaire en tête du fichier CSS. Tu n'auras plus qu'à "remplacer dans le fichier" la valeur définie. Pour palier ce cas de figure :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
/* CSS */
#header {color: #4D926F;}
h2 {color: #4D926F;}
 
/* LESS */
@brand_color: #4D926F;
#header {color: @brand_color;}
h2 {color: @brand_color;}
 
/* FC */
/** constantes
* @brand_color: #4D926F;
*/
#header {color: #4D926F;}
h2 {color: #4D926F;}

Les mixins : Ça existe déjà, ce sont les classes. C'est la que je me dis que les gens qui ont développer Less sont réellement des développeurs! L'exemple donné sur leur site est vraiment mauvais et me fait dire qu'ils n'ont rien compris au CSS (j'avoue c'est un peu présomptueux de ma part). Pour palier ce cas de figure :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
/* CSS */
#header {-moz-border-radius: 8px;-webkit-border-radius: 8px;border-radius: 8px;}
#footer {-moz-border-radius: 8px;-webkit-border-radius: 8px;border-radius: 8px;}
 
/* LESS */
.rounded_corners {-moz-border-radius: 8px;-webkit-border-radius: 8px;border-radius: 8px;}
#header {.rounded_corners;}
#footer {.rounded_corners;}
 
/* FC */
.rounded_corners {-moz-border-radius: 8px;-webkit-border-radius: 8px;border-radius: 8px;}

Les nested rules (encapsulage) : Aucun intérêt, le CSS est déjà très bien. Si tu cherches la performance tu peux suivre la recommandation de Mozilla que tu as trouvée. Pour palier ce cas de figure :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
/* CSS */
#header {color: red;}
#header a {font-weight: bold;text-decoration: none;}
 
/* LESS */
#header {
  color: red;
  a {font-weight: bold;text-decoration: none;}
}
 
/* FC */
#header {color:f00;}
#header-link {font-weight: bold;text-decoration: none;}

Les opérations : Est-ce vraiment important? Tu calcules une bonne fois pour toute et c'est bon, ce n'est pas si long. La calculatrice windows fait les calculs hexadécimaux. De plus, pour les couleurs ce n'est pas pertinent du tout, CDCDCD/3 = 4499EF c'est à dire gris divisé par trois donne bleu!

Les opérations m'ont fait voir que les couleurs sont beaucoup plus simples à remplacer que les dimensions. Pour ça, en développement tu peux intégrer les commentaires dans les règles CSS, pour les supprimer à la mise en production :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <title><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
  <title>constantes CSS</title>
  <meta http-equiv="Content-type" content="text/html; charset=UTF-8" />
  <style type="text/css">
  /** constantes
  * @fond = #333
  * @texte = 1.5em
  * @texte = #ddd
  */
  body {background:/*@fond*/#333;color:/*@texte*/#ddd;font-size:/*@texte*/1.5em;}
  </style>
</head>
<body>
  <p>Je teste.</p>
</body>
</html></title>
  <meta http-equiv="Content-type" content="text/html; charset=UTF-8" />
  <style type="text/css">
  /** constantes
  * @fond = #333
  * @texte = 1.5em
  * @texte = #ddd
  */
  body {background:/*@fond*/#333;color:/*@texte*/#ddd;font-size:/*@texte*/1.5em;}
  </style>
</head>
<body>
  <p>Je teste.</p>
</body>
</html>

Bref rien de bien nouveau dans Less, finalement.

Bien sûr les exemples du sites sont simplissimes. Si tu as des cas de figure plus pertinents, je t'encourage à me les exposer.

Le dernier point à éclaircir est :

- Si l'utilisateur choisit sa couleur, ca fait une infinité de fichiers css. Faut-il les générés à la demande et les mettre en chache OU généré le fichier une fois pour toute, au risque d'avoir bcp de fichiers ?

Que cherches-tu à développer exactement?

[Arkante]

Merci pour ta réponse, je vais revenir sur les points un par un :

Variables : Chercher/Remplacer n'est pas pertinent, tout simplement car si un fichier est réellement important il est très probable que la même couleur soit utilisée pour deux choses distinctes. Si on veut en changer seulement une des deux, on doit parcourir le document pour faire un remplacement sélectif. Je ne parle même pas de plusieurs feuilles de styles, même si certains éditeurs et IDE font de recherche croisée sur plusieurs fichiers, ce n'est pas idéal

Les variables, il faut les voir comme un fichier de configuration, aisé à remplacer pour modifier son code. De tous les points, c'est celui qui me semble le plus intéressant.


Mixins : Ton contre exemple ne tient pas, tu es retombé dans la situation 1 de mon précédent post. Aucune réutilisation du code. l'intérêt des mixins est nul dans leur exemple je vais essayer de le détailler dans un exemple plus poussé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
.box {width:200px;}
.error {color:red;}
.messageError {.box; .error;}
 
<div class="messageError"></div>

Quel est l'intérêt ? Si on définit .essageError, et bien il n'est pas factorisé, et il n'est pas réutilisable.

Pourquoi ne pas utiliser <div class="box error"> ? Car si on a un module complex, on va pas lui mettre 30 classes !

Qu'est ce que ca change entre Less et ton exemple ? Rien, le css au final sera le même, c'est juste qu'on l'écrit différement, d'une manière plus maintenanble. C'est d'ailleurs pour moi la grosse limite que le code final soit le même, car ce code est moins bon que celui issu d'une structure issué de la situation 2 (sans surcouche).


Nested rules : Mon argument est un peu bidon, c'est juste que ca facilite la lecture du code et sa hiérarchisation. Ca c'est une histoire de goût. Mais comme pour les mixins, le code final sera le même. On parle juste d'une facon différente d'écrire son code.

Opérations : Cette fois on est d'accord que c'est assez gadget. Surtout que si on a les variables, on peut faire les opérations au niveau des variables. Mais parallèlement, si on a les variables on a déjà une surcouche et donc opérations ou pas, ca coute pas grand chose en plus.

Ce que je veux faire ? : Avoir une librairie CSS performante pour répondre à tous les besoins, sur laquelle n'importe qui puisse travailler avec un tout petit peu d'apprentissage (à mon avis, n'importe qui peu apprendre Less en 1h, le mettre en pratique en 2 et le maitriser en 3).

Les différents besoins que je cible :
- Site quelconque : CSS compilé, optimisé, pas de surcouche en production (mais rien empêche d'en avoir une pour facilité le développement)
- Site interactif : CSS généré (soit on génère un fichier, soit on le génère dynamiquement et le met en cache), nécessité d'une surcouche en production.

C'est l'existence de site interactifs (modification du css par variable) qui me fait envisager la nécessité de la surcouche. Si les variables prennent des valeurs données, la surcouche n'est pas nécessaire en production, mais en développement c'est un gain ENORME que de générer ces CSS à la volée.

Finallement, même si les cas pratique où la surcouche en production est vraiment utile sont rares, les gains en production peuvent être énormes.


J'espère que ma démarche est plus claire. En tout cas merci encore de prendre du temps pour me donner ton avis.

[iManu]

Arkante,

Travail d'équipe efficace
C'est à peu près évident que c'est l'OOCSS (je sais que ce n'est pas de l'OO mais bon) qui l'emporte non ?

Pour info : OO = Orienté Objet



Mon avis : Attention aux surcouches, ce qui reste important c'est la séparation du contenu et de sa mise en forme ! Des feuilles de styles bien construites (no-spaghettis) et réutilisables permettent d'harmoniser le site et gagner en performances. Pour un site de taille réduite, une surcouche est totalement inutile, mais peut apporter des gains de performances sur les sites complexes possédant un grand nombre de pages et développés par plusieurs intervenants.

[iManu]

Arkante, je ne sait pas si cela pourra t'aider dans le cadre de ton projet, mais sache qu'il est possible de modifier les styles d'une feuille via Javascript, avec comme principal avantage de ne pas avoir à solliciter le serveur distant (comme dans l'exemple du fichier php qui va refondre à la demande une nouvelle feuille de style) car tout se passe coté client.

En gros, grâce à DOM (Document Object Model) manipulé à l'aide de javascript on va pouvoir parcourir l'arbre CSS directement dans le fichier CSS et modifier les valeurs à la demande.
Les instructions (choix d'une autre couleur pour le texte par exemple) peuvent être soumises par l'utilisateur via des éléments de formulaire, des prompt(), etc.
L'effet est immédiat et le gain de performance est réel par rapport à la solution php.

Inconvénients : Adapter le code js selon le navigateur, et ne fonctionne pas si on inclus le fichier css à l'aide de l'instruction @import ...

un exemple simple utilisé sur l'article de JDN :

Dans le fichier CSS on défini la règle suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

H1 {color: #660000; font-family: Verdana; font-size: 16pt; font-weight: bold }

Javascript pourra accèder à cette règle (et la modifier) avec l'instruction suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
var MaRegle = document.styleSheets[0].cssRules[2];
maRegle.style.color="#000066";

.. il existe des instructions "Rules" variées : insertRule, addRule, deleteRule, removeRule ...

Pour finir, javascript donne aussi la possibilité de changer de feuille de style ou d'en désactiver avec respectivement document.styleSheets[0].href='feuille.css' et document.styleSheets[0].disabled=true

Javascript est l'ami du serveur car il allège sa charge de travail, alors pourquoi ne pas l'utiliser ?