Atualmente, estamos no meio de um exercício do tipo CSS Zen Garden em nossa família de sites de perguntas e respostas, aos quais me refiro carinhosamente como “a Trilogia”:
(Caso o senhor esteja se perguntando, sim, meta é o Especial de férias de Star Wars.)
Todos esses sites executam o mesmo mecanismo principal, mas o logotipo, o domínio e a “capa” CSS que fica sobre o esqueleto HTML são diferentes em cada caso:
Eles não são terrivelmente com aparência diferente, é verdade, mas também queremos que eles sejam reconhecidos como uma família de sites.
Estamos trabalhando com dois designers incríveis, Jin Yang e Nathan Bowersque estão nos ajudando a colocar o CSS e o HTML em forma para que possam produzir um conjunto de cerca de 10 designs diferentes de jardins zen. À medida que novos sites em nossa rede são democratizados e passam a existiresses designs serão usados como uma paleta para a comunidade escolher. (E, posteriormente, a comunidade também decidirá sobre um nome de domínio e um logotipo).
De qualquer forma, menciono isso não porque o meus pokemans, deixe-me mostrá-los ao senhormas porque tenho que manter pessoalmente quatro arquivos CSS diferentes. E esse número só vai aumentar. Muito maior. Isso me assusta um pouco.
Acima de tudo, o que aprendi com esse exercício de tematização de sites é que CSS é um pouco doloroso. Eu apoio totalmente o CSS como uma ferramenta (principalmente) funcional interface de usuário Model-View-Controller. Mas mesmo que o senhor tenha uma higiene extrema com o HTML e níveis austríacos de disciplina, o CSS tem alguns limitações sérias na prática.
Coisas em particular que nos incomodam muito:
- O alinhamento vertical é um grande problema. (Mas as tabelas funcionam muito bem para isso!)
- A falta de variáveis faz com que tenhamos que repetir as cores em todos os lugares.
- A falta de aninhamento faz com que tenhamos que repetir blocos enormes de CSS por toda parte.
Em suma, o CSS viola a porcaria do o princípio DRY. O senhor está constantemente e inevitavelmente repetir o senhor mesmo.
É por isso que estou tão intrigado com duas joias Ruby que tentam abordar diretamente as deficiências do CSS.
1. Menos CSS
/* CSS */
#header {
-moz-border-radius: 5;
-webkit-border-radius: 5;
border-radius: 5;
}
#footer {
-moz-border-radius: 10;
-webkit-border-radius: 10;
border-radius: 10;
}
|
// LessCSS
.rounded_corners (@radius: 5px) {
-moz-border-radius: @radius;
-webkit-border-radius: @radius;
border-radius: @radius;
}
#header {
.rounded_corners;
}
#footer {
.rounded_corners(10px);
}
|
2. SASS
/* CSS */
.content_navigation {
border-color: #3bbfce;
color: #2aaebd;
}
.border {
padding: 8px;
margin: 8px;
border-color: #3bbfce;
}
|
// Sass !blue = #3bbfce !margin = 16px .content_navigation border-color = !blue color = !blue - #111 .border padding = !margin / 2 margin = !margin / 2 border-color = !blue |
Como o senhor pode ver, em ambos os casos estamos transmogrificando o CSS em um pouco mais de linguagem de programaçãoem vez do conjunto estático de regras de layout que existe atualmente. Nos bastidores, estamos gerando CSS simples usando essas pequenas linguagens dinâmicas. Isso pode ser feito no momento da criação do projeto ou até mesmo dinamicamente em cada carregamento de página, se o senhor tiver uma boa estratégia de cache.
Não tenho certeza de quantas dessas melhorias o CSS3 não importa quando a maior parte dos navegadores do mundo será compatível com ele. Mas, definitivamente, acho que as principais mudanças identificadas em ambos os Menos CSS e SASS abordam pontos problemáticos muito reais no uso prático do CSS. Vale a pena dar uma olhada neles para entender por que existem, o que eles trazem para a mesa e como o senhor pode adotar algumas dessas estratégias em seu próprio CSS e em sua linguagem de programação favorita.