<
Menu

Tableless



Imagem post: OOCSS ou CSS do jeito certo

OOCSS ou CSS do jeito certo

O CSS é algo muito simples de ser escrito mas com apenas um deslize todo o código pode transformar o projeto em um inferno. Saiba como podemos evitar isso.

O conceito

Escrever CSS é fácil. Isto não deveria ser um problema, mas é. Por ser fácil os desenvolvedores acabam se esquecendo de princípios básicos, técnicas e metodologias que nos ajudam a manter o controle durante a produção. Entenda que algumas dessas metodologias não precisam ser aplicadas em sites pequenos. Por exemplo, aqui no Tableless eu não modularizo o CSS em vários arquivos por um ou dois motivos: 1) Somente eu tenho acesso ao código. 2) O site não é grande. Ele tem meia dúzia de páginas e funcionalidades.
Mas quando falamos de sites grandes (em visitação e quantidade de páginas) existem algumas restrições: velocidade de carregamento, compatibilidade entre browsers, manutenção, flexibilidade para mudanças etc. Tudo isso deve ser pensado e planejado antes de colocarmos a mão na massa. É no planejamento que iremos estruturar como serão feitas as manutenções posteriores, como iremos mudar elementos principais sem interferir no layout como um todo.

O CSS Orientado a Objeto (em inglês OOCSS – Object Oriented CSS – Sendo sincero, esse nome é muito ruim) tem como conceito técnicas que já falamos durante muito tempo, mas que como o Responsive Web Design, está ganhando força somente agora.

Princípios

O OOCSS está baseado em dois pontos cruciais que são a separação da estrutura e do visual e a independência do container em relação ao conteúdo.

Separação da estrutura e do visual

A maioria dos elementos estilizados em uma página web tem diferentes características visuais que são repetidas em diferentes contextos e situações. Algumas características são fáceis de identificar como cores, títulos, gradientes, bordas etc. Essas são características visuais. Contudo, existem também as características de estrutura, que é onde nós “montamos” os elementos, definindo tamanhos, distâncias, medidas etc. Essas características também são repetidas em diversos elementos no decorrer do site.

A ideia é que nós separemos as características visuais das características estruturais, tornando-os modulares de forma que possamos reutilizá-los em diferentes elementos tendo resultados iguais.

Imagine 3 elementos diferentes, como um botão, uma caixa de chamada e um destaque que normalmente fica na lateral do site. Eles tem características estruturais diferentes, como width, height, paddings, margins etc. Mas as características visuais são iguais, como por exemplo o border-radius, background e o box-shadow. O CSS normal ficaria assim:

.botao {
   width:100px;
   height:50px;
   text-align:center;
   font:bold 13px verdana, arial, tahoma, sans-serif;
   border-radius:10px;
   background: url(gradients.png) repeat-X center;
   box-shadow: 0 0 10px rgba(0,0,0,0.5);
}

.chamada {
   width:250px;
   float:left;
   font:bold 23px verdana, arial, tahoma, sans-serif;
   border-radius:10px;
   background: url(gradients.png) repeat-X center;
   box-shadow: 0 0 10px rgba(0,0,0,0.5);
}

.destaque {
   width:300px;
   height:250px;
   border-radius:10px;
   background: url(gradients.png) repeat-X center;
   box-shadow: 0 0 10px rgba(0,0,0,0.5);
}

Para reutilizar de forma inteligente as características iguais destes elementos e prevendo que talvez seria criado outros elementos com as mesmas características – já que o designer mantém sempre (quase sempre, né?) um padrão visual estético – é interessante que criemos uma classe que componha estas características e apliquemos essa classe nos elementos necessários. Assim:

.botao {
   width:100px;
   height:50px;
   text-align:center;
   font:bold 13px verdana, arial, tahoma, sans-serif;
}

.chamada {
   width:250px;
   float:left;
   font:bold 23px verdana, arial, tahoma, sans-serif;
}

.destaque {
   width:300px;
   height:250px;
}

.boxEffects {
   border-radius:10px;
   background: url(gradients.png) repeat-X center;
   box-shadow: 0 0 10px rgba(0,0,0,0.5);
}

Em cada elemento que necessitasse destas características visuais, basta inserir a classe .boxEffects ao elemento.

Entenda que o abuso dessa técnica pode trazer complicações. Você não vai criar uma classe para cada característica visuais e sair aplicando essas classes em tudo quanto é elemento. Você estaria voltando a 1999 onde tínhamos aquele velho problema de misturar as camadas de formatação e informação.

Independência dos containers e do conteúdo

Imagine que você crie algum estilo para a formatação de algum elemento como por exemplo um parágrafo e atrela este estilo para os parágrafos localizados no article principal:

 
article p {
   font:bold 13px verdana, arial, tahoma, sans-serif;
   line-height:18px;
   letter-spacing:1px;
}

Mas então surge a necessidade de ter um parágrafo com as mesmas características no rodapé, por exemplo, mas com o tamanho da fonte maior! Você pode fazer assim:

 
article p, footer p {
   font: 13px verdana, arial, tahoma, sans-serif;
   line-height:18px;
   letter-spacing:1px;
}

footer p {font-size:20px;}

O que é ainda é ruim, mas é muito melhor do que fazer assim:

 
article p, footer p {
   font: 13px verdana, arial, tahoma, sans-serif;
   line-height:18px;
   letter-spacing:1px;
}

footer p {
   font: 20px verdana, arial, tahoma, sans-serif;
   line-height:18px;
   letter-spacing:1px;
}

Onde duplicamos desnecessariamente vários estilos.

Com o OOCSS nós devemos transformas estes estilos em módulos para serem reutilizados e não atrelando os estilos a um elemento específico.

Isso acontece também quando já fizemos uma classe onde carrega os estilos comuns. Se voltarmos ao exemplo anterior, alguém pode fazer assim:

footer .boxEffects {...}

Estamos aqui atrelando a classe que antes era para ser algo genérico ao elemento footer. Cuidado ao fazer isso. Tenha um bom motivo antes de ir adiante.

Outras boas práticas

Existem algumas boas práticas que fazem parte do OOCSS e que melhoram muito o planejamento e a prática do desenvolvimento web:

Modularização de código CSS

Não estou falando aqui sobre a modularização de arquivos CSS, mas sim do Código. Essa modularização é feita sob medida para cada um dos projetos. O objetivo é que o código CSS seja reutilizado em várias partes da produção evitando que você crie mais código. É aconselhável que se defina padrões de código para os principais elementos do layout. A equipe pode fazer isso ou delegar esse importante trabalho para um desenvolvedor, que será responsável em criar os métodos e os padrões estruturais dos elementos.

Minimizar usos de seletores muito específicos

Encontre o meio termo. Não faça seletores muito específicos ou seletores muito genéricos. O CSS trabalha com especificidade: quanto mais específico, mais certeiro você é ao capturar um elemento, mas seu CSS fica mais engessado e consequentemente você usa mais código. Quanto mais genérico, mais elementos do mesmo tipo você formata, mas o risco de conflito de estilos aumenta. O ideal é encontrar o meio termo, onde você é tão específico e nem tão genérico.

Dependendo da forma que você utiliza os seletores os browsers podem ser ou não mais rápidos ao renderizar seu site. Já falamos disso aqui.

Formate elementos com classes modulares

A ideia é que ao criar uma nova página, você não tenha que criar novo código CSS. Se a página tiver a estrutura diferente mas os elementos tem características visuais iguais, aí está uma boa oportunidade para modularizar o código visual dos objetos.

Um exemplo para demonstrar essa prática é ao fazer botões para diferentes ações. Normalmente utilizamos os mesmos botões com cores diferentes para definirmos visualmente ações diferentes que o usuário pode tomar. O botão de SALVAR tem o mesmo formato de CANCELAR, mas a cor dos dois é diferente, sendo que o primeiro é verde o segundo vermelho. O código seria assim:

.botao {
   display:inline-block;
   padding:10px 20px;
   font:13px verdana, arial, tahoma;
   color:white;
   text-decoration: none;
}

Este código cria toda a estrutura do botão. Agora falta definir as cores de fundo. Eu farei isso criando duas classes: btVerde e btVermelho. Essas classes serão utilizadas em pareceria com a classe botao

.btVermelho {background: red;}
.btVerde {background: green;}

Agora, o HTML ficaria assim:

<a href="#" class="botao btVermelho">Cancelar</a>
<a href="#" class="botao btVerde">Salvar</a>

Porque criei os nomes das classes btVermelho e btVerde em vez de btCancelar e btSalvar? Porque pode ser que exista algum botão que também seja verde, mas não tenha a ação de salvar. Assim deixo meu leque aberto para novas atribuições.

Concluindo

Seguir esses pequenos detalhes evitam uma série de problemas comuns no desenvolvimento client-side. A reutilização de código CSS se torna real, a velocidade do carregamento melhora e os problemas de manutenção são solucionados. A flexibilidade que teremos ao modificar o CSS será muito grande e não aumentaremos nosso código a cada modificação feita. A ideia é que seu código CSS fique sob controle. A utilização de frameworks e bibliotecas podem ajudar em muitos momentos.

Por Diego Eis

Diego Eis criou o Tableless para disseminar os padrões web no Brasil. Como consultor já treinou equipes de empresas como Nokia, Globo.com, Yahoo! e iG. É palestrante e empreendedor.

http://about.me/diegoeis/

Mais posts do autor

Comentários (35)

  • http://www.ortense.com.br Marcus Ortense

    rsrs OOCSS é horrivel mesmo, ainda mais por eu tbm ser desenvolvedor back-end, seguir padrões é muito bom, faz bem, principalmente qdo vc trabalha com uma equipe media ou grande (coisa q nao se aplica a sobrinho :] ), eu particularmente gosto muito de trabalhar com classes modulares, compondo um estilo com um conjunto de classes, pelo post Diego.

  • http://www.facebook.com/vanderson.filho Vanderson Gonçalves Guimarães

    Muito bom

  • Rhamsés Soares

    Excelente artigo. Tudo isso é bom senso aplicado. Um desenvolvedor que esteja ciente da extensão do projeto deve criar classes que o ajudem no trabalho.

    De qualquer maneira é uma forma muito útil de fazer mais com menos. 

  • Rhamsés Soares

    Excelente artigo. Tudo isso é bom senso aplicado. Um desenvolvedor que esteja ciente da extensão do projeto deve criar classes que o ajudem no trabalho.

    De qualquer maneira é uma forma muito útil de fazer mais com menos. 

  • Fourier

    eu não concordo em utilizar nome de classes com a característica, se a classe é btvermelho e futuramente quiser mudar para azul, terei que mudar o nome da classe alem dos atributos, o que não é legal, imagina se o projeto é muito grande?

    terei que encontrar todos os btvermelhoe mudar para btazul, seria porco usar uma classe btvermelho se na verdade é azul.

    reuso é bom, mas tem algumas exceções.

  • Fourier

    eu não concordo em utilizar nome de classes com a característica, se a classe é btvermelho e futuramente quiser mudar para azul, terei que mudar o nome da classe alem dos atributos, o que não é legal, imagina se o projeto é muito grande?

    terei que encontrar todos os btvermelhoe mudar para btazul, seria porco usar uma classe btvermelho se na verdade é azul.

    reuso é bom, mas tem algumas exceções.

  • Vitor

    btVermelho…?
    Muito bom! ;)

    Componentizar com largura fixa… Pode ser… Afinal de contas são botoēs…

    Modularizar arquivos… Realmente, depende do projeto (requisição x cache). Lembrando da divisão por camadas e do número de componentes formatados por cada arquivo do portal, ou pequeno site.

    Gostei do texto, parabéns!

  • Fernando Darini

    Conform já foi dito, nome da classe seguindo sua característica não é nem um pouco usual.
    A melhor forma de trabalhar com css no meu ponto de vista é com herança, dessa forma você evita ficar metendo classe em todos os elementos. Trabalhando com tags html5 é possível até definir uma classe para o elemento pai da página e uma uma para cada section. No caso usaria até ID no elemento pai e nos depois elementos por não repetirem na página e por ter melhor performance com jQuery

  • André Amaral

    Acho que trocar o nome uma classe (mesmo em um projeto gigante) não é tão dificil assim…

    Só se o projeto estiver muito desorganizado.

  • http://twitter.com/celapontas Pontas

    Diego, a modulorização pareceu ótima, só acho que, como outros já comentaram, o exemplo de class “btVermelho” e “btAzul” dificultaria se tivéssemos de mudar as cores. Acho ótimo separar por estrutura e estética, mas de repente seria melhor deixar o nome da classe com a função do botão. Por xemplo: “btVermelho” poderia virar “btCancel” e “btAzul” viraria “btConfirm”. Assim, se todo “btConfirm” no próximo layout viesse a ser verde, não teríamos que renomear todas as classes.

  • Foo

    Você quis dizer, CSS? Não vejo nada nos argumentos que indique algo que a própria referência do CSS no W3C já não indique como boa prática. Está parecendo mais buzzword do que algo prático. Daqui a pouco irão inventar OOCSS 2.0 beta realtime ajax.

    Ignorando que OOCSS é apenas CSS na prática, o problema que tenho é o mesmo que todos têm em algum ponto do projeto. Você começa com um .btnSubmitForm (já que btVerde todos concordam que é “pacabá”), aí você define todos os atributos CSS que deseja. Depois tem um outro .btnCancelForm que possui quase todas as características. Então você:

    1. Agrupa as declarações CSS em uma classe mais genérica, digamos, “.btn” e procura todos os seus arquivos HTML/template por .btnSubmitForm e troca por class=”btn btnSubmitForm” (tranquilo se for o começo do projeto, mais doloroso se está bem avançado e tiver templates em código fonte, além de .html)
    2. Coloca no seletor as opções: “.btnSubmitForm, .btnCancelForm { … }”
    3. Senta e chora.

    Mas tudo é lindo e maravilhoso até que você adiciona à classe genérica uma declaração pequena, sem importância como line-height, e todo teu layout afunda – nenhum elemento mais está no alinhamento certo. Ou ainda lá pelas tantas por algum motivo você decide trocar a fonte, de Tahoma para algo como Helvetica, e decide aplicar esta declaração no elemento raiz, como BODY ou HEAD. Novamente você vê seu site todo desconfigurado e desalinhado, e começa a procurar pelas classes para corrigir uma a uma, mas esquece que há aquela página da intranet, que só o gerente acessa, que um estagiário colocou uma declaração inline no elemento () e como todos sabemos as declarações inline tem prioridade sobre quaisquer outras, e no próximo release o gerente liga com todas as pedras na mão dizendo que não consegue mais fazer o seu trabalho direito porque a informação que ele precisa simplesmente sumiu…

    Eu criei esta historinha pra trazer à tona que o maior problema do CSS não é que ele não é uma linguagem de programação para ser OO, mas sim que o desenvolvimento de sites médios a grandes é algo orgânico, enquanto a OO exige um esforço muito maior de análise, documentação e consistência de ante-mão. Ainda, a OO tem uma hierarquia clara e estática, como em linguagens fortemente tipadas; mas mesmo nas fracamente tipadas os atributos e métodos não são aplicados automaticamente a seus objetos-filhos. Isto é, se você definir o atributo “color” de um container, seus filhos terão a mesma cor automaticamente — o que não acontece na OO. Isto torna muito mais trabalhoso o processo de amadurecimento dos seus “módulos CSS”, pois terá que considerar que este estilo possa ser aplicado a um container ou a um elemento filho (quantas vezes já não criei um estilo elaborado para uma tabela, e vi ele falhar miseravelmente quando precisei aninhar uma na outra…)

    Não me entendam mal, eu sou todo a favor de modularização e reuso, não só em CSS como em JS e nos sistemas que desenvolvo, mas: 1. não acredito que o termo OO tenha caído bem ao CSS, sendo que a própria especificação dele sugere os itens citados no artigo, e 2. esta falácia de associar desenvolvimento de softwares como blocos de LEGO já morreu há muito tempo. A única parte mecânica no desenvolvimento de software, e isto inclui a parte de design, é gravar os bytes em CDs. Todo sistema é diferente um do outro e cada um precisa de análise, documentação, revisão, aprovação, homologação etc. como todos os outros. 

    Software é algo criativo, não industrial.

  • Ale

    O cara aí. 
    Ta aprendendo PHP e resolveu inventar o CSS orientado a objetos.
    kkkkkkkkkkkk

  • Deivid Marques

    Não gosto de usar nome das cores em classe justamente por futuras alteraçoes mas se vc ja tem todo o projeto pode se criar classes genéricas, mas cada desenvolvedor tem seu método de trabalho, tudo tem seu lado bom e lado ruim. O legal é ter um css limpo e de fácil manutenção, lembrando sempre que o seu código tem que ser fácil interpretado por outra pessoa pra alguma alteração ou mesmo trabalho em equipe durante o desenvolvimento do projeto. Gostei do post Diego, muito bom, pois como voce falou justamente o css sendo fácil muitos esquecem dos princípios básicos.

  • http://twitter.com/Putcharles Carlos Eduardo

    Bacana a idéia de modularizar e, principalmente, tornar o código mais organizado e compreensível para outros que participam do projeto.

    Mas não sou a favor de nomear classes baseados em estilização… Acredito que cada estilização se baseie em alguma regra, por isso (quase) sempre conseguimos dar nomes que realmente façam sentido.

    Porém o que realmente importa na prática é a idéia de separar certas características inerentes a diversos elementos (no caso o background) em classes, o que é extremamente válido!

  • weliton

    Está passando da hora de alguém reinventar como se faz a apresentação web com CSS. Com a chegada das novidades do CSS 3 as coisas estão melhorando, mas ainda está muito longe do ideal. Eu penso num futuro CSS onde não é simplesmente uma “linguagem de apresentação” (formatação), mas uma Linguagem de Programação!
    Pode parecer desnecessário, pois já temos JavaScript e seus diversos frameworks, mas seria muito interessante fazer Condições e Estruturas de laço dentro do próprio CSS, entre outros!
    É isso.

  • R. Doi

    Como apontam os outros comentários, não acho que haja um modelo de desenvolvimento ideal para todos os projetos ou equipes.

    Mas é interessante que qualquer projeto, independente da dimensão, se adote uma linha de desenvolvimento pré-planejada (design pattern), sendo a decisão de separar layout da formatação de conteúdo apenas uma das pautas.

    De OO, a única coisa que sinto falta no CSS é o encapsulamento, mas reconheço que seria conflitante com o conceito de “Cascading”.

    De resto, conceitualmente, o CSS está bom do jeito que é.
    O se precisa é de uma boa compreensão de como tudo funciona, de um pouco planejamento e disciplina na implementação. Além, é claro, esperar que todos os browsers entendam as recomendações W3C da mesma forma.

  • Gorzoni

    Eu tenho um projeto e trabalho justamente com esta descrito no artigo, é muito pratico, principalmente no caso de estruturas e containers.

  • Danielevsilva

    Se vc trabalha com equipe de desenvolvimento é muito complicado, a responsabilidade pela aplicação do código é de outro departamento.

  • Pingback: Classes Funcionais | Tableless

  • Jonathan Silva

    Já uso algumas dessas práticas há muito tempo.
    A do botão vermelho é muito boa, pq outros elementos podem ter a mesma característica mas não executam a mesma função, salvar, cancelar. Se eu quiser algo muito específico eu coloco no css.

    E se algum dia eu quiser mudar todas as classes, o editor busca todas e muda pra mim no-stress.

    Ótimo post!

  • http://twitter.com/rafaelhbarreto Rafael Barreto

    Muito bom o artigo.

    A modularização e a organização são essenciais para a compreensão das folhas de estilo por outros .
    Mas ainda assim me intriga o fato de chamar de CSS Orientado a Objeto.

    Está mais para um código organizado e modularizado, como foi muito bem dito.

  • Emanuel

    Nesse caso, uma solução seria, em vez de .btVermelho e .btVerde, substituir por .btPrincipal e .btSecundario, ou .btEstilo1 e .btEstilo2, etc.
    É só ter alguma criatividade e controlo do código.
    Outra solução seria usar o Replace All do editor e substituir .btVermelho por .btAzul, embora possa não vir a ser a melhor opção em alguns casos.

  • http://www.facebook.com/sergiomandrake Sérgio Mandrake

    Outra ideia é utilizar .botao.vermelho { background-color: red; }
    onde a classe .vermelho só vai funcionar se declarar junto com .botao. Ex: <a class="botao vermelho"…

    Bem mais coerente e organizado.

  • Pingback: Classes Funcionais | Mundo Digitais

  • Pedro Canelas

    Acho que a idéia no exemplo foi usar classes como os frameworks tipo Twitter Boostrap fazem. Quer botão vermelho? Use class .btvermelho, quer o botão azul? Mude a class para .btazul. Mas claro, nem sempre esse é o melhor caminho.

  • Pingback: Object Oriented CSS – A teoria das classes reutilizáveis – OOCSS

  • Pingback: Object Oriented CSS - A teoria das classes reutilizáveis - OOCSS | iMasters

  • Dyego Severo

    Eu concordo com você, até posso dizer que me peguei lendo o artigo por conta do título.

  • Junior Castro

    Esse lance de trocar as cores caso o projeto seja grande, eu prefiro usar o sass/compass e trocar a cor nas variáveis.
    Ótimo texto.

  • Pingback: Programador Php, Programador web, desenvolvedor Web Victor Portfolio

  • Leonardo

    É interessante como isso pode ser revisto de uma forma mais funcional hoje se pensarmos que um wireframe semi-funcional pode derivar um css estrutural num piscar de olhos e o css “tema” extrapolar dessa execução com muito mais controle e sanidade.

  • merda

    Diego eis, tu tais metendo no HTML a responsabilidade de formatação do documento, seu burro. Imagina o seguinte… esse btVermelho, agora tem que ser amarelo? isso é um detalhe de interface, visual, design, coisa que deveria ser resolvida no CSS, mas segundo esse seu post, eu teria que alterar no HTML…

  • allan batista

    nem sempre é possível da um replace all. muitas vezes a implementação esta com o back e nao se tem acesso. a melhor solução foi como vcc falou. .btestilo1 etc. ou melhor ainda. seria trabalhar com sass e usar e abusar de extend e mixin.

  • Tivon

    Não sei pq 2 footers p com tamanho de fonte diferente !

  • Kaique Prazeres

    Bom, existe uma prática muito boa que facilita muito o trabalho de prever as características de cada elemento nas folhas de estilos.

    É uma prática de “planejamento” que costuma usar em meus projetos.
    Ao terminar o layout do referido projeto, observo cada elemento e faço uma listagem de todos que possuem mais de 2 atributos como características visuais e crio uma classe especial única considerando que aqueles atributos são predominantes nos elementos.

    Quanto aos nomes das classes, não precisam ser bem específicos, podem ser numerados após o nome referido e ordenados de forma crescente.

    Isto facilita muito a compreensão e manutenção do código.