Ícone do site Taller

Organizando CSS em Projetos Complexos #1

Luiz Henrique Guerra
Organizando CSS em projetos complexos

Arquitetura de Estilos

Esta série de artigos se propõe a mostrar técnicas e recursos para escrever, gerenciar e manter estilos em projetos de grande complexidade, com grande escala ou duração. Este primeiro artigo irá abordar a arquitetura de escrita de estilos, apresentando ferramentas para otimizá-la e alguns passos para começar a usar estas ferramentas.

Mas o que seria um projeto complexo?

Há muitos fatores que podem adicionar grande complexidade à escrita eficiente de estilos em um projeto. O sistema a ser desenvolvido não precisa ser, necessariamente, um portal com centenas de milhares de acessos diários ou uma loja com dezenas de categorias de produtos. Mesmo projetos mais modestos podem oferecer bastante complexidade no desenvolvimento de estilos do tema.

As dificuldades podem decorrer, principalmente, da diferença dos diversos sistemas com os quais se podem desenvolver para a web ou de sistemas com muitas telas e componentes com layouts específicos. Desenvolver um tema para Drupal é muito diferente do que desenvolver um para Ghost, por exemplo. Questões como performance, modularidade e semântica podem ficar comprometidas na transição entre tais sistemas e ao tratar padrões visuais.

Esta série se propõe a apresentar ferramentas que ajudam a manter a escrita de estilos tão agnóstica quanto possível do resto do sistema, sem que este perca valor por isso. Isso possibilitaria grande qualidade, produtividade e escalabilidade quando se trata de desenvolvimento de temas.

Iniciando o projeto

Para melhor acompanhamento do projeto, clone o repositório no Github.

Visando mostrar uma estrutura agnóstica, será desenvolvida uma simples página, sem qualquer sistema envolvido, com apenas HTML e CSS no resultado final. Depois de apresentar os processos e técnicas necessários, e estilar uma página com elementos básicos, o processo apresentado poderá ser replicado como modelo para temas em outros projetos.

Para isso, será utilizada uma pasta chamada assets, onde ficarão os recursos de front-end do tema que será desenvolvido. A partir desta pasta serão organizados os estilos e as dependências do tema. Por enquanto, a estrutura de pastas está assim (sendocomplex-css-projects a raiz do tema):

É importante notar que a pasta css não está sendo versionada. Isso será explicado em breve.

Antes de começar com as ferramentas, é necessário adicionar uma estrutura básica ao index.html. É para essa estrutura que serão criados os estilos exemplificados neste artigo.

Pré-processadores de CSS

Escrever CSS é muito mais um trabalho de organização do que de lógica, e organizar uma arquitetura com elementos independentes pode ser bastante custoso sem o uso de alguma ferramenta apropriada. Hoje em dia, algumas ferramentas existem para cumprir este objetivo, e os pré-processadores de CSS são as mais conhecidas e usadas. Eles oferecem uma forma diferente de desenvolver, apresentando vários recursos adicionais e facilidades à escrita, e entregam um código limpo e confiável se corretamente usados.

Neste exemplo será usado o SASS. Para usá-lo em um projeto, é necessário que a máquina tenha Ruby, que é a linguagem na qual é desenvolvido o SASS, instalado.

Organizando o SASS

Como referência de organização da arquitetura de estilos, será usado um boilerplate chamado SassySkeleton (desenvolvido pelo nosso amigo Lucas), que se propõe a melhorar a estrutura de escrita de estilos baseados em SASS e Compass (que é um framework de SASS). Esse boilerplate facilitará o uso dos recursos do SASS de forma modular e escalável. Para usá-lo, basta clonar o repositório para dentro da pasta assets/sass e depois excluir a pastaassets/sass/.git (mais instruções e explicações estão no repositório do SassySkeleton supracitado e nos arquivos README dentro de cada pasta). A estrutura de pastas deve ficar assim (alguns arquivos que não serão usados foram omitidos, mas podem ser mantidos na estrutura):

Botando a mão na massa

O SassySkeleton precisa de algumas dependências baseadas em Ruby para funcionar, e a forma mais fácil de mantê-las em diversos ambientes é usando Bundler. Na raiz da pasta sass há um arquivo chamado Gemfile, onde essas dependências estão declaradas com suas devidas versões:

# Read about Gemfiles at http://bundler.io/v1.5/man/gemfile.5.html
source 'https://rubygems.org'  
gem 'sass', '>= 3.4'  
gem 'compass', '>= 1.0.1'  
gem 'sass-globbing', '>= 1.1.0'

Para instalar as dependências do tipo Ruby Gem, basta declará-las noGemfile com as versões especificadas e rodar o comandobundle install na mesma pasta logo em seguida. Isso serve para que não haja conflito de versões das dependências entre os ambientes usados para desenvolver um sistema e que não haja necessidade de instalar cada uma delas múltiplas vezes, além de não ser necessário rodar o comando gem install para cada uma delas.

Agora é necessário configurar os diretórios de onde o Compass vai pegar o SASS e para onde vai o CSS resultante, além de outras configurações inerentes ao desenvolvimento. Estas configurações estão no arquivo assets/sass/config.rb. Por hora o que interessa é garantir que o CSS vai ser compilado na pasta correta para que possa ser carregado no HTML (este arquivo é um dos recursos mais úteis do Compass, vale a pena analisar o que mais ele oferece).

# Path locations.
sass_dir     = "source" # - The directory where to look for  
                        #   generating stylesheets.
css_dir      = "../css" # - The path for placing compiled  
                        #   CSS. Note that this path points
                        #   one directory above the current
                        #   directory.

Considerando a porção de código acima, percebe-se que os arquivos.sass da pasta assets/sass/source serão compilados em arquivos.css na pasta assets/css. Sabendo que na pastaassets/sass/source existe um arquivo main.sass, então será compilado um arquivo main.css na pasta assets/css. É posível criar mais arquivos .sass para gerar mais arquivos .css, dependendo da necessidade.

Botando a mão na massa mesmo!

Trabalhando, finalmente, com estilos, será criado um arquivobase.sass na pasta assets/sass/partials que será importado no arquivo assets/sass/source/main.sass.

main.sass – note que não é necessário informar o formato do arquivo importado, pois sendo tanto .sass como .scss o @import vai resolver isso.

// ------------------------------------
// Import base library.
// ------------------------------------

@import library

// ------------------------------------
// Import outputing extensions.
// ------------------------------------

// @import normalize

// ------------------------------------
// Import partials.
// ------------------------------------

@import shame
@import base

base.sass – alguns estilos foram adicionados para demonstração

// Basic theme styles.
*
    box-sizing: border-box

body  
    padding: 0
    margin: 0
    font-size: 16px
    font-family: Verdana, sans-serif

    > header
        background: gray
        color: white
        padding: 20px
        font-size: 3rem

section  
    width: 60%
    float: left
    background: yellow
    padding: 20px

aside  
    width: 40%
    float: left
    padding: 20px

footer  
    clear: both
    background: black
    color: white
    padding: 20px

Para transformar os estilos escritos em SASS em CSS legível pelo navegador, basta rodar o comandocompass clean && compass compile na pasta assets/sass (mesma pasta do arquivo config.rb). Para os estilos serem aplicados na página, basta importar normalmente o arquivo main.css.

main.css – é importante notar que o Compass está minificando o arquivo CSS por questões de performance.

*{box-sizing:border-box}body{padding:0;margin:0;font-size:16px;font-family:Verdana,sans-serif}body>header{background:gray;color:#fff;padding:20px;font-size:3rem}section{width:60%;float:left;background:#ff0;padding:20px}aside{width:40%;float:left;padding:20px}footer{clear:both;background:#000;color:#fff;padding:20px}

index.html – Com a linha que importa o CSS devidamente inserida no head.

<!DOCTYPE HTML>  
<html>  
<head>  
  <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
  <title>Your Website</title>

  <!-- Theme styles. -->
   <link rel="stylesheet" type="text/css" href="assets/css/main.css">
</head>  
<body>  
...
</body>  
</html>

Sendo assim, para melhor organizar a escrita dos estilos, basta separar os mesmos dentro da pasta assets/sass/partials de acordo com a área do site, região ou como for mais conveniente. Após criados os arquivos, basta adicionar a linha para importá-los no arquivoassets/sass/source/main.sass. Fazendo isso, todos os estilos, mesmo escritos em arquivos separados, serão transformados em um único arquivo minificado de CSS.

Caso seja necessário, por questões de performance, produzir mais de um arquivo .css para poder carregar estilos dinamicamente, basta criar mais um arquivo .sass na pasta assets/sass/source e importar os arquivos neccessários da mesma forma que no arquivomain.sass. Cada arquivo .sass na pasta assets/sass/source irá gerar um arquivo .css de mesmo nome na pasta assets/css.

É por isso que não se deve versionar a pasta assets/css: cada vez que se faz um deploy, o que interessa são os estilos escritos, ou seja, os arquivos .sass. Sempre que se manda estilos para outros ambientes, o SASS deve ser compilado novamente para gerar CSS atualizado.

Outros recursos de SASS, como definições de variáveis, placeholders, mixins, etc., devem ficar na pasta assets/sass/library. Nesta pasta há alguns subdiretórios para organizar tais recursos. Em cada um deles há um arquivo README explicando seus propósitos. Todos os arquivos criados na library são automaticamente importados no arquivo assets/sass/source/main.sass, não havendo necessidade de declará-los um por um (isso não é feito com os arquivos da pastaassets/partials porque estes últimos são os responsáveis por gerar CSS, então devem ser importados individualmente de acordo com a necessidade).

Com as orientações acima, já é possível começar a escrever estilos seguindo várias boas práticas consolidadas na comunidade. Na sequência, assuntos mais avançados serão tratados para dar continuidade ao trabalho aqui iniciado.

Sair da versão mobile