Oito dicas para servir (X)HTML

Publicado em: 18/07/2007

Autor: Tantek Çelik
URL do original: http://tantek.com/log/2006/07.html#d27t1218
Título original: 8 steps to serving better (X)HTML

Introdução

Eric Meyer, Aaron Gustafson e eu criticamos aspectos referentes à marcação, estilização e scripts de vários sites submetidos para análise por nossos ouvintes no evento "An Event Apart" (NT: encontro web standard realizado em Nova York na segunda semana de julho de 2006). Conforme prometi, apresento a seguir um sumário das minhas críticas. Constatei a existência de uma quantidade razoável de erros comuns e maneiras de corrigí-los, por outro lado, alguns sites forneceram exemplos marcantes e ilustrativos de erros. Na verdade vi algumas coisas bem estranhas no código, coisas que eu nunca tinha visto antes. Apresento aqui um sumário de todas as críticas que fiz, composto por oito itens sendo dois deles com sub itens, que devem ser levados em consideração por qualquer desenvolvedor que queira aperfeiçoar o código da sua página. Estas são minhas críticas pessoais, deixarei por conta de Eric e Aaron publicar as críticas deles se assim desejarem.

  1. Valide suas páginas web! Eu não posso deixar de bater nesta tecla. Todos os sites analisados, exceto um, são INVÁLIDOS. Como pode alguém esperar que CSS ou Javascript baseado no DOM funcione de maneira confiável em uma marcação (X)HTML inválida? Conteúdo válido poupará à você muitas horas de trabalho a procura de bugs para CSS e DOM. Um site que nos foi indicado para crítica e que não validou na ocasião da análise (mês de julho de 2006 - Valid XHTML 1.0 Transitional) foi o Piece of Cake Parties ) que foi alertado e validou o código. Bom trabalho. Para os demais - vergonhoso para você submeter um site para revisão sem primeiro certificar-se de que ele é válido. Para os curiosos mostro a seguir os erros de validação mais comuns:
    • Caractere ampersands (&) sem escape. Para ser honesto, confesso que vez ou outra eu mesmo ainda cometo este deslize. Certifique-se de codificar ampersdand com letras minúsculas & eu encontrei uma codificação com letras maiúsculas & e isto é inválido até mesmo na marcação não case-sensitive HTML4.
    • Falta de fechamento para tags vazias do XHTML (p.ex. uso de <link> em vez de <link />, <img> em vez de <img />, <br> em vez de <br />)
    • Elementos nível de bloco dentro de elementos inline (p.ex. colocar uma <div> ou <p> dentro de <a> ou <span>).
    • Tags de fechamento fora de posição no código, tal como </ul> em lugar errado.
    • Esquecimento de tags de fechamento, mais frequentemente a tag </div>
    • Tags de script sem o atributo obrigatório, type
    • Folhas de estilo na seção <body>! Você não pode fazer isto.
    • Atibutos proprietários desconhecidos como por exemplo autocomplete
    • Nome de atributos inválidos (camelCased) em documentos XHTML (p.ex. onSubmit deve ser escrito onsubmit)
    • Elementos <form> sem atributo action
    • Vários elementos <body>! Fala sério, as pessoas ainda fazem isto? Eu me lembro de uma técnica dois idos de 1996, chamada "fade-in background via uma série de tags <body bgcolor>". Ah sim.
    • Uso do atributo target em documentos (X)HTML Strict. Se você precisa usar o atributo target então há duas escolhas, usar DOCTYPEs Transitional, ou simular o atributo target dinamicamente usando script semântico, ou seja, com uso de nomes de classe semânticos.
  2. Elimine layout com tabelas e imagens espaçadoras GIFs. Já falei sobre isto.
  3. Elemento <meta> com palavras chave sem valor. Não perca tempo e espaço com esta tags pelos Principles of visibility and human friendliness (especialmante pelo fato de que mecanismos de busca não se importam com isto).
  4. Melhorar nomes de class. Diretrizes e exemplos de como escolher nomes de classes:
    • Use Context before class. p.ex. se você nomeou <ul class="nav">, não há necessidade de usar <li class="navitem"> para os itens da lista, use simplesmente <li> e seletores contextuais para casar os itens: ul.nav li.
    • Use lowercase classnames (letras minúsculas nos nomes de classes) e IDs, isto é, evite nomes de classes e de IDs, tipo camelCased. Por exemplo em lugar de id="siteNav" use id="sitenav". Assim fazendo, você evitará muitas dores de cabeça com eventuais troca de letras maiúsculas por minúsculas nos nomes e nas folhas de estilos.
    • Resumindo: qualquer um que envie um site para análise, por favor leia antes um artigo que escrevi há 4 anos atrás denominado A Touch of Class.
    • Evite nomes de classes que lembrem apresentação, tais como "trechoPreto", "clearFloat", "espacamento", ou "linkDireito". Por exemplo em lugar de "linkDireito" use "ultimo-link" que é mais semântico, mais legível, e em letras minúsculas. Ver Class for meaning not show. (Notar que se tivessemos considerado estes 4 subitens individualmente teríamos um total de 12 itens.)
  5. Evite grandes blocos de linhas em branco no código. Grandes espaços em branco no código, que eu saiba, não servem para nada. Retire tais blocos do código.
  6. Use 'rel' e 'hreflang' para traduções. Links para versões em idiomas alternativos devem ser codificados com uso de rel="alternate" e p.ex. hreflang="es" para uma versão em espanhol. O valor alternate rel significa uma versão alternativa da página e hreflang significa o idioma da página definido em href (diferente do atributo lang que significa o idioma do conteúdo do elemento).
  7. Servindo código comentado. Código de marcação comentado, deve ser removido no servidor. Muitos sites servem suas páginas via PHP, Perl, Ruby etc., normalmente usando templates. Em lugar de usar marcação de comentário do HTML(SGML) <!-- --> para desabilitar trechos de código, use a marcação de comentário nativa da linguagem escrita para gerar os templates, fazendo com que a desabilitação de trecos de código seja feita no servidor poupando tempo e espaço na rede. Contudo, se suas páginas são estáticas você terá que usar marcação para comentários do SGML (como é o blog do autor da matéria).
  8. hCard! Por fim, quase todos os sites que analisamos podem usar hCard ( use hCard) para o código de marcação e informação de contato. Seja o website de uma universidade, uma agência de webdesign, um fabricante de equipamentos, uma agência de viagens, uma promotora de eventos ou de um comediante. E por falar nisto, os desenvolvedores do site Piece of Cake Parties (é isto mesmo, o site a que me referi lá em cima no item número1 e que agora valida para XHTML 1.0) estiveram presentes no evento em fizemos as críticas e agora o site já tem seu hCard na parte inferior da home page incluindo um link para você adicioná-los ao seus favoritos. Eles são muito detalhistas também. A classe da página class="org" deveria ser class="org fn", e class="url fn" deveria ser simplesmente class="url". Com estas correções o link "adicionar aos favoritos" deve funcionar e gerar vCards apropriados para clientes desktop.

    E por falar em website de comediante, o desenvolvedor do site stevemartin.com esteve presente ao evento e agora a página de contato do Steve Martin's foi marcada apropriadamente com hCard e um link para favoritos. Sim, é o próprio Steve Martin. Eu acredito que ele deve ser o primeiro comediante famoso com um hCard. Bom trabalho Alison!

E isto é tudo. Oito lembretes que eu extrai das análises de sites na sessão Criticando Códigos do evento. Oito críticas aplicáveis de modo geral a qualquer website. Eu espero que você encontre pelo menos uma que possa ser usada para melhorar seu website.

topo