Quando um novo cliente contratava nossos serviços, o que fazíamos era bastante simples. O cliente escolhia o template e a gente copiava os arquivos de CSS e de imagens para a conta dele. Pronto, problema resolvido. Era a abordagem mais simples e óbvia que poderíamos usar e foi a que usamos. Mas, naturalmente, não era nem de longe a mais adequada. Afinal, a palavra duplicação sempre vem acompanhada de dor e sofrimento. Ambos bateram em nossa porta logo depois de colocarmos os primeiros sites de clientes no ar.
Falhas
O uso real dos templates no dia-a-dia mostrou que cada um deles possuía pequenas falhas. Por mais que revisássemos cada template no momento da compra dele, sempre havia uma ou outra falha que nos escapava, mas ficava bem fácil de enxergar uma vez que o template estive em uso no site de um cliente.
Quando encontrávamos uma falha, corrigíamos, naturalmente. Mas, espere, estávamos duplicando os templates. Então, ao fazermos a correção no original, tínhamos que replicar em cada uma das cópias. Mas, não pense que bastava copiar e colar a correção.
Cada site tem um layout que usa, como base, o código CSS de um template. Mas, normalmente há pequenas alterações no CSS que são pertinentes exclusivamente àquele site. Portanto, não apenas tínhamos um código CSS duplicado, como também modificado.
Colocar as correções nestes arquivos CSS era um tormento. Foi nesse estágio que sofrimento e dor passaram a nos visitar diariamente. Também pudera, tanto tempo desenvolvendo software e caímos no mais básico de todos os erros: duplicar.
A solução
Durante o mês de janeiro, sofremos muito com essa questão, aprendemos bastante e fizemos o que precisava ser feito. Alteramos completamente o funcionamento do sistema para que ele passasse a ter uma forma de utilização de templates mais racional.
A partir daí, cada site passou a ter um parâmetro de configuração onde informávamos o nome do template adotado. Por sua vez, cada site poderia ter um conjunto de arquivos CSS e de imagens específicos para particularidades dele. Então, o HTML de cada página gerada para o site do cliente passava a ficar assim:
Primeiro carrega todos os arquivos CSS do template.
Em seguida, carrega todos os arquivos CSS específicos daquele site, os quais, eventualmente, alteram ligeiramente o funcionamento do template original.
No momento em que essa alteração foi feita, as coisas ficaram bem mais simples. Continuamos a corrigir eventuais falhas nos templates, mas agora, podíamos corrigir em um único ponto e todos os sites que usavam o template corrigido recebiam a correção automaticamente.
Lição do dia: não duplique! O "copiar e colar" de hoje realmente significará a dor e o sofrimento de amanhã. E o pior: este amanhã sempre chega muito mais rápido do que imaginamos.
Se o Be on the Net fosse um recém-nascido feliz e saltitante, ele se pronunciaria mais ou menos assim:
Nas próximas semanas, todos os dias o site do Be on the Net vai ganhar uma pequena melhoria de design.
Pois é. Nesta 38ª iteração do Sistema Be on the Net, estamos começando também a uma segunda fase de design do site. Nas próximas semanas, todos os dias o site do Be on the Net vai ganhar uma pequena melhoria de design. Um ícone novo, um alinhamento melhorzinho, um sombreado estiloso aqui, uma tipografia aprimorada ali.
Por isso convidamos você a visitar o site do Be on the Net uma vezinha todo dia, e ir curtindo as novidades. Quem sabe você não fica com água na boca e adquire o seu? :)
Uma vez vi um filme chamado Drumline, a respeito de competições de bandas escolares nos EUA. É um filme excelente, embora o tópico possa fazê-lo parecer pouco interessante à primeira vista.
Há um rapaz (baterista) que toca magnificamente bem, entra na banda e tenta se destacar rapidamente. O modo como faz isso, lhe parece coerente, por ser tão talentoso, mas o resultado é exatamente o oposto do que espera. O treinador tenta lhe mostrar que em uma banda, assim como em um coral e em tantas outras equipes, o que importa é o equilíbrio e a harmonia do conjunto. O desempenho individual, ainda que excepcional, não pode se sobrepor ao funcionamento harmônico do conjunto, senão ele atrapalha, ao invés de contribuir. Abaixo uma breve cena que ilustra o assunto do filme. E prometo que já no próximo parágrafo explico porque o menciono.
Equilíbrio é o grande desafio. É assim na vida, de um modo geral, e no desenvolvimento de software, em particular. Quando nós treinávamos equipes para trabalhar com XP, buscávamos o equilíbrio e o funcionamento harmônico delas. Agora, com nosso produto, o Be on the Net, essa mesma busca continua, porém em um contexto diferente.
Aspectos de um site
Um site tem pelo menos três aspectos básicos: conteúdo, estética e funcionalidade. O conteúdo responde à pergunta: o que há naquele site? A estética cuida da questão: como está apresentado o que lá se encontra? E a funcionalidade dá a resposta para a última indagação: o que posso fazer neste site?
Assim como o baterista da banda não é mais, nem menos importante que o trompetista, conteúdo, estética e funcionalidade são todos igualmente importantes em um site. Mas, infelizmente, quem faz site frequentemente se esquece, ou não se dá conta disso.
Tem gente que faz site com muito conteúdo, mas feio que dói. Aí o site acaba sendo menos usado do que deveria, porque não é atraente. É o caso, por exemplo, da Transparência Brasil. Lamentavelmente, tem muito conteúdo útil, mas não atrai.
Outras pessoas se concentram tanto na estética, que deixam o conteúdo de lado. Colocam inúmeras animações, efeitos especiais dos mais diversos, mas quando você espreme o site para ver se dá um caldo, não sai nem uma gota. Veja esse exemplo magnífico.
O foco excessivo na estética, que deixa todo o restante de lado, parece endêmico, particularmente entre sites de fotógrafos. A maioria é feita em Flash, tem animações para todos os lados, efeitos especiais, música e tudo, mas navegar pelas fotos do profissional é uma dificuldade só. As poucas fotos que lá estão, frequentemente são minúsculas e praticamente nunca são atualizadas. Falta substância, sobra frustração.
Finalmente, há sites que são extremamente úteis, mas possuem uma estética nada rebuscada. Alguém aí entrou no Google recentemente? A utilidade é monstruosa, mas a estética é simples. Neste caso, há que se fazer uma ressalva. Apesar de simples, a estética minimalista do Google é extremamente apropriada para o propósito do site.
Como se pode ver, é fácil cair no erro de dar ênfase demais a apenas um aspecto do site, negligenciando os demais. Não cair neste erro é um dos nossos maiores desafios com o Be on the Net.
Equilibrando as partes
Os sites que criamos com o Be on the Net procuram ser ricos em conteúdo. Isso significa que o dono do site pode colocar tantos textos, fotos e vídeos quanto quiser. Mas, isso não é suficiente. O conteúdo tem que ser atual. Por isso, é muito fácil atualizá-lo e acrescentar mais ao longo do tempo.
Na estética, nós usamos puramente CSS, que é mais do que suficiente para fazer sites lindos. Muita gente acha que o único jeito de criar um site bonito é usando Flash, por exemplo. Isso é um erro grave.
Finalmente, na parte funcional, nós buscamos fazer com que tudo funcione da maneira mais padronizada e óbvia possível. Porque quanto mais padronizado, mais as pessoas têm familiaridade e conseguem usar facilmente. Pense no caso da navegação por um álbum de fotos por exemplo. É claro que é possível criar inúmeras formas de navegar por fotos. Mas, não é porque você pode criar uma nova, que você deve fazer isso. Pelo contrário. Se há uma maneira de navegar por fotos que qualquer pessoa seria capaz de usar, então adote-a.
Você pode mudar o conteúdo (as fotos), pode criar uma estética toda exclusiva, mas não precisa e nem deve mexer na forma de usar, quando há uma maneira bem conhecida e disseminada. No caso de fotos, mostre uma lista de álbuns. Quando alguém clicar em um álbum, mostre uma lista de fotos em um tamanho reduzido. Quando alguém clicar na foto, mostre-a em tamanho ampliado e permita que a pessoa avance para a próxima ou volte para a anterior. Pronto! Qualquer pessoa sabe usar isso.
Agora entre em um site de fotógrafo, feito em Flash e prepare-se para aprender. Pois cada um te oferecerá sua própria forma de navegação. Triste, porém mais comum do que se imagina. E o desequilíbrio segue firme e forte.
Infelizmente a web parece estar cheia de bateristas brilhantes, que puxam a sardinha para seu instrumento e negligenciam o restante da banda. Quem paga o pato? Cada um de nós. Afinal, quantas não foram as vezes em que nos frustramos no mar de sites desequilibrados pelos quais navegamos diariamente?
PS: Sim, eu mencionei Flash. Mas, não, este não é um artigo para falar mal de Flash, até porque é apenas uma tecnologia. Minha crítica aqui não é em relação ao Flash, mas de quem faz um site desequilibrado em Flash. Mas, é claro que é possível fazer site desequilibrado usando só HTML, por exemplo. Quer um exemplo dos melhores? Então se prepara e vai para um lugar onde possa rir escandalosamente. Foi? Bem, eu avisei. Veja que beleza. :-)
Publicado por Leandro Mello há
aproximadamente 1 ano.
Estamos procurando um grupo de excelentes designers com quem possamos manter um relacionamento duradouro. E você pode ser um deles.
Nosso produto em desenvolvimento, Be on the Net, está avançando rumo a seu lançamento.
Se depender do número de pessoas interessadas nele, podemos dizer que já somos um potencial sucesso: hoje, mais de cento e cinqüenta pessoas aguardam ansiosamente em nossa lista de espera para terem um site lindão só seu.
Assim que o Be on the Net for lançado, atenderemos estas pessoas uma a uma, para dar a elas layouts simples, belos e personalizados. Para a fila fluir, vamos adotar a seguinte prática: o cliente da vez vai passar dois maravilhosos dias em contato conosco para, todos juntos, darmos saída ao design lindão dele. Mas só isso: dois expedientes. Depois disso, venha o próximo da fila. Para ela fluir, como dissemos.
Puro CSS
Para a fila fluir mais ainda, é aí que você entra. Be on the Net é um aplicativo web que já tem HTML e JavaScript prontinhos para o usuário, só precisando de seu CSS para deixar o site com a cara do cliente. Portanto, estamos a partir de agora convocando webdesigners de todo o Brasil para faturar dindim com o que sabem fazer de melhor: puro CSS.
A dinâmica e as possibilidades
Funciona assim: os designers desse Brasil — você, por exemplo — vão oferecer, assim como nosso designer, um freela de dois dias para uma pessoa da nossa lista de espera. Ao final de dois expedientes, o cliente sai com design pronto, paga um troquinho atraente para ele, você sai com grana e a Improve it, com uma comissãozinha simbólica. Simples assim.
E é aí que entram as possibilidades! Há várias maneira de você fazer grana com o Be on the Net!
Você pode:
Passar seu mês ajudando-nos com design:
Se você é um freelancer que tem bastante tempo disponível para pequenos sprints de dois dias, pode faturar com a quantidade de layouts por mês — supondo que você trabalhe dois dias da semana, passe um dia fazendo a faxina e passe os últimos dois dias com o cliente seguinte, são dois clientes por semana, oito por mês. Um único layout dá um troquinho, mas oito dão uma grana! Dá para basicamente viver de CSS para Be on the Net.
Virar uma máquina de produzir design:
Se você se considera uma máquina superpoderosa de design, pode realizar a proeza de completar um layout em um único dia. Neste caso, acontecem mais coisas boas: o cliente leva um desconto, mas você não recebe menos: recebe a mesma coisa que em dois dias. E em vez de oito layouts por mês, pode conseguir até dezesseis. Fatura o dobro.
Revender Be on the Net para seus clientes:
Seja você freelancer ou empregado numa agência de imagem ou design, você pode incorporar à sua carteira de clientes o Be on the net. Ou seja, faz (ou refaz) os sites para seus clientes com seu CSS bonitão sobre nossa estrutura. Neste caso, você nos paga as mensalidades dos Be on the Net’s de seus clientes e faz lucro com o seu preço de revenda. E não precisa ficar que nem um tarado fazendo um layout por dia.
Se você e seu cliente entrarem em comum acordo de ceder o design como Creative Commons e o dispolibilizar como template para futuros clientes no site do Be on the Net, vocês dois são recompensados e saem ganhando ainda mais (detalhes adicionais nas próximas semanas).
Estas são as formas mais básicas de ganhar dinheiro. Mas há mais possibilidades! E se você faz vários layouts por mês em um dia cada um, e seus clientes todos concordam em ceder como Creative Commons? Putz, enxurrada de dinheiro! E por aí vai.
Que poderes você deve ter
Simples: os poderes que qualquer ninja teria. :-) O Be on the Net funciona sobre um código XHTML 1.0 Strict válido e um JavaScript impecável. Para você figurar entre nosso grupo seleto de designers, gostaríamos que tivesse o mesmo carinho com seu design, orientando-o plenamente aos web standards. O que você precisa:
Usar CSS3 válido;
Esquecer tabelas. O HTML já vem pronto, totalmente tableless, para você estilizar com a fluidez que quiser;
Esquecer Flash. Flash é muito, muito lindo, e só. O Be on the Net não usa Flash, só puro CSS;
Fazer um design totalmente cross-browser. IE6 e 7, Safari, Firefox, Opera, Flock, Chrome, Camino, Konqueror, e por aí vai (mas fique à vontade para fazer firulas não-essenciais nos que forem standards-compliant, hehe!);
E claro, ter um layout final de dar água na boca. Esquema de cores agradável, tipografia legível, diagramação de encher os olhos, e a bela e sempre bem-vinda simplicidade. Que beleza.
Para terminar... por enquanto
Ainda há muito a decidirmos sobre dindim. O preço que o cliente vai pagar nestes dois dias de setup, o desconto que ele vai levar se terminar em um dia, o que você vai ganhar a cada trabalho e o que vamos ou não receber como comissão, isso tudo ainda está em definição.
O que buscamos é alinhar interesses — o que o cliente paga é leve e bem atraente; ele ganha o Be on the Net dele logo, sai feliz o quanto antes e colhe os lucros de seu novo site em pouco tempo; o tempo curto inspira-o a pensar em simplicidade e a se preparar para ajudar você, no melhor estilo “menos é mais”; você recebe uma baita grana associando criatividade de ação, qualidade e quantidade — se você é bom, queremos você por perto como freela mais vezes, ora! :) —; ganha nome em nosso site; e nós multiplicamos nossas mãos ganhando um montão de parceiros — e todos nós garantimos o leitinho das crianças no processo! ;)
Vamos adorar lucrar fazendo da web um lugar melhor. E seu cliente vai adorar você pelo site lindão.
Espalhe (bem) a notícia, divulgue por todos os meios: estamos procurando um grupo de excelentes designers com quem possamos manter um relacionamento duradouro. E você pode ser um deles. Se estiver interessado(a), entre em contato — links para seus melhores trabalhos serão muito bem-vindos!
Publicado por Leandro Mello há
aproximadamente 1 ano.
Basicamente, o tapa na cabeça que faz o IE se comportar direitinho é o display: block. Depois dessa, você põe a margem que quiser no <hr />.
Sou dos que usa a tag <hr /> para dividir seções. É semanticamente mais coerente do que separar usando as próprias bordas dos divs, fica melhor quando se vê o HTML sem CSS, essas coisas que já se discute à beça por aí. Aprendi a apreciar sua utilidade.
Mas o fato é que é enjoado dar estilo a esta tag. Para cada browser devem-se editar atributos diferentes para se alcançar um mesmo efeito. Enfim, com algum jeitinho, deixa-se o <hr /> com a mesma cara em todos os browsers.
O que mata mesmo, o que deixa fóruns de cabelo em pé é a tal margem que fica em volta do <hr /> no IE. A margem no IE é teimosa, indestrutível, incontrolável, inestilizável. Por todo lugar que eu procurasse, as pessoas decidiam seguir com as margens mesmo, e os mais persistentes chegavam ao ponto de inserir o <hr /> num <div> para conseguir dar o estilo que quiserem. Ou seja, uns desistiam muito fácil, outros recorriam a medidas desesperadas para fazer a coisa de qualquer jeito.
Um dia encontrei dois posts que se aproximavam da solução. Sozinho, nenhum dos dois resolvia o caso. Mas juntando os dois funcionava! Fiz os testes e, de fato, misturando os dois raciocínios eu conseguia a medida que eu quisesse em qualquer browser que fosse — até zero. Mas, numa jogada um tanto infeliz, não salvei os posts nos favoritos, nem salvei o arquivo de testes. Uma resposta bastante procurada, e eu a perdi de bobeira...
Este artigo é sobre o meu caso: eu queria usar o <hr /> livre de divs sem sentido, e com margem zero; até no IE. E, sobretudo, o artigo é para deixar a resposta num lugar seguro e ao alcance de todos. Agora que eu lembrei a solução, não perco mais.
“Pescotapa”
Depois que perdi de vista os posts e as semanas se passaram, tudo o que eu lembrava é que o Internet Explorer precisava de um tapa na cabeça: era um atributo nada intuitivo e totalmente inesperado, que surpreendentemente o fazia acordar para a realidade. Basicamente, o tapa na cabeça que faz o IE se comportar direitinho é o display: block. Depois dessa, você põe a margem que quiser no <hr />.
Vai entender. O <hr /> já é um elemento em bloco. Tem toda a cara de elemento em bloco. Pula linha em cima, pula linha embaixo, não tem nada de inline. E é por isso que os fóruns tanto rodam atrás de uma solução: poucos suspeitariam que é necessário lembrar a ele que de fato é um bloco. Dizer display: block seria redundante e desnecessário. Mas o danado do IEca faz questão disso para se dar conta de que “ah, é, é verdade...”.
Como aconteceu comigo:
Vamos ao meu caso. Eu pretendia inserir umas tags <hr /> no site da fotógrafa Patricia Figueira, como experimento para implementação futura no próprio site e em nosso produto em desenvolvimento, o beonthe.net.
O primeiro passo foi inserir tags <hr /> nos espaços entre cabeçalho, conteúdo principal e rodapé. Vamos ao HTML:
E logo surgiu a linha cinza entre os divs. Ficou assim:
Safari:
Opera:
Firefox:
Internet Explorer 7:
Internet Explorer 6:
(Ah, o IE...)
Linhas inseridas, eu queria que cada divisória tivesse as seguintes características:
Quebrasse possíveis floats;
Não ocupasse qualquer espaço vertical;
Fosse invisível.
A primeira tarefa é simples. Na folha de estilos application.css, usamos:
hr {
clear: both;
}
Nota: Depois vi que, para limpar de fato os floats do div#main_content, foi necessário pôr os hr’s dentro do #main_content, em suas extremidades, e não adjacentes a ele. Mas isto é papo para toda uma outra discussão e, para efeito de ilustração, vou continuar exibindo os hr’s como se estivessem entre o #main_content e o #header.
Agora vem a segunda tarefa: limpar os espaços que a linha gera no IE. Mas, como dito antes e tantas vezes blogs afora, a margem do hr no IE é turrona, implacável, indelével, inoxidável. Tem gente tentando de tudo: margin: 0, padding: 0, line-height: 0, font-size: 0, até overflow: hidden. Zerar as margens até ajuda com os browsers que seguem os padrões, mas nada acaba com o espaçamento no IE.
Então, em nosso application.css, cuidemos dos browsers inteligentes para garantir que não haja margens:
hr {
clear: both;
margin: 0;
}
A explicação para as margens insistentes do IE é a seguinte: o IE renderiza o <hr /> com uma margem vertical de 7px a mais do que os outros browsers. Ou seja, se você escreve...
hr {
clear: both;
margin: 7px 0;
}
... Você tem num browser decente o esperado:
E no IE, uma soma do que você inseriu mais a margem nativa:
“Ora”, posso pensar, “Então é só escrever margens negativas para o IE”. Seria o intuitivo, mas o IE não trata de coisas como “o intuitivo”. Não funciona: o IE tira a margem superior, mas jamais elimina a margem inferior! Veja:
O pulo do gato
Entra na nossa folha de estilos application.css o atributo display: block:
hr {
clear: both;
margin: 0;
display: block;
}
Este é o último atributo em que eu pensaria para eliminar margens. Não sei explicar por que dá certo. É contra-intuitivo. É redundante. É idiota. E mesmo assim (ou talvez por isso mesmo) faz o IE acordar.
Agora sim, podemos repensar a questão das margens negativas. Então corrigimos o application.css:
Ela serve para chamar uma folha de estilo com regras específicas para o Internet Explorer: application_ie.css.
Nesta nova folha application_ie.css, aplicamos as margens negativas que tínhamos até então:
hr {
margin: -7px 0;
}
E pronto. Esta é a única regra que diferencia o <hr /> nos browsers inteligentes e no Internet Explorer. Agora podemos zerar as margens no nosso application.css:
hr {
clear: both;
margin: 0;
display: block;
}
E o resultado é: consenso! Nos browsers inteligentes:
... e no IE:
Acabamento
Resta a terceira tarefa, que é deixar invisíveis as linhas divisórias. Isso é fácil com visibility: hidden:
O que vai fazer com que o <hr /> fique invisível, mas ainda ocupando o espaço que ocupava antes, de modo que fica uma lacuna de 2 pixels entre o cabeçalho e o conteúdo principal:
Nota: Usar display: none não é útil neste caso porque cancela o atributo clear: both. E nós queremos que ele quebre os floats. Neste caso, é melhor ficar com visibility: hidden.
Nos browsers decentes, esta lacuna é devida à espessura da borda. Bordas de 1px em volta de um elemento com altura zero resultam em 2px de altura total. Um aributo de borda deve resolver:
No Firefox resolve. Mas no IE a lacuna, em vez de sumir, fica reduzida a 1px (Ah, o IE...). Isso porque nele as bordas não são definidas pelo atributo border, mas pelo atributo color (já mencionei que o IE não trata de coisas como “o intuitivo”?). Como não dá para “zerar” a cor para sumir com a lacuna, o jeito é retocar as margens que deixamos no application_ie.css, contribuindo para as margens negativas com 1px em cima ou em baixo:
hr {
margin: -8px 0 -7px 0;
}
E eis o resultado final:
Conclusão
Este foi o meu caso bem específico com a tag <hr />. Se você for uma das pessoas que se descabelavam por causa das margens teimosas no IE, saiba que há solução. Não é preciso desistir e adaptar seu precioso layout para se conformar com as margens, nem é preciso inserir a tag num <div> só para ela. Boas práticas já!
Espero ter contribuído para diminuir sua dor de cabeça. A resposta está agora aqui, para todo o mundo. E breve você a verá implementada no site da Patricia Figueira e no beonthe.net. Mas se este post não resolver o seu caso específico, escreva. Vamos juntos pensar em soluções para dominar o <hr /> — e, quem sabe, só quem sabe, o Internet Explorer.
Publicado por Leandro Mello há
aproximadamente 1 ano.
Na internet, mesmo que você não consiga mostrar uma imagem, ainda consegue dizer as mil palavras.
Hoje descobri um detalhe no meu método de escrever CSS que pretendo adotar como "best practice" pra mim em todo projeto futuro: a única folha de estilo que, num projeto que abranja tela/impressão/mobile, deve levar atributo media="all". Eu a chamo de "typography.css".
Inspiração de fora da web
Cheguei a esta prática aplicando no webdesign um tanto do modus operandi adotado por publicitários e designers fora da web.
Em design e publicidade, costuma-se lidar separadamente com layout e tipografia. Isso porque o design aplicado ao texto carrega por si só uma personalidade tão forte, que merece atenção à parte. Há aos montes empresas dedicadas exclusivamente à tipografia, que passam dias, semanas, para criar uma única fonte, completa e bela. O visual do texto tem um poder só seu.
Na web, sofremos sérias restrições à tipografia. Não é possível usar fontes realmente únicas em um site porque elas podem não existir no computador do usuário. O uso de imagens com texto bonitão apresenta alguns riscos à acessibilidade, e a prática de incluir as próprias fontes no código tem suas próprias complicações. Em resumo, paciência: o jeito é usar o rozfejão mesmo e saber brincar com ele. O que é bom, já que este texto não trata mesmo de tipografia, mas do que podemos aprender com o hábito de separá-la do layout.
Consistência e identidade visual
O bom do CSS é que ele garante a consistência das páginas do seu site. Uma mudança num seletorzinho qualquer e pronto, milhares de páginas são atualizadas de uma vez só, que beleza! Isso tem tudo a ver com o que chamamos identidade visual.
Uma empresa que respeita a própria identidade visual faz questão de que, no mínimo, sua tipografia seja consistente em todos os meios de comunicação, tanto em impressos como em eletrônicos, tanto quanto for possível. O layout é muito mais sujeito a pequenos ajustes aqui e ali por causa da variedade de suportes a que pode ser aplicado, mas o modo como o texto é apresentado tem que respeitar uma consistência ainda mais globalizada — o designer um dia pode se ver tendo que fazer uma peça que confie unicamente na tipografia, e as pessoas têm que reconhecer que tal peça pertence a tal empresa. E na web esta situação é bastante recorrente.
O denominador comum
Imagine que seu site é poderosão, pode ser impresso, visto em mobiles, transformado numa transparência etc. Agora tire todos os luxos. Imagens, firulas de layout e tudo mais. O que sobra? Texto. Na internet, mesmo que você não consiga mostrar uma imagem, ainda consegue dizer as mil palavras. E de quebra transmiti-las para as outras mídias. Então por que não criar uma folha de estilo que lide só com o que tem a ver com texto?
Como aconteceu comigo
À medida que os projetos em que eu trabalho cresciam, ficava complicado navegar pelo mar de seletores. Como eu escrevo CSS de modo incrivelmente regular, com todas propriedades aparecendo sempre na mesma ordem (ok, podem me chamar de maníaco) percebi que as propriedades que regiam o texto vinham sempre antes do grupo que controlava o layout. Para diminuir o tamanho de arquivo, resolvi pegar as propriedades de texto e jogar todas num arquivo separado, a que chamei typography.css.
... dividiu-se em um trecho que foi para o typography.css:
.rss_links a,
.podcast_files h4 a {
font-size: 80%;
text-transform: uppercase;
text-decoration: none;
}
... e outro que permaneceu no original application.css:
.rss_links a,
.podcast_files h4 a {
padding: .3em 1em;
background: #F7F7F7 url(/images/background/gradient_light_to_dark.png) repeat-x bottom left;
border: 1px outset #F7F7F7;
}
E assim por diante, com todos seletores. A cisão foi bem fácil. A decisão de fazer a divisão e o nome que arranjei para a nova folha de estilos foi mais guiada pelo meu velho hábito de designer gráfico — e por uma leve esperança de que isso tornasse menores os arquivos — do que por alguma noção de onde isso ia dar. Mal sabia que ia ter resultados bem interessantes.
Ora, em um ponto chega a hora de fazer um CSS de impressão e um para mobile. Em minha primeira experiência desde que resolvi usar o método typography, resolvi expandir a dobradinha para o print e o handheld, criando assim as folhas de estilo application_print e typography_print, e application_handhled e typography_handheld.
Minha pasta "stylesheets" então ficou assim:
application.css;
application_handhled.css;
application_print.css;
typography.css.
typography_handheld.css;
typography_print.css;
Que beleza! Mas pô... seis folhas de estilo só por um capricho de designer de separar o layout da tipografia? "Tem que ter um jeito de fazer melhor", pensei. E tinha. Com a sacação sutil, já dita lá em cima, de que a tipografia tem que ser global.
Refatoração, resultados e vantagens
Percebi que os seletores dos três arquivos de tipografia eram muito similares. Assim, misturei tudo o que eu tinha no typography, typography_handheld e typography_print em um único arquivo typography.css. Fim da duplicação: ele passou a cuidar de tudo — tamanho da fonte, cor da letra, itálicas, negritos, maiúsculas e tudo mais. No CSS de impressão, como geralmente as pessoas preferem imprimir textos em preto, foi só escrever html * { color: #000; } que tudo foi resetado para preto (sobra meia dúzia de seletores teimosos, é só fazer o mesmo).
Por último, no head do HTML, atribuí ao typography.css media="all". E só a ele. As outras folhas de estilo que se preocupassem com suas mídias específicas. Todas estas outras folhas herdariam as mesmas propriedades de texto e, assim, estaria garantida a consistência não só entre as páginas de um mesmo site, mas entre as várias mídias que uma empresa e seu site disponibilizam. Identidade visual, caro leitor!
Outras vantagens que este método me trouxe:
Com todas as minhas preocupações com texto voltadas para uma única folha de estilos, pude concentrar esforços de design no layout específico de cada mídia, o que me salvou de um trabalhão extra, e mostrou ser para mim um jeito bem mais gostoso de trabalhar layout;
A proliferação das folhas de estilo ficou bem mais controlada. Agora, se eu tenho CSS para n mídias diferentes, em vez de ter 2n folhas de estilo como antes, passo a ter sempre n+1, sendo este "1" o nosso amigo typography;
O peso total da soma dos arquivos, em conseqüência, diminuiu. Leveza é o que há!
E o mais importante de tudo: as folhas de estilo não mais viram um oceano gigantesco de seletores, ficam legíveis para todos na equipe, eu encontro o que quero fácil, altero o que preciso bem fácil, e volto para casa no fim do expediente sem fazer hora extra! ;D
Enfim, a nova prática tem-me rendido bons resultados. Há ressalvas, claro: num projeto pequeno, que não se pretende imprimir ou ver em mobile, não vale a pena separar typography de application. Por sua vez, um projeto gigantesco, ainda que bom candidato a ganhar um typography.css, tem muito mais chances de ter folhas de estilo auxiliares que provavelmente jogariam por terra minha contagem "n+1" de folhas. Mas no todo, meu trabalho com CSS tem sido bem mais bacana tendo que me preocupar com uma coisa de cada vez. É algo que com certeza vou adotar como best practice nos meus trabalhos... até aparecer uma prática melhor! :)
Este foi meu primeiro post no blog da Improve It. Espero que as informações sejam úteis de alguma forma, e inspirem boas práticas em designers e programadores por aí. Até onde experimentei, foi dos métodos que mais facilitou o trabalho por aqui. Claro que, ou eu não li o suficiente sobre CSS, ou esse assunto de separar tipografia já cansou de ser discutido lá fora, ou as duas coisas. Por isso, convido meus caros compadres designers a participarem da discussão. Quem sabe até onde esta metodologia pode ser aprimorada?
