Pós e pré-processamento de CSS

Olá leitor. No seu caminho para aprender layouts, você aprendeu CSS e deseja seguir em frente? Então para você sob gato. Cuidado, muito código.

Neste artigo, revisarei pré-processadores e pós-processadores.

Não entrarei em detalhes sobre CSS, o que implica que você já o conhece. Vou nomear classes na notação BEM . Além disso, não vou me aprofundar na instalação e configuração de tudo o que escrevo, mas mesmo assim deixarei links que você pode seguir e aprender como fazê-lo.

Vamos começar com os pré-processadores.

Pré-processadores

O que é um pré-processador fora de contexto com CSS? Vicki sabe a resposta.

O que é um pré-processador no contexto do CSS? No nosso caso, o pré-processador é um programa que recebe o código escrito na linguagem do pré-processador para entrada e, na saída, obtemos CSS que podemos fornecer ao nosso navegador.

Quais são os pré-processadores? Existem vários representantes, por exemplo: Sass (.sass, .scss), Less (.less) e Stylys (.stylus).
Também entre os pré-processadores, o PostCSS (ou melhor, seu analisador SugarSS e o plugin PreCSS) podem ser destacados separadamente. Olhando para o futuro, direi que sim, o PostCSS não é apenas um pós-processador.

Vou fazer uma revisão no exemplo do Sass. Mais precisamente, em sua nova sintaxe - SCSS, pois está mais próxima do CSS do que a antiga sintaxe. Vamos começar com os recursos adicionados pelos pré-processadores que não estão em CSS e terminar com os problemas que estão sendo resolvidos.

As possibilidades

Variáveis

//style.scss $color: #fff; span { color: $color; background: $color; } //style.css span { color: #fff; background: #fff; } 

É difícil superestimar a utilidade das variáveis. Agora você pode dar nomes significativos às cores ($ tomato: rgb (255,99,71)), calcular valores não através de constantes, mas através de variáveis ​​(height: $ body_height - $ footer_height) e muito mais. Muitos podem argumentar que existem variáveis ​​no CSS. Mas Can I Use diz que não há suporte para o IE (e por razões óbvias, isso não é esperado).

Aninhamento

 //style.scss .chat-area { width: 40%; &__button { // & -    (   & = .chat-area) display: inline-block; height:36px; width: 10px; } a { color: red; } } //style.css .chat-area { width: 40%; } .chat-area__button { display: inline-block; height:36px; width: 10px; } .chat-area a { color: red; } 

No começo do artigo, me referi ao BEM. Neste exemplo, o elemento com a classe da área de bate-papo é um bloco. Caso haja uma necessidade súbita de renomeá-lo, agora será possível fazê-lo em um só lugar, e isso se tornará uma rotina se várias dezenas de seletores forem digitados em um arquivo que contenha o nome do bloco. Também quero observar que esse é um tipo de proteção contra erros de digitação, porque o nome do bloco é escrito uma vez.

Mixins

 //style.scss @mixin border-radius($radius) { -webkit-border-radius: $radius; -moz-border-radius: $radius; -ms-border-radius: $radius; border-radius: $radius; } .box { @include border-radius(10px); } //style.css .box { -webkit-border-radius: 10px; -moz-border-radius: 10px; -ms-border-radius: 10px; border-radius: 10px; } 

Mixins são um dos tópicos mais difíceis de entender. Grosso modo, um mixin é uma função que recebe argumentos e aplica regras que dependem desses argumentos para um determinado seletor. Neste exemplo, a mixin de raio da borda foi aplicada ao seletor .box

Funções adicionais

 //style.scss $color: #202020; h1, h2 { color: lighten($color, 40%); } //style.css h1, h2 { color: #868686; } 

Basicamente, novos recursos facilitam o trabalho com cores. Por exemplo, a função clarear - ilumina a cor pelo número especificado de porcentagem (o oposto é a função escurecer).

Problemas resolvidos

Modularidade

O problema com a importação padrão é que ele cria uma solicitação adicional para o servidor, o que é uma operação cara. Seria bom se a importação inserisse imediatamente todo o texto da importação no arquivo de origem, certo?

De uma forma ou de outra, não havia pré-processadores antes e o problema tinha que ser resolvido de alguma forma. Por exemplo, você pode escrever todo o código em um arquivo.


No entanto, temos pré-processadores e eles resolverão esse problema para nós. O pré-processador substitui a importação padrão e agora, em vez de solicitar o servidor, insere a importação no arquivo de origem, da maneira que eu queria.

 //style.scss @import "selector1"; @import "selector2"; //selector1.scss span { color: white; } //selector2.scss div { color: gold; } //style.css div { color: gold; } span { color: white; } 

Observe que os arquivos de origem foram convertidos em um. Uma solicitação ao servidor para estática - uma resposta.

Herança

<sarcasm> Temos classes, mas nenhuma herança, como? </sarcasm>. Agora é possível selecionar os chamados "seletores de modelo" e expandi-los com outros seletores.

 // style.scss %equal-heights { //   height: 100%; } %message { //   padding: 10px; } .success { @extend %message; color: green; } .error { @extend %message; color: red; } // style.css .success, .error { padding: 10px; } .success { color: green; } .error { color: red; } 

A beleza dos seletores de modelo é que eles não se encaixam nos estilos gerados. O equalizador do modelo% equal-heights não estava envolvido no código e não deixou rastros no CSS. A mensagem do seletor% foi refletida na forma de regras para os seletores que a expandiram. Você pode herdar de seletores comuns, mas é preferível usar seletores de modelo para que não haja excesso de lixo.

Formatação

Depois que o código é gravado, ele precisa ser formatado (compactado para produção). Você pode fazer isso com a ajuda de colecionadores como o webpack ou através de ferramentas padrão.

Existem 4 tipos de formatação no Sass.

 //expanded span { color: gold; display: block; } div { color: red; } //nested span { color: gold; display: block; } div { color: red; } //compact span { color: gold; display: block; } div { color: red; } //compressed span{color:gold;display:block}div{color:red} 

expandido - Mais semelhante ao código escrito por humanos.
aninhado - Aproximado ao formato da sintaxe antiga. A legibilidade não está perdida, mas é uma questão de hollywood.
compacto - ainda mantém a legibilidade, mas com dificuldade. Útil para determinar o número de seletores em um projeto a olho nu.
compactado - formato já completamente ilegível. Todos os caracteres que podem ser excluídos são excluídos. Adequado para alimentar o navegador.

Postscript

Não entendi alguns dos recursos adicionados por Sass. Por exemplo, loops ou recursos de operadores aritméticos . Vou deixá-los para você se familiarizar.

Pós-processadores

Depois de lidar com os pré-processadores, passamos para os pós-processadores.

No contexto de Css, o pós-processador é essencialmente o mesmo que o pré-processador, mas a entrada no pós-processador não recebe código escrito no idioma do pré-processador, mas também css. Ou seja, o pós-processador é um programa na entrada do qual css é fornecido e a saída é css. Não está muito claro por que isso é necessário.

Vou explicar um exemplo concreto da operação do PostCSS - o único representante dos pós-processadores no contexto do css.

O PostCSS pronto para uso não faz nada com CSS. Ele simplesmente retorna o arquivo que foi fornecido na entrada. As alterações começam quando os plug-ins são conectados ao PostCSS.

Todo o ciclo do PostCSS pode ser descrito da seguinte maneira:

• O arquivo de origem é fornecido à entrada PostCSS e analisado.
• O plug-in 1 faz alguma coisa
• ...
• Plugin n faz alguma coisa
• O resultado é convertido em uma sequência e gravado no arquivo de saída.

Considere os principais plugins existentes no ecossistema PostCSS

Plugins

Autoprefixer

Este plugin é tão popular que muitas pessoas pensam que usam esse plugin, mas não usam PostCSS. Eles estão errados.

 //in.css div { display: flex } //out.css div { display: -webkit-box; display: -webkit-flex; display: -moz-box; display: -ms-flexbox; display: flex } 

O autoprefixer adiciona prefixos de navegador às suas regras. Um dos plugins mais importantes que iniciaram a história do PostCSS sem nada substituível. Você pode até dizer que faz sentido colocar o PostCss apenas por causa deste plugin.

Ambiente predefinido

 //in.css @custom-media --med (width <= 50rem); @media (--med) { a:hover { color: color-mod(black alpha(54%)); } } //out.css @media (max-width: 50rem) { a:hover { color: rgba(0, 0, 0, 0.54); } } 

O PostCSS Preset Env adiciona recursos que são discutidos apenas nos rascunhos dos desenvolvedores de CSS. Neste exemplo, a diretiva @ custom-media foi implementada, bem como a função color-mod. Comece a usar o CSS do futuro hoje!

Módulos CSS

Todos esses BEMs não são para você, mas ainda há um problema com conflitos de nome de classe? Então o PostCSS oferece uma solução diferente.

 //in.css .name { color: gray; } //out.css .Logo__name__SVK0g { color: gray; } 

Módulos CSS alteram os nomes das classes de acordo com um determinado padrão (tudo é personalizável). Agora não sabemos antecipadamente o nome da classe, porque é determinado dinamicamente. Como agora classificar elementos se não os conhecemos com antecedência? Combinando PostCSS, Webpack e ES6, posso oferecer esta solução:

 import './style.css'; //  import styles from './style.css'; //  

Agora, não estamos apenas importando um arquivo com estilos (por exemplo, no arquivo React do componente) e substituindo os valores que conhecíamos antes, mas importando um objeto. As chaves deste objeto serão os seletores originais e os valores serão convertidos. Ou seja, neste exemplo, styles ['name'] = 'Logo__name__SVK0g'.

Curto

 //in.css .icon { size: 48px; } .canvas { color: #abccfc #212231; } //out.css .icon { width: 48px; height: 48px; } .canvas { color: #abccfc; background-color: #212231; } 

O PostCSS Short adiciona várias entradas reduzidas para várias regras. O código está ficando mais curto e, portanto, há menos espaço para erros. Além disso, aumenta a legibilidade.

Reinicialização automática

 //in.css div { margin: 10px; } a { color: blue; } //out.css div, a { all: initial; } div { margin: 10px; } a { color: blue; } 

A Redefinição Automática do PostCSS nos permite não criar um arquivo separado com uma redefinição de todos os estilos. O plug-in cria um seletor grande para todos os seletores, onde ele coloca as regras, redefinindo todos os estilos. Por padrão, apenas a regra all é criada com o valor inicial. Isso é útil em combinação com o plug- in postcss-initial , que por sua vez transforma essa regra em um conjunto de regras para 4 telas. No entanto, tudo pode ser configurado e redefinido, por exemplo, assim:

 //out.css div, a { margin: 0; padding: 0; } div { margin: 10px; } a { color: blue; } 

Lembre-se, no início do artigo, eu disse que o PostCSS não é apenas um pós-processador?

PostCSS - pré-processador?

Considere um analisador e um plug-in, após o qual você mudará sua opinião atual sobre o PostCSS.

Sugararss

 //in.sss .parent color: white .parent > .child color: black //out.css .parent { color: white } .parent > .child { color: black } 

O SugarSS é um analisador (não um plugin!), Que é baseado em recuo , e não em chaves, como padrão. Possui uma extensão separada ".sss". O código escrito usando SugarSS é semelhante em estilo à sintaxe antiga do Sass, mas sem loções como variáveis, mixins, herança etc.

Você adivinhou o que o próximo plugin adicionará?

Precss

 //in.sss $color: black .parent .child color: $color //  SugarSS $color: black; .parent { .child { color: $color } } //out.css .parent .child { color: black } 

O PreCSS apenas adiciona os recursos dos pré-processadores descritos na primeira metade do artigo.

E por que o PostCSS não é um pré-processador agora?

Stylelint

Muito já foi escrito sobre o Stylelint . Ele entrou nessa revisão porque usa o PostCSS como um analisador de linhas de arquivos CSS. Suponha que tenhamos esse arquivo.

 a { color: rgb(1, 1, 1) } div { color: rgb(0, 0, 0) } 

Aqui está sua saída para o arquivo atual:

  2:21 Expected a trailing semicolon declaration-block-trailing-semicolon 6:21 Expected a trailing semicolon declaration-block-trailing-semicolon 7:1 Unexpected missing end-of-source newline no-missing-end-of-source-newline 

A utilidade dessa ferramenta é bastante difícil de superestimar.

Conclusões

Os pré-processadores adicionam muitas novas funcionalidades que não estão no CSS. Depois de experimentar, você dificilmente retornará ao CSS comum.

O PostCSS está muito mais próximo do CSS original do que os pré-processadores, mas, no entanto, com certos plugins conectados, ele pode ter a mesma funcionalidade (e até sintaxe semelhante). Os tipógrafos iniciantes podem escrever sem nem pensar que os layouts não estão em CSS puro. Alguns plugins (por exemplo, Autoprefixer) não possuem análogos no mundo do pré-processador.

Ninguém se incomoda em usar pré-processadores e PostCSS em conjunto. A opção é muito boa para projetos que já usam pré-processadores e têm um local de moradia.

Para novos projetos, eu recomendaria usar apenas PostCSS. Os designers de layout são usados ​​para pré-processar a sintaxe? Instale o plug-in PreCSS e o analisador SugarSS. Precisa de compatibilidade entre navegadores? Instale o plug-in Autoprefixer. A compatibilidade entre navegadores não é mais necessária (por exemplo, seu projeto foi envolto em elétron e tornou-se desktop)? Basta desinstalar o Autoprefixer! Com o PostCSS, você pode, assim como o construtor, criar exatamente o que seu projeto precisa.