Desenvolvimento Ágil - Blog da Improve It: Tag best practices

Margens na tag HR: um caso resolvido

Leandro Mello — Tue, 02 Sep 2008 12:33:00 -0300

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:

<div id="header">
  (conteúdo do cabeçalho)
</div>
<hr />
<div id="main_content">
  (conteúdo principal)
</div>
<hr />
<div id="footer">
  (conteúdo do rodapé)
</div>

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:

hr {
  clear:      both;
  margin:     -7px 0;
  display:    block;
}

E voilà! Finalmente, um <hr /> sem margens!

Comentário condicional:

O problema de usar margens negativas é que os browsers inteligentes as interpretam como elas são — negativas:

Temos que definir um comportamento para cada tipo de browser.

O que eu costumo usar são comentários condicionais. Há quem diga que eles são maus, mas até agora só têm me ajudado.

Vamos ao <head> no HTML. Lá inserimos uma condição para o IE:

<!--[if IE]>
  <link href="/stylesheets/application_ie.css" media="all" rel="stylesheet" type="text/css" />
<![endif]-->

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:

hr {
  clear:      both;
  margin:     0;
  display:    block;
  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:

hr {
  clear:      both;
  margin:     0;
  display:    block;
  visibility: hidden;
  border:     none;
}

A lacuna some no Safari e no Opera. Mas Firefox e IE precisam de mais uma forcinha. Lembre-os que a altura do elemento deve ser nula:

hr {
  clear:      both;
  margin:     0;
  display:    block;
  visibility: hidden;
  border:     none;
  height:     0;
}

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.

O denominador comum

Leandro Mello — Thu, 26 Jun 2008 22:57:44 -0300

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.

Então, por exemplo:

.rss_links a, 
.podcast_files h4 a {
    font-size:              80%;
    text-transform:         uppercase;
    text-decoration:        none;
    padding:                .3em 1em;
    background:             #F7F7F7 url(/images/background/gradient_light_to_dark.png) repeat-x bottom left;
    border:                 1px outset #F7F7F7;
}

... 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?

Desenvolvimento Ágil - Blog da Improve It: Tag best practices

Margens na tag HR: um caso resolvido

“Pescotapa”

Como aconteceu comigo:

O pulo do gato

Comentário condicional:

Acabamento

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.

Conclusão

O denominador comum

Inspiração de fora da web

Consistência e identidade visual

O denominador comum

Como aconteceu comigo

Então, por exemplo:

... dividiu-se em um trecho que foi para o typography.css:

... e outro que permaneceu no original application.css:

Refatoração, resultados e vantagens

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`.