¿Por qué no usamos CSS dinámico (generado por el servidor)?


15

Como el HTML generado en el lado del servidor es trivial (y era la única forma de crear páginas web dinámicas antes de AJAX), el CSS generado en el lado del servidor no lo es. En realidad, nunca lo he visto. Hay compiladores CSS, pero generan archivos CSS que pueden usarse como estáticos.

Técnicamente, no requiere bibliotecas especiales, la etiqueta de estilo HTML debe hacer referencia a la secuencia de comandos de plantilla PHP (/ ASP / lo que sea) en lugar del archivo CSS estático, y la secuencia de comandos debe enviar un encabezado de tipo de contenido CSS , eso es todo.

¿Tiene problemas de caché? No lo creo. El script debe enviar encabezados sin caché, etc. ¿Es un problema para los diseñadores? No, deberían editar la plantilla CSS (ya que editan la plantilla HTML).

¿Por qué no usamos generadores dinámicos de CSS? O si hay alguno, por favor hágamelo saber.


3
Less, Sass, SCSS, etc.
Rein Henrichs

Respuestas:


13

La gran razón por la cual css rara vez se genera dinámicamente (esto también es cierto para javascript) es porque son buenos candidatos para el almacenamiento en caché. CSS es una forma muy flexible de diseñar sus páginas, con la combinación correcta de clases, puede obtener todas las diferentes partes de todas sus diferentes páginas diseñadas de acuerdo con todo tipo de pistas sin tener que condicionar ninguna de ellas en el CSS en lo que realmente está presente en esta página vista.

Simplemente porque CSS no necesita ser diferente por página lleva a una práctica muy común de optimizar el costo de descargarlo. La mayoría de los sitios agrupan todo el CSS para todo su sitio en una sola descarga, de modo que las partes que se aplicarían a diferentes vistas de página están presentes en un solo archivo descargado. Con el almacenamiento en caché, sus clientes no tienen que esperar a que se descargue por segunda vez. Quizás lo más importante es que usted, como proveedor de contenido, no tiene que pagar el costo de cargar el contenido más de una vez; e incluso puede colocar el CSS estático en un servidor que sea más adecuado para servir contenido estático, lo que libera recursos para contenido dinámico real en sus servidores de aplicaciones.

Esta práctica es tan común, que muchos navegadores simplemente asumen que el CSS es estático; y son muy reacios a descargar CSS que ya tienen; incluso si los usuarios vuelven a cargar la página. Este tratamiento especial se aplica solo a CSS; otros tipos de contenido se vuelven a cargar como se esperaba.


7

Creo que su suposición es incorrecta: en mi último proyecto, la aplicación estaba usando CSS generado por el servidor cargado por ajax (porque, dependiendo de la ubicación del mapa que estaba viendo, la página tenía una marca con estilos completamente diferentes).

Sin embargo, los casos de uso en los que recuperar CSS adicional por ajax resolvería el problema son bastante raros, esta puede ser la razón por la que nunca se encontró con esto: generalmente es más fácil mantener un conjunto de hojas de estilo que se procesan previamente en el momento de la implementación (MENOS + minificación) y se pueden almacenar en caché ( por ejemplo, la página siguiente podrá reutilizar la hoja de estilo que almacenó en caché antes, por lo que el tiempo inicial es más corto).


su punto es útil, pero creo que es diferente caso por caso, por lo que la descripción de good_computer es breve y útil a nivel mundial.
QMaster

7

En realidad, hay casos de uso para CSS dinámico. He trabajado con tres tipos diferentes:

  1. Less : Less CSS es básicamente una extensión de lenguaje CSS que agrega "comportamiento dinámico como variables, mixins, operaciones y funciones". También permite "reglas anidadas", lo cual es muy conveniente. He usado Less principalmente para hacer que la escritura CSS sea menos detallada eliminando parte de la repetición.

  2. Reescritura de URL : como prueba de su afirmación de que no hay problemas de caché, he usado PHP para servir scripts como archivos CSS con los encabezados de caché correctos durante mucho tiempo. Principalmente lo hago para servir archivos CSS de bibliotecas que no están dentro de la raíz web.

  3. Informes dinámicos : en un proyecto en el que trabajé, teníamos un generador de informes para todo tipo de datos en el sistema. Generamos (dentro de las styleetiquetas, como usted menciona) reglas de estilo dinámico principalmente para los colores que el usuario había seleccionado en el generador de informes.

Nota: Al enviar CSS directamente a una URL (como en 1 o 2 ) y no incrustarlo dentro de una página que ya está siendo generada por un script, agregará una carga bastante significativa al servidor sobre la publicación de contenido estático. Por lo tanto, si tiene un tráfico considerable, a pesar de que puede hacerlo dinámicamente cada vez, querrá almacenarlo en caché como un archivo estático si su caso de uso lo permite.


Pero, ¿por qué no es más común? Creo que hay una razón principal: CSS no está realmente diseñado para generar contenido. Entonces simplemente no hay una gran necesidad. Más allá de generar colores dinámicos elegidos por el usuario, como lo hicimos nosotros, o posiblemente imágenes de fondo (aunque si la imagen es contenido , entonces probablemente sea un buen argumento para usar la imgetiqueta), ¿qué más necesita hacer dinámicamente?

La mayoría de los cambios de estilo dinámicos se pueden producir haciendo referencia a diferentes documentos CSS estáticos .

Entonces, ciertamente es posible, como pensabas, pero simplemente no hay demasiadas razones para hacerlo.


4

Hay DOS aspectos separados para cargar CSS dinámicamente ...

  1. Generando el archivo CSS dinámicamente en el servidor

    Esto es bastante sencillo, y muchos sitios web lo hacen. Esto es útil si cambia su CSS en función de alguna condición. Por ejemplo, si elige el tema de su sitio en función de la ubicación geográfica del usuario.

  2. Carga de un archivo CSS bajo demanda a través de un cargador de script JS

    Esto podría ser útil si crea una gran parte de DOM dinámicamente y luego carga los estilos requeridos. PERO Como dice el autor de LABjs ...

    En realidad, determinar si un archivo CSS cargado dinámicamente ha terminado de cargarse es bastante complicado y desafiante para hacer un navegador cruzado. Los eventos de "carga" no se activan como cabría esperar / esperar. por lo que agregar dicho soporte agregaría un tamaño no trivial a LABjs


3
  1. Nosotros hacemos esto. Todo el tiempo. Especialmente para cosas como la marca específica del cliente en una aplicación SaaS, donde los colores, etc. provienen de la base de datos.
  2. Es mucho más rápido (desde el punto de vista del usuario) generar previamente el CSS antes o durante la implementación, o durante el inicio de la aplicación si la aplicación tiene una fase de inicio. Generalmente preferimos pregenerar archivos CSS estáticos siempre que sea posible.
  3. Para una velocidad máxima (desde el punto de vista del usuario), es mejor entregar archivos CSS estáticos a un CDN y hacer que el navegador los obtenga del CDN, en lugar de los servidores de aplicaciones. Esto generalmente es posible solo cuando los archivos CSS pueden generarse previamente antes o durante la implementación, y cuando parte de la implementación entrega los archivos CSS estáticos generados previamente a la CDN. Los CDN ahora son muy baratos y fáciles de usar: consulte CloudFront de Amazon y Cloud Files de Rackspace.

1

¿Tiene problemas de caché? No lo creo. El script debe enviar sin caché, etc.

Todo muy bien, pero esa es una pieza importante de información generalmente estática que le está pidiendo al usuario que descargue cada vez que carga una página. Así que será mejor que tengas una buena razón para ello.

Ahora, ¿cuál podría ser esa razón?

Si desea cambiar un estilo basado en varios parámetros, hágalo teniendo múltiples hojas de estilo y generando el HTML para descargar el correcto.


La generación de diferentes hojas de estilo basadas en parámetros puede volverse inmanejable si tiene, por ejemplo, una combinación de tres colores, cada uno seleccionado de una paleta de 256. No desea tener 16 millones de hojas de estilo para cubrir todo esto, ¿verdad?
tdammers

@tdammers: ¿Cuál es el caso de uso para eso? Parece que se lograría mejor usando JavaScript.
pdr

algún tipo de sistema donde los usuarios pueden personalizar la apariencia? No puede simplemente darles un editor CSS, porque eso expondría un montón de vulnerabilidades de seguridad, pero poder elegir una fuente y algunos colores para personalizar la experiencia del usuario no es exactamente un requisito exótico, y si lo hace , 256 colores en realidad son atípicamente bajos; en su lugar, pruebe los selectores de color en el rango completo de 24 bits. Javascript no resolverá esto tan bien como lo haría CSS dinámico.
tdammers

1

El CSS dinámico es bastante trivial, y aunque sus aplicaciones son más limitadas (ver cómo el HTML generado dinámicamente con una hoja de estilo estática resuelve la mayoría de las necesidades cotidianas, y el propio CSS incorpora algunos mecanismos para lograr semidinámico), yo ' Lo he visto usado en muchas ocasiones, y lo uso yo mismo cuando lo necesito.

A menudo, la parte 'dinámica' hace poco más que combinar varias hojas de estilo en una (para reducir el número de solicitudes HTTP) y minimizarlas (para reducir el uso de ancho de banda), pero cosas simples como la sustitución de variables (por ejemplo, el uso de variables para los colores utilizados en todo la hoja de estilo) puede hacerte la vida mucho más fácil. Sin embargo, dado que CSS tiene una sintaxis bastante sencilla con algunas advertencias, un sistema de procesamiento de texto de propósito general o un lenguaje de script como PHP generalmente es suficiente para esto, por lo que no ve muchos sistemas de procesamiento CSS estándar.

Tal vez los has visto en la naturaleza, sin reconocerlos. Los servidores que envían scripts dinámicos generalmente usan la reescritura de URL para que la URL se vuelva indistinguible del contenido servido estáticamente. Esto es necesario porque algunos navegadores (especialmente IE) confían en extensiones para la detección correcta del tipo MIME bajo ciertas circunstancias, ignorando (o descartando) cualquier encabezado de tipo de contenido que haya enviado.

Con respecto al almacenamiento en caché: las hojas de estilo se incorporan con solicitudes GET, y hacerlas almacenables en caché es absolutamente importante para una experiencia de usuario decente. No desea ver el reflujo de la página, ya que vuelve a descargar la hoja de estilo en cada solicitud. En su lugar, debe colocar todos los parámetros que alteran la salida del procesamiento de su hoja de estilo en la cadena de consulta; una cadena de consulta diferente produce una URL diferente, lo que a su vez provoca una pérdida de caché, por lo que cada vez que se modifican los parámetros, la hoja de estilo se volverá a descargar, incluso si el cliente almacena en caché todo. Si realmente necesita CSS que sea potencialmente diferente para cada solicitud y que dependa de los efectos secundarios, considere colocar la parte no dinámica en una hoja de estilo servida estáticamente, y solo sirva dinámicamente aquellas cosas que son absolutamente necesarias para ser dinámicas.


1

Hay algunos escenarios en los que me encantaría usar CSS dinámico, pero la mayoría de las veces me quedo con el uso de diseñadores que necesitan un poco de ayuda para comprender los conceptos básicos de CSS. Lanzar un lenguaje dinámico en la mezcla en realidad podría hacer explotar una cabeza.

Otra forma de ver esto sería "algún otro tipo está haciendo todo el trabajo manual doloroso, no es realmente mi problema, seguir adelante ...".

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.