Por que não usamos CSS dinâmico (gerado pelo servidor)?

Como o HTML gerado pelo servidor é trivial (e era a única maneira de criar páginas dinâmicas antes do AJAX), o CSS gerado pelo servidor não é. Na verdade, eu nunca vi isso. Existem compiladores CSS, mas eles geram arquivos CSS que podem ser usados ​​como estáticos.

Tecnicamente, ele não requer bibliotecas especiais, a tag de estilo HTML deve fazer referência ao script de modelador PHP (/ ASP / qualquer que seja) em vez do arquivo CSS estático, e o script deve enviar o cabeçalho do tipo de conteúdo CSS - isso é tudo.

Possui problemas de cache? Acho que não. O script deve enviar cabeçalhos sem cache etc. É problema para designers? Não, eles devem editar o modelo CSS (como eles editam o modelo HTML).

Por que não usamos geradores CSS dinâmicos? Ou, se houver, entre em contato.

A grande razão pela qual o css raramente é gerado dinamicamente (isso também é verdade para o javascript) é porque eles são bons candidatos ao cache. CSS é uma maneira muito flexível de estilizar suas páginas, com a combinação certa de classes, você pode obter todas as diferentes partes de todas as suas diferentes páginas estilizadas de acordo com todos os tipos de sugestões - sem ter que condicionar nenhuma delas no CSS sobre o que realmente está presente nessa visualização de página.

Simplesmente porque o CSS não precisa ser diferente por página, leva a uma prática muito comum de otimizar o custo do download. A maioria dos sites agrupa todos os css de todo o site em um único download, para que partes que se aplicariam a diferentes visualizações de página estejam presentes em apenas um arquivo baixado. Com o cache, seus clientes não precisam aguardar o download pela segunda vez. Talvez o mais importante seja que você, como provedor de conteúdo, não precisa pagar o custo do upload do conteúdo mais de uma vez; e você pode até colocar o CSS estático em um servidor mais adequado para a veiculação de conteúdo estático, o que libera recursos para o conteúdo dinâmico real em seus servidores de aplicativos.

Essa prática é tão comum que muitos navegadores apenas assumem que o css é estático; e relutam muito em baixar o CSS que já possuem; mesmo se os usuários recarregarem a página. Este tratamento especial se aplica apenas ao CSS; outros tipos de conteúdo são recarregados conforme o esperado.

Acredito que sua suposição está errada: no meu último projeto, o aplicativo estava usando CSS gerado pelo servidor carregado pelo ajax (porque, dependendo da localização do mapa que você estava olhando, a página foi marcada com estilos completamente diferentes).

No entanto, os casos de uso em que a recuperação de CSS extra pelo ajax resolveria o problema são bastante raros; talvez seja por isso que você nunca encontrou isso: geralmente é mais fácil manter um conjunto de folhas de estilo pré-processadas no momento da implantação (LESS + minification) e armazenável em cache ( por exemplo, a próxima página poderá reutilizar a folha de estilo em cache antes, para que o tempo inicial seja mais curto).

Na verdade, existem casos de uso para CSS dinâmico. Eu trabalhei com três tipos diferentes:

1. CSS Menos - Menos é basicamente uma extensão da linguagem CSS que adiciona "comportamento dinâmico como variáveis, mixins, operações e funções". Também permite "regras aninhadas", o que é muito conveniente. Eu usei Menos principalmente para tornar a escrita CSS menos detalhada, eliminando parte da repetição.

2. Reescrita de URL - Como prova de que não há problemas de cache, usei o PHP para servir scripts como arquivos CSS com os cabeçalhos de cache corretos por um longo tempo. Faço isso principalmente para servir arquivos CSS de bibliotecas que não estão dentro da raiz da web.

3. Relatórios dinâmicos - em um projeto em que trabalhei, tínhamos um construtor de relatórios para todos os tipos de dados no sistema. Produzimos (dentro das styletags, como você mencionou) regras de estilo dinâmico principalmente para cores que foram selecionadas pelo usuário no construtor de relatórios.

^{Nota: Ao gerar CSS diretamente para uma URL (como em 1 ou 2 ) e não incorporá-lo em uma página que já está sendo gerada por um script, você adicionará uma carga bastante significativa ao servidor ao veicular conteúdo estático. Portanto, se você tiver um tráfego considerável, mesmo que possa fazê-lo dinamicamente sempre, convém armazená-lo em cache como um arquivo estático, se o seu caso de uso permitir.}

Mas por que não é mais comum? Eu acho que há uma razão principal - o CSS não é realmente construído para gerar conteúdo. Portanto, simplesmente não há uma grande necessidade. Além de produzir cores dinâmicas escolhidas pelo usuário, como fizemos, ou possivelmente imagens de segundo plano (embora se a imagem seja conteúdo , provavelmente é um bom argumento usar a imgtag), o que mais você precisa fazer dinamicamente?

A maioria das alterações dinâmicas de estilo podem ser produzidas consultando diferentes documentos estáticos CSS.

Portanto, é certamente possível, como você pensou, mas simplesmente não há muitas razões para fazê-lo.

Existem DOIS aspectos separados para carregar CSS dinamicamente ...

1. Gerando o arquivo CSS dinamicamente no servidor

   Isso é bastante simples e muitos sites fazem isso. Isso é útil se você alterar seu CSS com base em alguma condição. Por exemplo, se você escolher o tema do seu site com base na localização geográfica do usuário.

2. Carregando um arquivo CSS sob demanda por meio de um carregador de scripts JS

   Isso pode ser útil se você criar grande parte do DOM dinamicamente e carregar os estilos necessários. MAS Como o autor do LABjs diz ...

   determinar se um arquivo CSS carregado dinamicamente terminou o carregamento é realmente bastante complicado e desafiador para o usuário em vários navegadores. Os eventos "load" não são acionados como seria de esperar / esperar. portanto, adicionar esse suporte adicionaria um tamanho não trivial ao LABjs

1. Nós fazemos isso. O tempo todo. Especialmente para itens como marca específica do cliente em um aplicativo SaaS, onde cores etc. vêm do banco de dados.
2. É muito mais rápido (do ponto de vista do usuário) pré-gerar o CSS antes ou durante a implantação ou durante a inicialização do aplicativo, se o aplicativo tiver uma fase de inicialização. Geralmente, preferimos pré-gerar arquivos CSS estáticos sempre que possível.
3. Para obter a velocidade máxima (do ponto de vista do usuário), é melhor entregar arquivos CSS estáticos para uma CDN e fazer com que o navegador os obtenha da CDN, e não dos servidores de aplicativos. Geralmente, isso só é possível quando os arquivos CSS podem ser pré-gerados antes ou durante a implantação e onde parte da implantação está entregando os arquivos CSS estáticos pré-gerados à CDN. Agora, as CDNs são muito baratas e fáceis de usar - confira o CloudFront da Amazon e o Cloud Files da Rackspace.

Possui problemas de cache? Acho que não. O script deve enviar sem cache, etc

Tudo muito bem, mas é uma parte significativa das informações geralmente estáticas que você está pedindo ao usuário para baixar sempre que carregar uma página. Então é melhor você ter uma boa razão para isso.

Agora, qual poderia ser esse motivo?

Se você deseja alterar um estilo com base em vários parâmetros, faça isso tendo várias folhas de estilo e gerando o HTML para fazer o download do correto.

O CSS dinâmico é bastante trivial e, embora seus aplicativos sejam mais limitados (vendo como o HTML gerado dinamicamente com uma folha de estilo estática resolve a maioria das necessidades do dia-a-dia, e o próprio CSS incorpora alguns mecanismos para obter semi-dinâmica), ' já o vi usado em muitas ocasiões, e eu mesmo as uso sempre que preciso.

Freqüentemente, a parte 'dinâmica' faz pouco mais do que combinar várias folhas de estilo em uma (para reduzir o número de solicitações HTTP) e reduzi-las (para reduzir o uso da largura de banda), mas coisas simples como substituição de variável (por exemplo, usando variáveis ​​para cores usadas em toda a folha de estilos) pode facilitar sua vida. No entanto, como o CSS tem uma sintaxe bastante direta com poucas advertências, um sistema de processamento de texto de propósito geral ou uma linguagem de script como PHP geralmente é suficiente para isso, e é por isso que você não vê muitos sistemas de processamento CSS disponíveis no mercado.

Talvez você os tenha visto na natureza, sem reconhecê-los. Os servidores que enviam scripts dinâmicos geralmente usam a reescrita de URL, para que a URL se torne indistinguível do conteúdo veiculado estaticamente. Isso é necessário porque alguns navegadores (principalmente o IE) contam com extensões para a detecção correta do tipo MIME sob certas circunstâncias, ignorando (ou descartando) qualquer cabeçalho do tipo Conteúdo que você possa ter enviado.

Sobre o cache: as folhas de estilo são recebidas com solicitações GET, e torná-las armazenáveis ​​em cache é absolutamente importante para uma experiência decente do usuário. Você não deseja assistir à página refluir enquanto ela baixa novamente a folha de estilo em cada solicitação. Em vez disso, você deve colocar todos os parâmetros que alteram a saída do processamento da folha de estilo na string de consulta; uma sequência de consulta diferente gera uma URL diferente, o que, por sua vez, causa uma falha no cache; portanto, sempre que os parâmetros forem alterados, a folha de estilo será baixada novamente, mesmo que o cliente armazene tudo em cache. Se você realmente precisa de CSS potencialmente diferente para cada solicitação e depende de efeitos colaterais, considere colocar a parte não dinâmica em uma folha de estilo veiculada estaticamente e atenda apenas as coisas dinamicamente que são absolutamente necessárias para serem dinâmicas.

Existem alguns cenários em que eu adoraria usar CSS dinâmico, mas, na maioria das vezes, não consigo usar designers que precisam de um pouco de ajuda para entender o básico sobre CSS. Jogar uma linguagem dinâmica na mistura pode realmente fazer a cabeça explodir.

Outra maneira de ver isso seria "outro cara está fazendo todo o trabalho manual doloroso, não é realmente o meu problema, seguindo em frente ..."