Gerenciando a explosão de CSS

Confio muito em CSS para um site em que estou trabalhando. No momento, todos os estilos CSS estão sendo aplicados por tag e, agora, estou tentando movê-lo para um estilo externo, para ajudar em futuras alterações.

Mas agora o problema é que notei que estou recebendo uma "Explosão CSS". Está ficando difícil para mim decidir como organizar e abstrair melhor os dados no arquivo CSS.

Estou usando um grande número de divtags no site, saindo de um site fortemente baseado em tabela. Então, eu estou recebendo muitos seletores de CSS parecidos com este:

div.title {
  background-color: blue;
  color: white;
  text-align: center;
}

div.footer {
  /* Styles Here */
}

div.body {
  /* Styles Here */
}

/* And many more */

Ainda não é tão ruim, mas como sou iniciante, fiquei pensando se poderiam ser feitas recomendações sobre a melhor forma de organizar as várias partes de um arquivo CSS. Não quero ter um atributo CSS separado para cada elemento do meu site e sempre quero que o arquivo CSS seja bastante intuitivo e fácil de ler.

Meu objetivo final é facilitar o uso dos arquivos CSS e demonstrar seu poder de aumentar a velocidade do desenvolvimento da web. Dessa forma, outras pessoas que possam trabalhar neste site no futuro também entrarão na prática do uso de boas práticas de codificação, em vez de precisarem aprender da maneira que eu fiz.

Esta é uma pergunta muito boa. Em todos os lugares em que olho, os arquivos CSS tendem a ficar fora de controle depois de um tempo - especialmente, mas não apenas, quando se trabalha em equipe.

A seguir, estão as regras que eu mesmo estou tentando seguir (não que eu sempre consiga.)

• Refatorar cedo, refatorar com freqüência. Limpe com freqüência os arquivos CSS, junte várias definições da mesma classe. Remova definições obsoletas imediatamente .

• Ao adicionar CSS durante a correção de erros, deixe um comentário sobre o que a alteração faz ("Isso é para garantir que a caixa fique alinhada no IE <7")

• Evite redundâncias, por exemplo, definindo a mesma coisa em .classnamee .classname:hover.

• Use comentários /** Head **/para criar uma estrutura clara.

• Use uma ferramenta de pré-modificação que ajude a manter um estilo constante. Eu uso o Polystyle , com o qual estou muito feliz (custa US $ 15, mas é dinheiro bem gasto). Existem outros gratuitos também (por exemplo, Code Beautifier baseado no CSS Tidy , uma ferramenta de código-fonte aberto).

• Crie classes sensatas. Veja abaixo algumas notas sobre isso.

• Use semântica, evite sopa DIV - use <ul>s para menus, por exemplo.

• Defina tudo no nível mais baixo possível (por exemplo, uma família de fontes padrão, cor e tamanho body) e use sempre inheritque possível

• Se você possui CSS muito complexo, talvez um pré-compilador CSS o ajude. Estou planejando analisar o xCSS pelo mesmo motivo em breve. Existem vários outros por aí.

• Se estiver trabalhando em equipe, destaque também a necessidade de qualidade e padrões para arquivos CSS. Todo mundo gosta muito de padrões de codificação em sua (s) linguagem (s) de programação, mas há pouca consciência de que isso também é necessário para CSS.

• Se trabalhar em uma equipe, não considerar o uso de controle de versão. Torna as coisas muito mais fáceis de rastrear e a edição de conflitos muito mais fáceis de resolver. Realmente vale a pena, mesmo se você é "apenas" em HTML e CSS.

• Não trabalhe com !important. Não apenas porque o IE = <7 não pode lidar com isso. Em uma estrutura complexa, o uso de !importantmuitas vezes é tentador para mudar um comportamento cuja fonte não pode ser encontrada, mas é veneno para manutenção a longo prazo.

Construindo classes sensíveis

É assim que eu gosto de criar classes sensatas.

Aplico as configurações globais primeiro:

body { font-family: .... font-size ... color ... }
a { text-decoration: none; }

Depois, identifico as principais seções do layout da página - por exemplo, a área superior, o menu, o conteúdo e o rodapé. Se eu escrevi uma boa marcação, essas áreas serão idênticas à estrutura HTML.

Então, começo a criar classes CSS, especificando o máximo de ancestralidade possível, desde que seja sensato, e agrupando as classes relacionadas o mais próximo possível.

div.content ul.table_of_contents 
div.content ul.table_of_contents li 
div.content ul.table_of_contents li h1
div.content ul.table_of_contents li h2
div.content ul.table_of_contents li span.pagenumber

Pense em toda a estrutura CSS como uma árvore com definições cada vez mais específicas, mais distantes da raiz que você é. Você deseja manter o número de aulas o mais baixo possível e deseja repetir-se o mais raramente possível.

Por exemplo, digamos que você tenha três níveis de menus de navegação. Esses três menus parecem diferentes, mas também compartilham certas características. Por exemplo, são todos <ul>, todos têm o mesmo tamanho de fonte e os itens são todos próximos um do outro (em oposição à renderização padrão de um ul). Além disso, nenhum dos menus possui pontos de marcador ( list-style-type).

Primeiro, defina as características comuns em uma classe chamada menu:

div.navi ul.menu { display: ...; list-style-type: none; list-style-image: none; }
div.navi ul.menu li { float: left }

em seguida, defina as características específicas de cada um dos três menus. O nível 1 tem 40 pixels de altura; níveis 2 e 3, 20 pixels.

Nota: você também pode usar várias classes para isso, mas o Internet Explorer 6 tem problemas com várias classes ; portanto, este exemplo usa ids.

div.navi ul.menu#level1 { height: 40px; }
div.navi ul.menu#level2 { height: 20px; }
div.navi ul.menu#level3 { height: 16px; }

A marcação para o menu ficará assim:

<ul id="level1" class="menu"><li> ...... </li></ul>
<ul id="level2" class="menu"><li> ...... </li></ul>
<ul id="level3" class="menu"><li> ...... </li></ul>

Se você tiver elementos semanticamente semelhantes na página - como esses três menus - tente descobrir os pontos comuns primeiro e colocá-los em uma classe; depois, elabore as propriedades específicas e aplique-as às classes ou, se você precisar dar suporte aos IDs do Internet Explorer 6.

Dicas HTML diversas

Se você adicionar essas semânticas à sua saída HTML, os designers poderão personalizar posteriormente a aparência de sites e / ou aplicativos usando CSS puro, o que é uma grande vantagem e economiza tempo.

• Se possível, forneça uma classe única ao corpo de cada página: <body class='contactpage'>isso facilita a adição de ajustes específicos da página à folha de estilos:

  body.contactpage div.container ul.mainmenu li { color: green }

• Ao criar menus automaticamente, adicione o máximo de contexto CSS possível para permitir um estilo extenso posteriormente. Por exemplo:

  <ul class="mainmenu">
   <li class="item_first item_active item_1"> First item </li> 
   <li class="item_2"> Second item </li> 
   <li class="item_3"> Third item </li> 
   <li class="item_last item_4"> Fourth item </li> 
  </ul>
  

  Dessa forma, todos os itens de menu podem ser acessados ​​para estilizar de acordo com seu contexto semântico: se é o primeiro ou o último item da lista; Se é o item atualmente ativo; e por número.

Observe que essa atribuição de várias classes, conforme descrito no exemplo acima , não funciona corretamente no IE6 . Existe uma solução alternativa para tornar o IE6 capaz de lidar com várias classes. Se a solução alternativa não for uma opção, você deverá definir a classe que é mais importante para você (número do item, ativo ou primeiro / último) ou recorrer ao uso de IDs.

Aqui estão apenas 4 exemplos:

• Convenções CSS / Modelos de layout de código
• Existem padrões de CSS que devo seguir ao escrever minha primeira folha de estilo?
• Qual é o melhor método para arrumar CSS?
• Práticas recomendadas - Formatação de folha de estilo CSS

Nos quatro, minha resposta incluiu o conselho de baixar e ler os PDF CSS Systems de Natalie Downe . (O PDF inclui várias notas que não estão nos slides, então leia o PDF!). Tome nota das sugestões dela para organização.

EDIT (2014/02/05) quatro anos depois, eu diria:

• Use um pré-processador CSS e gerencie seus arquivos como parciais (eu pessoalmente prefiro o Sass with Compass, mas Menos também é muito bom e existem outros)
• Leia conceitos como OOCSS , SMACSS e BEM ou getbem .
• Veja como estruturas CSS populares, como o Bootstrap e o Zurb Foundation, estão estruturadas. E não descarte estruturas menos populares - o Inuit é interessante, mas existem muitas outras.
• Combine / minifique seus arquivos com uma etapa de compilação em um servidor de integração contínua e / ou em um executor de tarefas como Grunt ou Gulp.

Não escreva títulos em CSS

Apenas divida as seções em arquivos. Qualquer comentário CSS, deve ser apenas isso, comentários.

reset.css
base.css
somepage.css
someotherpage.css
some_abstract_component.css

Use um script para combiná-los em um; se necessário. Você também pode ter uma boa estrutura de diretórios e fazer com que seu script procure recursivamente .cssarquivos.

Se você precisar escrever títulos, tenha um sumário no início do arquivo

Os títulos no sumário devem ser perfeitamente iguais aos títulos que você escrever mais tarde. É doloroso procurar títulos. Para adicionar ao problema, como exatamente alguém deve saber que você tem outro cabeçalho após o primeiro cabeçalho? ps. não adicione documentos * (estrela) no início de cada linha ao escrever TOCs, apenas torna mais irritante selecionar o texto.

/* Table of Contents
   - - - - - - - - -
   Header stuff
   Body Stuff
   Some other junk
   - - - - - - - - -
 */
...
/* Header Stuff 
 */
...
/* Body Stuff 
 */

Escreva comentários com ou dentro das regras, fora do bloco

Primeiro, quando você edita o script, há uma chance de 50/50 de prestar atenção ao que está fora do bloco de regras (principalmente se for uma grande quantidade de texto;)). Em segundo lugar, não há (quase) nenhum caso em que você precise de um "comentário" do lado de fora. Se estiver fora, é 99% das vezes um título, então mantenha-o assim.

Dividir a página em componentes

Os componentes devem ter position:relative, não paddinge não margin, na maioria das vezes. Isto simplifica% governa um monte, bem como permitindo muito mais simples absolute:position'ing de elementos, uma vez que se há um recipiente posicionado absoluto o elemento posicionado absoluta usará o recipiente quando computação top, right, bottom, leftpropriedades.

A maioria dos DIVs em um documento HTML5 geralmente é um componente.

Um componente também é algo que pode ser considerado uma unidade independente na página. Em termos de leigos, tratam algo como um componente se faz sentido tratar algo como uma caixa preta .

Indo com o exemplo da página QA novamente:

#navigation
#question
#answers
#answers .answer
etc.

Ao dividir a página em componentes, você divide seu trabalho em unidades gerenciáveis.

Coloque regras com efeito cumulativo na mesma linha.

Por exemplo border, margine padding(mas não outline), todos aumentam as dimensões e o tamanho do elemento que você está estilizando.

position: absolute; top: 10px; right: 10px;

Se eles não são tão legíveis em uma linha, pelo menos os coloque bem próximos:

padding: 10px; margin: 20px;
border: 1px solid black;

Use taquigrafia quando possível:

/* the following... */
padding-left: 10px;
padding-right: 10px;
/* can simply be written as */
padding: 0 10px;

Nunca repita um seletor

Se você tiver mais instâncias do mesmo seletor, é provável que você acabe inevitavelmente com várias instâncias das mesmas regras. Por exemplo:

#some .selector {
    margin: 0;
    font-size: 11px;
}
...
#some .selector {
    border: 1px solid #000;
    margin: 0;
}

Evite usar TAGs como seletores, quando você puder usar id / classes

Primeiro, as tags DIV e SPAN são a exceção: você nunca deve usá-las! ;) Use-os apenas para anexar uma classe / ID.

Este...

div#answers div.answer table.statistics {
    border-collapse: collapsed;
    color: pink;
    border: 1px solid #000;
}
div#answers div.answer table.statistics thead {
    outline: 3px solid #000;
}

Deve ser escrito assim:

#answers .answer .statistics {
    border-collapse: collapsed;
    color: pink;
    border: 1px solid #000;
}
#answers .answer .statistics thead {
    outline: 3px solid #000;
}

Como os DIVs pendentes extras não adicionam nada ao seletor. Eles também forçam uma regra de tag desnecessária. Se você mudasse, por exemplo, .answerde um divpara um, articleseu estilo seria quebrado.

Ou se você preferir mais clareza:

#answers .answer .statistics {
    color: pink;
    border: 1px solid #000;
}
#answers .answer table.statistics {
    border-collapse: collapsed;
}
#answers .answer .statistics thead {
    outline: 3px solid #000;
}

A razão de ser a border-collapsepropriedade é uma propriedade especial que só faz sentido quando aplicada a a table. Se .statisticsnão é um table, não deve ser aplicado.

Regras genéricas são más!

• evite escrever regras genéricas / mágicas se puder
• a menos que seja para redefinição / redefinição de CSS, toda a sua mágica genérica deve ser aplicada a pelo menos um componente raiz

Eles não economizam seu tempo, fazem sua cabeça explodir; além de tornar a manutenção um pesadelo. Ao escrever a regra, você pode saber onde elas se aplicam, no entanto, isso não garante que sua regra não irá mexer com você mais tarde.

Para adicionar a isso, regras genéricas são confusas e difíceis de ler, mesmo se você tiver alguma idéia do documento que está estilizando. Isso não quer dizer que você não deve escrever regras genéricas, apenas não as use, a menos que realmente pretenda que sejam genéricas, e mesmo elas adicionem o máximo possível de informações de escopo ao seletor.

Coisas assim ...

.badges {
    width: 100%;
    white-space: nowrap;
}

address {
    padding: 5px 10px;
    border: 1px solid #ccc;
}

... tem o mesmo problema que o uso de variáveis ​​globais em uma linguagem de programação. Você precisa dar a eles espaço!

#question .userinfo .badges {
    width: 100%;
    white-space: nowrap;
}

#answers .answer .userinfo address {
    padding: 5px 10px;
    border: 1px solid #ccc;
}

Basicamente, lê-se como:

components                   target
---------------------------- --------
#answers .answer   .userinfo address
-------- --------- --------- --------
domain   component component selector 

Gosto de usar IDs sempre que um componente que conheço é um singleton em uma página; suas necessidades podem ser diferentes.

Nota: Idealmente, você deve escrever apenas o suficiente. Mencionar mais componentes no seletor, no entanto, é o erro mais perdoador, comparado a mencionar menos componentes.

Vamos supor que você tenha um paginationcomponente. Você o usa em muitos lugares do seu site. Este seria um bom exemplo de quando você escreveria uma regra genérica. Digamos que você vincule display:blocko número da página individual e forneça a eles um plano de fundo cinza escuro. Para que eles sejam visíveis, você precisa ter regras como esta:

.pagination .pagelist a {
    color: #fff;
}

Agora, digamos que você use sua paginação para obter uma lista de respostas, você pode encontrar algo parecido com isto

#answers .header a {
    color: #000;
}
...
.pagination .pagelist a {
    color: #fff;
}

Isso tornará os links brancos em preto, o que você não deseja.

A maneira incorreta de corrigi-lo é:

.pagination .pagelist a {
    color: #fff !important;
}

A maneira correta de corrigi-lo é:

#answers .header .pagination .pagelist a {
    color: #fff;
}

Comentários "lógicos" complexos não funcionam :)

Se você escrever algo como: "esse valor depende de blá-blá combinado com a altura do blá-blá", é inevitável que você cometa um erro e tudo cairá como um castelo de cartas.

Mantenha seus comentários simples; se você precisar de "operações lógicas", considere uma dessas linguagens de modelagem CSS, como SASS ou LESS .

Como você escreve um palete de cores?

Deixe isso para o fim. Tenha um arquivo para todo o palete de cores. Sem esse arquivo, seu estilo ainda deve ter algumas paletas de cores utilizáveis ​​nas regras. Seu palete de cores deve substituir. Você encadeia seletores usando um componente pai de nível muito alto (por exemplo #page) e depois escreve seu estilo como um bloco de regras auto-suficiente. Pode ser apenas cor ou algo mais.

por exemplo.

#page #header .description,
#page #categories .description,
#page #answers .answer .body
{
    color: #222; background: #fff; 
    border-radius: 10px;
    padding: 1em;
}

A idéia é simples: seu palete de cores é uma folha de estilo independente do estilo base, no qual você cascata .

Menos nomes, requer menos memória, facilitando a leitura do código

Usar menos nomes é melhor. Idealmente, use palavras muito simples (e curtas!): Texto, corpo, cabeçalho.

Eu também acho que a combinação de palavras simples é mais fácil de entender do que tomar uma sopa longa de palavras "apropriadas": corpo de post, cabeçalho, informações do usuário etc.

Mantenha o vocabulário pequeno, dessa maneira, mesmo que algum estranho que esteja lendo sua sopa de estilo (como você depois de algumas semanas;)) precise entender apenas onde as palavras são usadas e onde todos os seletores são usados. Por exemplo, eu uso .thissempre que um elemento é supostamente "o item selecionado" ou "o item atual" etc.

Limpe depois de si mesmo

Escrever CSS é como comer, às vezes você deixa uma bagunça para trás. Certifique-se de limpar a bagunça, ou o código do lixo ficará acumulado. Remova as classes / IDs que você não usa. Remova as regras CSS que você não usa. Verifique se tudo está bem e que você não tem regras conflitantes ou duplicadas.

Se você, como sugeri, tratou alguns contêineres como caixas-pretas (componentes) em seu estilo, usou esses componentes em seus seletores e manteve tudo em um arquivo dedicado (ou dividiu adequadamente um arquivo com um sumário e cabeçalhos), o trabalho é substancialmente mais fácil ...

Você pode usar uma ferramenta como a extensão do firefox Dust-Me Selectors (dica: aponte-o para o seu sitemap.xml) para ajudá-lo a encontrar alguns dos itens ocultos nos seus munições e bombas css.

Mantenha um unsorted.cssarquivo

Digamos que você esteja criando um site de controle de qualidade e já tenha uma folha de estilo para a "página de respostas", a qual chamaremos answers.css. Se você agora precisa adicionar muitos css novos, adicione-o à unsorted.cssfolha de estilo e refatorá-lo answers.css.

Várias razões para isso:

• é mais rápido refatorar depois que você terminar, é procurar regras (que provavelmente não existem) e injetar código
• você escreverá as coisas que removerá, injetar código apenas dificulta a remoção desse código
• anexar ao arquivo original facilmente leva à duplicação de regra / seletor

Veja 1. SASS 2. Compass

A melhor maneira que eu já vi para combater o CSSinchaço é usar os princípios CSS orientados a objetos.

Existe até uma estrutura OOCSS por aí que é muito boa.

Algumas das ideologias vão contra muito do que foi dito aqui nas respostas principais, mas depois que você souber como arquitetar CSSde maneira orientada a objetos, verá que realmente funcionará para manter o código enxuto e mesquinho.

A principal coisa aqui é identificar 'Objetos' ou padrões de blocos de construção em seu site e arquitetar com eles.

O Facebook contratou a criadora do OOCSS, Nicole Sullivan, para obter muitas economias em seu código de front-end (HTML / CSS). Sim, você pode realmente obter economias não só no seu CSS, mas em seu HTML também, que pelo som dela, é muito possível para você como você menciona a conversão de um tablelayout com base em um monte de div's

Outra ótima abordagem é semelhante em alguns aspectos ao OOCSS, é planejar e escrever seu CSS para ser escalável e modular desde o início. Jonathan Snook fez um brilhante escrever e reservar / ebook sobre SMACSS - Arquitetura Modular e Escalável para CSS

Deixe-me ligar para você com alguns links:
5 erros de CSS maciço - (Vídeo)
5 erros de CSS maciço - (Slides)
CSS Bloat - (Slides)

Você também deve entender a cascata, o peso e como eles funcionam.

Percebo que você está usando apenas identificadores de classe (div.title). Você sabia que também pode usar IDs e que um ID tem mais peso que uma classe?

Por exemplo,

#page1 div.title, #page1 ul, #page1 span {
  // rules
}

fará com que todos esses elementos compartilhem um tamanho de fonte, digamos, uma cor ou quaisquer que sejam suas regras. Você pode até fazer com que todos os DIVs descendentes de # página1 obtenham determinadas regras.

Quanto ao peso, lembre-se de que os eixos CSS passam do mais geral / mais leve para o mais específico / mais pesado. Ou seja, em um seletor CSS, um especificador de elemento é substituído por um especificador de classe, por um especificador de ID. Os números contam, portanto, um seletor com dois especificadores de elemento (ul li) terá mais peso do que um com apenas um único especificador (li).

Pense nisso como dígitos. Um 9 na coluna unidades ainda é menor que um na coluna dezenas. Um seletor com um especificador de ID, um especificador de classe e dois especificadores de elemento terá mais peso do que um seletor sem ID, 500 especificadores de classe e 1.000 especificadores de elemento. Este é um exemplo absurdo, é claro, mas você entendeu. O ponto é que a aplicação desse conceito ajuda a limpar muito CSS.

BTW, adicionar o especificador de elemento à classe (div.title) não é necessário, a menos que você esteja enfrentando conflitos com outros elementos que possuem class = "title". Não adicione peso desnecessário, pois pode ser necessário usá-lo mais tarde.

Posso sugerir uma estrutura menos dinâmica do CSS

É semelhante ao SASS, como mencionado anteriormente.

Ajuda a manter o CSS por classe pai.

Por exemplo

 #parent{     
  width: 100%;

    #child1
    {    
     background: #E1E8F2;    
     padding: 5px;    
    }

    #child2
   {
     background: #F1F8E2;
     padding: 15px
   }
 }

O que isso faz: Aplica largura: 100% a # child1 e # child2.

Além disso, o CSS específico # child1 pertence a #parent.

Isso renderia a

#parent #child1
{
 width: 100%;
 background: #E1E8F2;
 padding: 5px;
}

#parent #child2
{
 width: 100%;
 background: #F1F8E2;
 padding: 15px;
}

Acho que o difícil é traduzir o design necessário para um site em uma série de regras. Se o design do site for claro e baseado em regras, os nomes das classes e a estrutura CSS poderão resultar disso. Mas se, com o tempo, as pessoas adicionam aleatoriamente pequenos bits ao site que não fazem muito sentido, não há muito o que fazer no CSS.

Costumo organizar meus arquivos CSS mais ou menos assim:

1. Redefinição de CSS, com base em Eric Meyer . (Porque, caso contrário, acho que, para a maioria dos elementos, tenho pelo menos uma ou duas regras que estão apenas redefinindo os estilos padrão do navegador - a maioria das minhas listas não se parece com o estilo HTML padrão das listas, por exemplo.)

2. CSS do sistema de grade, se o site solicitar. ( Baseio o meu em 960.gs )

3. Estilos para componentes que aparecem em todas as páginas (cabeçalhos, rodapés etc.)

4. Estilos para componentes usados ​​em vários locais do site

5. Estilos relevantes apenas em páginas individuais

Como você pode ver, a maior parte disso depende do design do site. Se o design é claro e organizado, seu CSS pode ser. Caso contrário, você está ferrado.

Minha resposta é de alto nível para abordar as preocupações de alto nível que você levantou em sua pergunta. Pode haver truques organizacionais de baixo nível e ajustes que você pode fazer para torná-lo mais bonito, mas nenhum deles pode corrigir deficiências metodológicas. Há várias coisas que afetam a explosão do CSS. Obviamente, a complexidade geral do site, mas também coisas como semântica de nomes, desempenho de CSS, organização de arquivos CSS e testabilidade / aceitabilidade.

Você parece estar no caminho certo com a semântica de nomes, mas pode ser um passo adiante. Seções de HTML que aparecem repetidamente no site sem modificação estrutural (conhecidas como "módulos") podem ser consideradas raízes seletoras e, a partir daí, você pode definir o escopo do layout interno relativo a essa raiz. Esse é o princípio básico do CSS orientado a objetos , e você pode ler / assistir mais sobre isso nesta palestra por um engenheiro do Yahoo .

É importante observar que essa abordagem limpa pode ser oposta à preocupação com o desempenho, o que favorece seletores curtos com base no ID ou no nome da tag . Encontrar esse equilíbrio depende de você, mas, a menos que você tenha um site gigantesco, isso deve ser apenas um guia na parte de trás da sua cabeça, lembrando que você deve manter seus seletores curtos. Mais sobre desempenho aqui .

Por fim, você terá um único arquivo CSS para todo o site ou vários arquivos (um único arquivo base usado com arquivos por página ou por seção)? O arquivo único é melhor para o desempenho, mas pode ser mais difícil de entender / manter com vários membros da equipe e mais difícil de testar. Para testar, recomendo que você tenha uma única página de teste CSS que inclua todos os módulos CSS suportados para testar colisões e cascatas indesejadas.

Como alternativa, você pode ter uma abordagem de vários arquivos , para definir as regras de CSS para uma página ou seção. Isso requer que o navegador baixe vários arquivos, o que é um problema de desempenho. Você pode usar a programação do lado do servidor para especificar e agregar (e minificar) os arquivos CSS em um único arquivo dinamicamente. Porém, como esses arquivos são separados e os testes para eles seriam separados, você apresenta a possibilidade de aparência inconsistente nas páginas / seções. Assim, o teste se torna mais difícil.

Cabe a você analisar as necessidades específicas do cliente, equilibrar essas preocupações de acordo.

Como disse antes de mim: Entre no OOCSS. O Sass / Less / Compass é tentador de usar, mas até que o CSS vanilla seja usado da maneira certa, o Sass / Less / Compass só piorará as coisas.

Primeiro de tudo, leia sobre CSS eficiente. experimente o Google Page Speed ​​e leia o que Souders escreveu sobre CSS eficiente.

Em seguida, insira OOCSS.

• Aprenda a trabalhar com a cascata. (Afinal, chamamos de folhas de estilo em cascata ).
• Aprenda como obter a granularidade correta (de baixo para cima, em vez de cima para baixo)
• Aprenda a separar estrutura e capa (o que é único e quais são as variações desses objetos?)
• Aprenda a separar contêiner e conteúdo.
• Aprenda a amar grades.

Ele vai revolucionar tudo sobre como escrever css. Estou totalmente renovado e adoro.

ATUALIZAÇÃO: O SMACSS é semelhante ao OOCSS, mas mais fácil de se adaptar em geral.

Os princípios básicos para CSS sensível, extraídos da refatoração de CSS: do CSS somente de anexo ao modular

Escreva no SASS. Você seria insano em abrir mão das vantagens de variáveis, mixins e assim por diante.

Nunca use um ID HTML para estilizar; sempre use classes . Os IDs HTML, quando usados ​​corretamente, aparecem apenas uma vez na página inteira, que é o oposto completo da reutilização - um dos itens mais básicos em engenharia sensata. Além disso, é realmente difícil substituir seletores que contêm IDs e, geralmente, a única maneira de substituir um ID HTML é criar outro ID, fazendo com que os IDs se propaguem na base de código como as pragas que são. Melhor deixar os IDs HTML para Javascript inalterável ou ganchos de teste de integração.

Nomeie suas classes CSS pela função visual, e não pela função específica do aplicativo. Por exemplo, diga ".highlight-box" em vez de ".bundle-product-discount-box". Codificar dessa maneira significa que você pode reutilizar suas folhas de estilo existentes quando desempenhar funções secundárias. Por exemplo, começamos a vender notas de direito, mas recentemente nos mudamos para tutores de direito. Nossas antigas classes CSS tinham nomes como ".download_document_box", um nome de classe que faz sentido quando se fala em documentos digitais, mas só confunde quando aplicado ao novo domínio de professores particulares. Um nome melhor que atenda aos serviços existentes - e aos futuros - seria ".pretty_callout_box".

Evite nomear classes CSS após informações específicas da grade. Havia (e ainda existe) um antipadrão terrível nas comunidades de CSS em que os designers e criadores de estruturas de CSS (tosse Twitter Bootstrap ) acreditam que "span-2" ou "cols-8" são nomes razoáveis ​​para as classes CSS. O objetivo do CSS é oferecer a possibilidade de modificar seu design sem afetar a marcação (muito). A codificação codificada do tamanho das grades no HTML impede esse objetivo, portanto, é desaconselhado em qualquer projeto que dure mais que um fim de semana. Mais sobre como evitamos as classes de grade posteriormente.

Divida seu CSS entre arquivos . Idealmente, você dividiria tudo em "componentes" / "widgets" e depois comporia páginas desses átomos de design. Realisticamente, porém, você notará que algumas das páginas do seu site têm idiossincrasias (por exemplo, um layout especial ou uma galeria de fotos estranha que aparece em apenas um artigo). Nesses casos, você pode criar um arquivo relacionado a essa página específica, refatorando-o apenas em um widget completo quando ficar claro que o elemento será reutilizado em outro lugar. Essa é uma troca, motivada por preocupações orçamentárias práticas.

Minimize o aninhamento. Introduzir novas classes em vez de aninhar seletores. O fato de o SASS remover a dor de repetir seletores ao aninhar não significa que você precisa aninhar cinco níveis de profundidade. Nunca super-qualifique um seletor (por exemplo, não use "ul.nav" onde ".nav" possa fazer o mesmo trabalho.) E não especifique elementos HTML ao lado do nome da classe personalizada (por exemplo, "h2.highlight"). Em vez disso, basta usar o nome da classe sozinho e soltar o seletor de base (por exemplo, o exemplo anterior deve ser ".highlight"). Seletores superqualificados não agregam valor.

Crie estilos para elementos HTML (por exemplo, "h1") somente ao estilizar componentes básicos que devem ser consistentes em todo o aplicativo. Evite seletores amplos como "cabeçalho ul", pois é provável que você precise substituí-los em alguns lugares de qualquer maneira. Como continuamos dizendo, na maioria das vezes você deseja usar uma classe específica e bem nomeada sempre que quiser um estilo específico.

Adote o básico do modificador de elemento de bloco. Você pode ler sobre isso, por exemplo, aqui. Nós o usamos de ânimo leve, mas ainda assim nos ajudou muito na organização de estilos CSS.

Muitas vezes, vejo pessoas dividindo o arquivo em seções, com um comentário no cabeçalho entre as seções.

Algo como

/* Headings and General Text */

.... stuff here for H1, etc..

/* Main page layout */

.... stuff here for layout page setup etc.

Funciona muito bem e pode facilitar a volta mais tarde e encontrar o que você está trabalhando.

Você deve olhar para o BEM .

Teoria

O BEM é uma tentativa de fornecer um conjunto de instruções para organizar e nomear seletores de css, na tentativa de tornar as coisas mais reutilizáveis ​​e modulares e evitar conflitos entre os seletores do tipo que geralmente leva a códigos de espaguete e dores de cabeça de especificidade.

Quando usado corretamente, na verdade tem alguns efeitos muito positivos.

• Os estilos fazem o que você espera quando adicionados a um elemento
• Os estilos não vazam e afetam apenas o que foram adicionados
• Os estilos são completamente dissociados da estrutura do documento
• Os estilos não precisam ser forçados a se sobrepor

O BEM funciona bem com o SASS para trazer um estilo quase orientado a objetos para CSS. Você pode criar arquivos modulares, que manipulam a exibição de um único elemento da interface do usuário e contêm variáveis, como cores e 'métodos', como a forma como os elementos internos são manipulados. Embora um programador hardcore de OO possa se opor a essa idéia, de fato, os conceitos aplicados trazem muitas partes mais agradáveis ​​das estruturas de OO, como modularidade, acoplamento flexível e coesão rígida e reutilização sem contexto. Você pode até construir de uma maneira que se pareça com um objeto encapsulado usando Sass e o &operador .

Um artigo mais detalhado da Smashing Magazine pode ser encontrado aqui ; e um de Harry Roberts, da CCS Wizardry (quem qualquer pessoa envolvida em CSS deveria ter lido) está aqui .

Na prática

Eu usei isso várias vezes, além de ter usado SMACSS e OOCSS, o que significa que também tenho algo para compará-los. Eu também trabalhei em algumas grandes bagunças, muitas vezes por minha própria criação, inexperiente.

Quando uso o BEM no mundo real, aprimoro a técnica com alguns princípios extras. Utilizo classes de utilidade - um bom exemplo é uma classe de wrapper:

.page-section {
    width: 100%;
}
@media screen and (min-width: 1200px) {
    margin: 0 auto;
    width: 1200px;
}

E também confio um pouco na cascata e na especificidade. Aqui o módulo BEM seria .primary-boxe .headerseria o contexto para uma substituição específica

.header {
  .primary-box {
    color: #000;
  }
}

(Esforço-me ao máximo para tornar tudo o mais genérico e livre de contexto possível, o que significa que um bom projeto quase tudo está nos módulos que são reutilizáveis)

Um ponto final que eu colocaria aqui é que, por mais pequeno e complexo que o seu projeto possa parecer, você deve fazer isso desde o início, por dois motivos:

• projetos aumentam em complexidade, por isso é importante estabelecer boas fundações, incluindo css
• até mesmo um projeto que parece simples porque é construído no WordPress com pouco JavaScript ainda pode ser muito complexo no CSS - OK, você não precisa fazer nenhuma codificação no servidor, de modo que a parte é simples, mas o front-end de brochura tem vinte módulos e três variações de cada um: você tem alguns css muito complexos lá!

Componentes da Web

Em 2015, começamos a analisar os Web Components. Ainda não sei muito sobre isso, mas eles procuram reunir todas as funcionalidades do front-end em módulos independentes, tentando efetivamente aplicar os tipos de princípios do BEM ao front-end como um todo e componentes dispersos, mas totalmente acoplados elementos como fragmentos do DOM, Js (MVC) e CSS que constroem o mesmo widget da interface do usuário.

Ao fazer isso, eles abordarão alguns dos problemas originais que existem com o css, que tentamos resolver com coisas como o BEM, ao longo do caminho, tornando algumas das outras arquiteturas de front-end mais sãs.

Há algumas leituras adicionais aqui e também um quadro Polymer aqui que vale a pena dar uma olhada

Finalmente

Também acho que este é um excelente e moderno guia de práticas recomendadas em CSS - projetado especificamente para impedir que grandes projetos de CSS fiquem confusos. Eu tento seguir a maioria deles.

Eu recomendo que você analise a estrutura CSS "Compass Style" .

existe algum material excelente aqui e alguns levaram muito tempo para responder a essa pergunta, no entanto, quando se trata de folhas de estilo separadas ou individuais, eu usaria arquivos separados para desenvolvimento e depois passava a ter todos os seus css genéricos usados ​​em todo o site mesclado em um único arquivo quando implantado.

Dessa forma, você tem o melhor dos dois mundos, aumenta o desempenho (menos solicitações de HTTP sendo solicitadas pelo navegador) e separa os problemas de código durante o desenvolvimento.