Sobre o que escrevo?

Vale a pena criar um site seguindo padrões de codificação?

twitter
google-buzz

Não gosto de repetir o óbvio, mas lá vai. Todo mundo sabe, ou deveria saber, que um dos fatores mais importantes – senão ‘o mais importante’ – para definir a popularidade de um blog é a relevância do seu conteúdo para o público-alvo pretendido.

Entretanto, é ‘contra-produtivo’ (minha versão em português para counter-productive, :grin: ) ter um ótimo conteúdo em um site bagunçado. E isso inclui sites em que o Firefox dá um jeito de entender um html/css sem o mínimo de organização, e – quando você vai ver o código-fonte – quase tem que chamar um tradutor.

É muito legal falar em seguir padrões e escrever o código de forma organizada. Mas o fato é que isso exige do programador/webdesigner/… (muita) disciplina para:

  1. começar o projeto seguindo padrões já estabelecidos
  2. nas sucessivas atualizações, continuar seguindo esses padrões

Você pode pensar que não vale a pena tanto esforço. I mean, quantas pessoas – ao chegar no seu site – vão sequer pensar em usar ctrl+u (no firefox ou a opção equivalente em outros navegadores) para ver como está seu html?

O ‘x’ da questão não é quantas pessoas vão se interessar em ver seu código; é, no entanto, quantas pessoas vão deixar de chegar em seu site se os bots de mecanismos de pesquisa não entenderem o que você tem a dizer.

O caso de sites que utilizam gerenciadores de conteúdo pode se tornar ainda mais crítico, devido a possibilidade de utilizar layouts prontos. Claro que acho muito legal ter layouts que você pode enviar os arquivos para o servidor, descompactar e está tudo pronto; facilita a vida de quem não sabe html/css ou por qualquer motivo não quer um tema exclusivo. O problema que quero destacar aqui é que já vi muitos layouts com certa ênfase em seguir os padrões do w3c[1], mas que – depois de instalados – não passam pelos testes de validação.

Por isso, aí vão algumas dicas para melhorar seu site/blog:

  1. Verifique se seu site tem uma declaração Doctype válida. Isso define como o navegador irá renderizar seu código; uma declaração incorreta pode causar erros mesmo que o código seja válido.
  2. O css está correto? http://jigsaw.w3.org/css-validator/.
  3. O html/xhtml é válido? http://validator.w3.org/.
  4. Crie um sitemap em xml, os bots de mecanismos de pesquisa utilizam esse arquivo para indexar suas páginas. (Veja um exemplo.) Se você usa WordPress, experimente o Sitemap Generator.
  5. Crie, também, um sitemap para seus usuários. (Veja um exemplo.)
  6. Se você tem problemas ao tentar validar suas páginas devido às palavras acentuadas, você pode (1) substituir as letras com ~,^,´,` pelas suas representações em utf-8 [exemplos: ã -> ã , ê -> ê , ç -> ç , ü -> ü ] ou (2) se suas páginas são em php, utilizar a função utf8_encode()[2]
  7. Não esqueça de incluir as tags <meta name=“keywords” content=“” /> e <meta name=“description” content=“” /> para informar ao Google, Yahoo!, Msn, … qual o conteúdo do site.
  8. Há também problemas relacionados a versões anteriores do Internet Explorer. Mesmo xhtml/css válidos podem (geralmente vão) ser mal renderizados pelo IE 6 e IE 5.5 em especial. Mas, em relação a isso, não me preocupo mais; afinal por que raios (1) alguém ainda não mudou para o Firefox, Mozilla, Opera ou Safari? ou (2) (I’m sorry… :loser: ) pelo menos não se deu o trabalho de mudar para o IE7? (…) Para os curiosos, achei um site que renderiza seu site como o IE 6 e 5.5 (preparem-se para chorar depois de ver seu maravilhoso código se transformar em um monstrinho virtual :risos: ) IE Net Renderer.

A lista é grande, e acredito que ainda há mais detalhes. :nugget: Entretanto – além conquistar seu espaço na web – com o tempo e a prática você se acostuma a seguir esses e outros passos para continuar escrevendo códigos mais organizados.

Pois é, people, como diz o povo do wordpress.org: “Code is poetry”. :up:

[1] W3C = World Wide Web Consortium.
[2] Mais informações sobre a função utf8_encode().

geek, , , , 1 comentário

posts relacionados

1 comentário