Já sabemos que se tratando de CSS, apesar da escrita ser muito simples, há uma série de armadilhas. Começamos não utilizando !important ou tags para estilização, considerando o peso dos seletores e adotando um code standard. Mas ainda não damos tanta atenção para a arquitetura que está intimamente ligada a futuros conflitos. Um conflito de CSS é fruto de código mal escrito que cancela regras ou as aplicada em porções inadequadas do layout.
Saiba que não se trata de aprender algumas técnicas a mais, antes que alguém deixe um dos muito comentários infelizes que figuram em outros textos do assunto, trata-se essencialmente de reconhecer soluções para um problema pertinente e comum. É preciso pensar como organizar nosso código CSS. Melhor ainda, devemos planejar qual será a o estilo de arquitetura da nossa folha de estilo.
Conceitos básicos
A experiência nos mostra aquilo que Phil Karlton já dizia: uma das tarefas mais árduas da computação é a de nomear coisas. E isto é o que fazemos o tempo todo quando escrevemos CSS, definir quais serão nossos seletores. Esta tarefa envolve organização, padronização, planejar reutilização e uma série de outras disciplinas.
Um ponto pertinente é compreendermos o significado de semântica, que define a relação entre símbolos e seu significado, neste contexto. Nicolas Gallagher escreveu um texto sensacional sobre semântica no HTML e sua não relação com semântica da arquitetura do front-end. A semântica das tags do HTML e Microdata está muito bem definida nas especificações e deve ser respeitada. Através dela é possível para humanos e máquinas melhor interpretar as informações contidas em um documento.
Por outro lado, ao contrário daquilo que muitos pensam, não há nenhuma semântica a ser seguida quando atribuímos classes a um elemento. Não existe classe não semântica, já que seu significado deve ser estabelecido em cada projeto.
Object Oriented CSS
O conteúdo de um website geralmente é bem específico em cada uma das páginas. É pouco comum que o mesmo conteúdo se manifeste em diferentes seções de um projeto. Portanto, classes nomeadas com base no conteúdo são bastante difíceis de serem reusadas.
Segundo o OOCSS, um objeto de CSS é todo padrão visual que pode se repetir no projeto e é identificado através de uma classe. O estilo enfatiza a separação de propriedades de estrutura e de skin. Propriedades como background, color e border, quando fizerem parte da identidade visual do projeto, são consideras parte do skin e devem ser agrupadas em classes próprias. Observe a classe de skin anchor-icon, que define um background, utilizada juntamente com duas classes de estrutura: e Tableless.
O uso dos objetos ao longo do projeto não deve causar surpresas, o que significa que sua localização não deve interferir na sua apresentação. Isto significa não utilizar nesting de seletores. Caso sejam necessárias variações, objetos podem estender outros diretamente no HTML:
Classes como .wrapper, .image-replacement e .clearfix aparecem em alguns exemplos que aplicam este sistema. O argumento é que se tratam de classes de estrutura com um padrão que pode ser reusado. Um exemplo:
O maior ensinamento é o de utilizar classes baseadas na aparência ao invés de conteúdo ou até mesmo funcionalidade, que até pouco eu acreditava ser o ideal. Apesar dos demais conceitos serem interessantes, a documentação é vaga e não há um padrão de nomenclatura que diferencie classes de estruturação e de skins.
O sistema estabelece e é bastante baseado em cinco categorias de regras de CSS: base, layout, module, state e a pouco importante theme. As regras de base são as do tipo que não utilizam seletores com classes ou ids, as encontramos em um CSS Reset ou normalize.css. O sistema alerta sobre a agressividade dos CSS Resets mas não alerta sobre as regras deste tipo definidas no próprio projeto, ainda mais quando aplicadas a divs, spans ou headings. Regras cujos seletores não utilizam classes são globais e qualquer decisão tomada neste nível irá perpetuar por todo o projeto, cuidado.
As categorias de layout e module são bastante semelhantes. Pense no layout como elementos agregadores e geralmente únicos como header, footer e sidebar. O sistema propõe que regras de layout tenham ids ou classes com o prefixo .l- como seletores.
As regras da categoria module englobam os demais componentes da página. O sistema não encoraja o uso de elementos nos seletores, preferindo .box .title ao invés de .box h2. Ainda, o seletores como .box-title são defendidos para facilitar a leitura do HTML.
Assim como o OOCSS, o sistema repudia regras do tipo #sidebar .media onde a localização do elemento passa a ser relevante para sua apresentação. O SMACSS reforça que seja adicionada uma classe para abrigar as variações. O elemento da sidebar passa a ter a classe do módulo e também a do sub-módulo: