Pourquoi n'utilisons-nous pas du CSS dynamique (généré côté serveur)?


15

Comme le HTML généré côté serveur est trivial (et c'était le seul moyen de créer des pages Web dynamiques avant AJAX), le CSS généré côté serveur ne l'est pas. En fait, je ne l'ai jamais vu. Il existe des compilateurs CSS, mais ils génèrent des fichiers CSS qui peuvent être utilisés comme statiques.

Techniquement, il ne nécessite aucune bibliothèque spéciale, la balise de style HTML doit faire référence au script templater PHP (/ ASP / autre) au lieu du fichier CSS statique, et le script doit envoyer un en- tête de type de contenu CSS - c'est tout.

At-il des problèmes de cache? Je ne pense pas. Le script doit envoyer des en - têtes sans cache, etc. Est-ce un problème pour les designers? Non, ils doivent modifier le modèle CSS (comme ils modifient le modèle HTML).

Pourquoi nous n'utilisons pas de générateurs CSS dynamiques? Ou s'il y en a, faites-le moi savoir.


3
Moins, Sass, SCSS, etc.
Rein Henrichs

Réponses:


13

La grande raison pour laquelle css est rarement généré dynamiquement (cela est également vrai pour javascript) est qu'ils sont de bons candidats pour la mise en cache. Le CSS est un moyen très flexible de styliser vos pages, avec la bonne combinaison de classes, vous pouvez obtenir toutes les différentes parties de toutes vos différentes pages stylisées selon toutes sortes d'indices sans avoir à en conditionner une quelconque dans le CSS lui-même sur ce qui se trouve réellement être présent sur cette page vue.

Tout simplement parce que CSS n'a pas besoin d'être différent par page conduit à une pratique très courante d'optimisation du coût de téléchargement. La plupart des sites regroupent tous les CSS de l'ensemble de leur site en un seul téléchargement, de sorte que les parties qui s'appliqueraient à différentes pages vues sont présentes dans un seul fichier téléchargé. Avec la mise en cache, vos clients n'ont pas besoin d'attendre qu'il se télécharge une deuxième fois. Peut-être plus important encore, vous, en tant que fournisseur de contenu, n'avez pas à payer plus d'une fois le coût du téléchargement du contenu; et vous pouvez même placer le CSS statique sur un serveur mieux adapté à la diffusion de contenu statique, ce qui libère des ressources pour le contenu dynamique réel sur vos serveurs d'applications.

Cette pratique est si courante que de nombreux navigateurs supposent simplement que le CSS est statique; et sont très réticents à télécharger du CSS qu'ils ont déjà; même si les utilisateurs rechargent la page. Ce traitement spécial s'applique uniquement au CSS; les autres types de contenu sont rechargés comme prévu.


7

Je crois que votre hypothèse est fausse: dans mon dernier projet, l'application utilisait du CSS généré par le serveur chargé par ajax (car, selon l'emplacement de la carte que vous regardiez, la page était marquée avec des styles complètement différents).

Cependant, les cas d'utilisation où la récupération de CSS supplémentaire par ajax résoudrait le problème sont assez rares, cela peut être la raison pour laquelle vous ne l'avez jamais rencontré: il est généralement plus facile de maintenir un ensemble de feuilles de style qui sont prétraitées au moment du déploiement (MOINS + minification) et pouvant être mises en cache ( Par exemple, la page suivante pourra réutiliser la feuille de style qu'elle a mise en cache auparavant, donc le temps initial est plus court).


votre point est utile mais je pense que c'est différent au cas par cas, donc la description de good_computer est courte et utile à l'échelle mondiale.
QMaster

7

En fait, il existe des cas d'utilisation pour le CSS dynamique. J'ai travaillé avec trois types différents:

  1. Moins - Moins CSS est essentiellement une extension de langage CSS qui ajoute "un comportement dynamique tel que des variables, des mixins, des opérations et des fonctions". Il autorise également les "règles imbriquées", ce qui est très pratique. J'ai utilisé moins principalement pour rendre l'écriture CSS moins verbeuse en éliminant une partie de la répétition.

  2. Réécriture d'URL - Pour prouver votre affirmation qu'il n'y a pas de problème de cache, j'ai utilisé PHP pour servir les scripts sous forme de fichiers CSS avec les en-têtes de cache appropriés depuis longtemps. Je le fais principalement pour servir des fichiers CSS à partir de bibliothèques qui ne sont pas à l'intérieur de la racine Web.

  3. Rapports dynamiques - Sur un projet sur lequel j'ai travaillé, nous avions un générateur de rapports pour toutes sortes de données dans le système. Nous générons (à l'intérieur des stylebalises, comme vous le mentionnez) des règles de style dynamique principalement pour les couleurs qui avaient été sélectionnées par l'utilisateur dans le générateur de rapports.

Remarque: lorsque vous exportez du CSS directement vers une URL (comme dans 1 ou 2 ) et que vous ne l'incorporez pas dans une page qui est déjà générée par un script, vous ajouterez une charge assez importante au serveur au-dessus du service de contenu statique. Donc, si vous avez un trafic important, même si vous pouvez le faire dynamiquement à chaque fois, vous voudrez le mettre en cache en tant que fichier statique si votre cas d'utilisation le permet.


Mais pourquoi n'est-ce pas plus courant? Je pense qu'il y a une raison principale - CSS n'est pas vraiment conçu pour produire du contenu. Il n'y a donc tout simplement pas un grand besoin. Au-delà de la sortie de couleurs dynamiques choisies par l'utilisateur, comme nous l'avons fait, ou éventuellement d'images d'arrière-plan (bien que si l'image est du contenu , alors c'est probablement un bon argument pour utiliser la imgbalise), que devez-vous faire d'autre dynamiquement?

La plupart des changements de style dynamiques peuvent être produits en se référant à différents documents CSS statiques .

C'est donc certainement possible, comme vous le pensiez, mais il n'y a tout simplement pas trop de raisons de le faire.


4

Il y a DEUX aspects distincts pour charger dynamiquement CSS ...

  1. Génération dynamique du fichier CSS sur le serveur

    C'est assez simple, et beaucoup de sites Web le font. Ceci est utile si vous modifiez votre CSS en fonction d'une condition. Par exemple, si vous choisissez le thème de votre site en fonction de l'emplacement géographique de l'utilisateur.

  2. Chargement d'un fichier CSS à la demande via un chargeur de script JS

    Cela pourrait être utile si vous créez une grande partie du DOM de manière dynamique, puis chargez les styles requis. MAIS Comme le dit l'auteur de LABjs ...

    en fait, déterminer si un fichier CSS chargé dynamiquement a terminé le chargement est en fait assez compliqué et difficile à faire entre les navigateurs. Les événements de "chargement" ne se déclenchent pas comme on pourrait l'espérer / s'y attendre. donc l'ajout d'un tel support ajouterait une taille non triviale à LABjs


3
  1. C'est ce que nous faisons. Tout le temps. Surtout pour des choses comme l'image de marque spécifique au client dans une application SaaS, où les couleurs, etc. proviennent de la base de données.
  2. Il est beaucoup plus rapide (du point de vue de l'utilisateur) de pré-générer le CSS avant ou pendant le déploiement, ou pendant le démarrage de l'application si l'application a une phase de démarrage. Nous préférons généralement pré-générer des fichiers CSS statiques dans la mesure du possible.
  3. Pour une vitesse maximale (du point de vue de l'utilisateur), il est préférable de fournir des fichiers CSS statiques à un CDN et que le navigateur les obtienne du CDN, plutôt que de vos serveurs d'applications. Cela n'est généralement possible que lorsque les fichiers CSS peuvent être pré-générés avant ou pendant le déploiement, et lorsqu'une partie du déploiement fournit les fichiers CSS statiques pré-générés au CDN. Les CDN sont désormais très bon marché et faciles à utiliser - consultez CloudFront d'Amazon et Cloud Cloud de Rackspace.

1

At-il des problèmes de cache? Je ne pense pas. Le script doit envoyer sans cache, etc.

Très bien, mais c'est un élément important d'informations généralement statiques que vous demandez à l'utilisateur de télécharger à chaque fois qu'il charge une page. Il vaut donc mieux avoir une bonne raison.

Maintenant, quelle pourrait être cette raison?

Si vous souhaitez modifier un style en fonction de divers paramètres, vous le faites en ayant plusieurs feuilles de style et en générant le code HTML pour télécharger le bon.


La génération de différentes feuilles de style basées sur des paramètres peut devenir ingérable si vous avez, par exemple, une combinaison de trois couleurs, chacune sélectionnée dans une palette de 256. Vous ne voulez pas garder 16 millions de feuilles de style pour couvrir tout cela, n'est-ce pas?
tdammers

@tdammers: Quel est le cas d'utilisation pour cela? On dirait que ce serait mieux réalisé en utilisant javascript.
pdr

une sorte de système où les utilisateurs peuvent personnaliser l'apparence? Vous ne pouvez pas simplement leur donner un éditeur CSS, car cela exposerait un tas de vulnérabilités de sécurité, mais pouvoir choisir une police et quelques couleurs pour personnaliser l'expérience utilisateur n'est pas exactement une exigence exotique, et si vous le faites , 256 couleurs est en fait trop faible - essayez plutôt des sélecteurs de couleurs sur toute la plage de 24 bits. Javascript ne résoudra pas cela aussi bien que le CSS dynamique.
tdammers

1

Le CSS dynamique est assez trivial, et même si ses applications sont plus limitées (voir comment le HTML généré dynamiquement avec une feuille de style statique résout la plupart des besoins quotidiens, et le CSS lui-même incorpore quelques mécanismes pour obtenir un semi-dynamique), je ' Je l'ai vu utilisé à de nombreuses reprises, et je les utilise moi-même chaque fois que j'en ai besoin.

Souvent, la partie «dynamique» ne fait guère plus que de combiner plusieurs feuilles de style en une seule (pour réduire le nombre de requêtes HTTP) et de les réduire (pour réduire l'utilisation de la bande passante), mais des choses simples comme la substitution de variables (par exemple, en utilisant des variables pour les couleurs utilisées partout) la feuille de style) peut vous faciliter la vie. Cependant, comme CSS a une syntaxe assez simple avec quelques mises en garde, un système de traitement de texte à usage général ou un langage de script comme PHP est généralement suffisant pour cela, c'est pourquoi vous ne voyez pas beaucoup de systèmes de traitement CSS standard.

Vous les avez peut-être vus à l'état sauvage, sans les reconnaître. Les serveurs qui envoient des scripts dynamiques utilisent généralement la réécriture d'URL de sorte que l'URL ne se distingue pas du contenu diffusé statiquement. Cela est nécessaire car certains navigateurs (notamment IE) s'appuient sur des extensions pour une détection correcte du type MIME dans certaines circonstances, ignorant (ou supprimant) les en-têtes de type de contenu que vous avez pu envoyer.

Concernant la mise en cache: les feuilles de style sont tirées avec les demandes GET, et leur mise en cache est absolument importante pour une expérience utilisateur décente. Vous ne voulez pas regarder la page refluer car elle retélécharge la feuille de style à chaque demande. Au lieu de cela, vous devez placer tous les paramètres qui modifient la sortie de votre traitement de feuille de style dans la chaîne de requête; une chaîne de requête différente produit une URL différente, ce qui entraîne à son tour un échec de cache, donc chaque fois que les paramètres sont modifiés, la feuille de style sera téléchargée à nouveau, même si le client met tout en cache. Si vous avez vraiment besoin d'un CSS qui est potentiellement différent pour chaque demande et qui dépend des effets secondaires, envisagez de mettre la partie non dynamique dans une feuille de style desservie statiquement et ne servez que les éléments dynamiques qui sont absolument nécessaires pour être dynamiques.


1

Il y a certains scénarios où j'aimerais utiliser du CSS dynamique, mais le plus souvent, je suis coincé avec des concepteurs qui ont besoin d'un peu d'aide pour comprendre les bases du CSS. Lancer un langage dynamique dans le mix pourrait faire exploser une tête.

Une autre façon de voir les choses serait «un autre gars fait tout le travail manuel douloureux, pas vraiment mon problème, en passant…»

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.