Tag br pra quê?

É sério, eu não consigo enxergar muita utilidade para a tag <br />. Pelo menos não tanto quanto alguns desenvolvedores enxergam.

Pular uma linha após o input do form? Ajuste o CSS do input para “display:block”.

Deixar a imagem sem nenhum texto ao lado? Idem anterior, “display:block” para a imagem.

Alinhar o texto verticalmente? Simples, especifique um padding para o container desse texto ou em casos mais específicos use o vertical-align.

Aumentar a altura da div? Propriedade height.

Título e subtítulo com o mesmo link do texto? Deixe de preguiça e faça do jeito certo, um link para cada elemento, e claro, utilize as tags adequadas para cada um deles.

Ás vezes parece mais prático utilizar um <br />, mas na hora de atualizar pode ser que você tenha que alterar o HTML e o CSS, sendo que você poderia mexer apenas no CSS. Eu sei que é uma coisa mínima, mas isso é separar conteúdo de apresentação, um dos princípios dos padrões web standards.

Até hoje consegui encontrar apenas uma aplicação plausível para a tag <br />. Poesias[bb], pois é necessário delimitar os versos.

No meio do caminho tinha uma pedra <br />
tinha uma pedra no meio do caminho <br />
tinha uma pedra <br />
no meio do caminho tinha uma pedra.

Se alguém conhecer outra utilização semântica para a tag <br /> avise, eu não lembro de mais nenhuma.

E antes que digam. Sim, eu sou chato pra escrever qualquer HTML. :-)

Resolvendo problemas com altura de divs e floats

Um problema comum ao utilizar elementos com a propriedade float é que o elemento pai não tem sua altura afetada pelo elemento com float.

semclearboth.jpg

Uma das soluções era utilizar outro elemento com a propriedade clear:both após o elemento com float.

clearboth.jpg

Entretanto, para isso você tinha que incluir um código muitas vezes desnecessário no HTML.

Procurando melhorar a estrutura do código HTML, encontrei este link no Position Is Everything com uma solução para o problema. Ele utiliza o pseudo-elemento :after e hacks para os browsers que não o interpretam.

Posteriormente, encontrei outra solução que não faz uso de pseudo-elementos. Basta setar duas propriedades para o CSS do elemento pai.

div.container {
overflow: auto;
width: 100%

}

Confira o exemplo.

Algumas considerações:

  • A propriedade width apenas é necessária devido ao conceito hasLayout do Internet Explorer;
  • Pode ser que em alguns casos você tenha que definir o width com valor diferente de 100%, isso vai depender do seu layout;
  • Devido à propriedade overflow, em alguns casos podem aparecer barras de rolagem, você pode resolver isso aplicando valores apropriados para a propriedade width e, muito raramente, height;
  • Parece que alguns browsers da Apple aplicam barras de rolagem para o overflow:auto, nesse caso utilize overflow:hidden.

Pensar em usabilidade não é criticar

Usabilidade e acessibilidade são termos que estão em alta. Principalmente na hora de pensar nisso como defeito no site dos outros.

O menu está ruim? Tudo bem, então qual seria a melhor forma de apresentá-lo? Usabilidade e acessibilidade são áreas estudadas há muito tempo, mas só recentemente vem sendo divulgadas e utilizadas na internet. Vejo muita gente comentando, criticando e até vendendo (de forma errônea, mas vendendo), e poucos aplicando isso ao seu trabalho. A aplicação fica por conta de uma minoria, seguida e, as vezes, até plagiada pelos demais.

Uma forma de driblar o problema e aprender a aplicar conceitos de usabilidade no seu projeto é ser auto-crítico e estudar, veja bem, estudar não é apenas ler estudos de casos e acompanhar blogs de especialistas. Estudar é ir mais a fundo, é tentar entender como o usuário pensa e como os dispositivos funcionam, ler livros[bb] e desenvolver projetos visando apenas o aprendizado. Com certeza você vai aprender muito mais quebrando a cabeça para resolver um problema do que apenas visitando uma página com péssima usabilidade.

Antes de reclamar que está ruim, pense em como diminuir o problema e, se puder, resolva, aplique a solução e defenda os conceitos que você utilizou no processo. Perca de tempo? Não, aprendizado.

Complicando os web standards

Quando você descobre pra que serve CSS tudo muda. Ao desenvolver um site sem tabelas nem se fala, ainda mais se você era adepto do “TableYes”. Passa algum tempo e você ouve falar de semântica, web standards e surgem algumas tags que você mal sabia que existiam, <abbr>, <dl>,<fieldset>,<optgroup>, <thead>, etc. Apesar de todo esse conhecimento, já reparou como complicamos algumas coisas?

Por exemplo, vejo muitas pessoas incluirem um form dentro de ‘<div id=”form”>’, sendo que, na maioria das vezes, isso é desnecessário pois um form já tem por padrão a propriedade “display:block”. Muitas vezes, não é nem por falta de conhecimento, mas sim, preocupação em deixar o site bem estruturado ou até mesmo pressa.

De vez em sempre, flagro alguns deslizes nos sites que desenvolvo. Aprendi a revisar rapidamente o trabalho do dia anterior assim que chego ao escritório[bb], ou quando volto do almoço. Com isso já consegui ajustar dezenas de divs e spans desnecessários.

Pode ser que não haja como escapar de inserir uma div dentro de uma ul (será?), mas você pode eliminar aquela “div class=titulo” que só possui um h2 dentro.

Para alguns pode parecer neurose, mas seguir os padrões é deixar seu site com código semântico, é retirar tabelas usadas para inserir backgrounds e, porque não, divs e span desnecessários, por mais que não atrapalhem ou interfiram no layout.

Quanto mais simples você desenvolve, acredite, mais fácil é modificar depois.

Site Prometido X Site Entregue

O que você oferece na hora de fechar um site? Já vi pessoas enviarem propostas enormes, oferecendo sistema de notícias, artigos, enquetes, estatísticas, cadastro de usuários, envio de newsletters. Calma, vamos parar por aí. Antes de gerar uma proposta, é necessário ter um briefing. O que o seu cliente vende? O que ele realmente precisa? Pode ser que aquela seção de artigos fique eternamente desatualizada e ele nunca envie uma newsletter sequer.

É um defeito nosso achar que, por incluir demasiadas opções em uma proposta, o cliente terá a impressão que somos excelentes profissionais. E aí que vem a dor de cabeça, o cliente espera muito mais do que podemos oferecer. Ele achou que a seção de notícias seria um novo portal do UOL, quando na realidade é apenas uma lista do que existe cadastrado. Será que faltou exemplificar isso? Ou será que foi maquiado na proposta?

A melhor forma de oferecer um serviço é vendendo-o como ele é. Sua proposta é para um site simples? Deixe isso bem claro ao cliente, seja sincero. Pois assim ele já sabe pelo que estará pagando. Você deixa de ouvir reclamações que o site não é o que ele esperava. Futuramente, você poderá oferecer, ou até mesmo ele irá solicitar, uma nova proposta de upgrade no site, incluindo serviços que se tornaram necessários automaticamente.

Já tem algum tempo que venho trabalhando e estudando uma metodologia diferente. Vejo o que o cliente precisa e faço, nada de adicionar serviços que não sejam necessários. Vou acompanhando as estatísticas de acesso e ofereço novas propostas para serviços que, de acordo com as estatísticas, vão trazer retorno e acelerar o desenvolvimento do site. O cliente consegue mensurar o retorno do investimento e avaliar o meu trabalho. Deixei de fazer um site administrativo para entrega-lo na mão do cliente. Vou acompanhando o site o tempo todo. Ganho menos? Inicialmente sim, mas prefiro receber mensalidades do que um valor fixo por 2 meses de sono e stress diário. Desse jeito, o cliente sai satisfeito, sabe pelo que está pagando e eu tenho menos dor de cabeça.

Por isso, volto a bater na tecla. O que seu cliente realmente precisa? Se sua proposta for bem elaborada e o cliente não gostar, não se preocupe, é porque nem ele sabe o que quer.

Topo