Apesar de achar que o auge do frenesi de rechear os rodapés das páginas com selos de validação da W3C já havia passado há um certo tempo, comecei a prestar atenção em algumas listas de discussão e nos posts de alguns blogs e percebi que muita gente ainda se preocupa muito em validar seus códigos HTML e CSS a qualquer custo, e acaba deixando de lado coisas mais importantes. Essas pessoas, ao verem seus documentos validados sem erros, ficam com a consciência tranquila sobre algo que elas não compreendem: a semântica.

Mas, a bem da verdade, é preciso dizer que:

• Validadores apenas encontram erros de sintaxe, de acordo com uma especificação.
• Validadores não reconhecem se o código é bem estruturado.
• Validadores não reconhecem a semântica.

Os validadores reconhecem códigos “bem formatados”, mas não dizem se ele é “bem estruturado”. Por códigos “bem formatados” entenda que são aqueles sem erros de sintaxe (sem tags abertas ou fora da hierarquia correta), e “bem estruturados” aqueles que são montados de forma inteligente (usando o correto significado das tags ou evitando excessos desnecessários de código).

Eu poderia escrever um documento inteiro usando apenas a tag <p> que o meu código seria validado, ou usar diversas tags com os seus significados corretos e ter um documento que, além de válido, também é mais semântico e com um melhor SEO.

Eu poderia, ainda, criar um documento CSS sem erros de sintaxe, porém excessivamente grande e de difícil manutenção, ou trabalhar de uma forma inteligente a estrutura e as classes, e deixá-lo menor e mais flexível para futuras manutenções.

Validadores apenas avaliam erros de sintaxe, mas não pensam conceitualmente.

Selos para satisfazer o ego

Hoje, se eu quiser inserir um botão “like” do Facebook no meu site, ele não vai validar com uma especificação “XHTML 1.0 Strict”, pois nem a tag <iframe> e nem as marcações XFBML constam nessa especificação. Então, devo deixar de usar o botão “like” apenas para ganhar um selo de validação?

O atributo target=’_blank’ também foi excluído do XHTML devido à intrusividade de abrir uma outra janela. Porém, atualmente os navegadores usam abas que organizam as páginas na janela, assim como o acesso a elas, e o uso desse atributo já não é mais intrusivo como antes. Então, devo deixar de usar o target=’_blank’ apenas para ganhar um selo de validação?

Muitos desenvolvedores sentem a necessidade de usar hacks no CSS para igualar a visualização das páginas em todos os navegadores, mas tentam esconder isso com Javascript para passar na validação. Acredito que se um desenvolvedor se propõe a usar apenas marcações que façam parte de uma especificação como o “XHTML 1.0 Strict”, faz todo sentido buscar a validação. Mas se a proposta é usar diferentes opções, hacks e recursos que vão além da especificação, não vejo sentido em ficar buscando formas de ocultar isso com Javascript ou outras formas apenas para que o código seja validado, mesmo sabendo que o seu código está bem estruturado e com boa acessibilidade.

Aliás, se quisermos seguir à risca as recomendações da W3C, não devemos usar o Javascript de forma obstrusiva, isto é, fazer com que a exibição das camadas de conteúdo (HTML) e apresentação (CSS) dependam em partes da camada de comportamento (Javascript). Essas três camadas que compõem o front-end devem se complementar, mas ainda assim ser independentes. Fornecer diferentes conteúdos (HTML) e apresentações (CSS) através de comportamento (javascript) é obstrusivo, e não recomendado pela W3C.

O papel da W3C

O trabalho da W3C é de extrema importância para a evolução da web, mas nem de longe suas especificações são perfeitas. Muitas vezes elas entram em conflito, além de não acompanharem o ritmo de evolução da web – basta ver que muito antes de surgir a propriedade “border-radius” no CSS3 (que ainda é só um rascunho), muita gente já criava alternativas com imagens recortadas para conseguir uma borda arredondada no layout.

Tim Berners-Lee, que além de estar à frente da W3C, é o homem que inventou essa coisa toda, pode até ser uma cara bem bacana, mas não podemos esquecer que a W3C é formada por diversas empresas com interesses distintos, e nem sempre esses padrões caminham como deveriam. Quando não são as especificações que caminham devagar, são os navegadores e os dispositivos que são limitados, e a consequência disso é que nós desenvolvedores temos que ficar discutindo e descobrindo diferentes formas de fazer com que as coisas funcionem da forma que queremos em nossos projetos.

A validação de código ainda faz sentido?

O XHTML veio como uma evolução do HTML, que corrigia algumas falhas estruturais do mesmo. Por ter regras baseadas no XML, o bom uso do XHTML permite a produção de um código bem formatado e minimamente bem estruturado. Foi com o XHTML e com o crescimento das discussões sobre SEO que os desenvolvedores começaram a compreender melhor o uso correto das marcações. Mas o próprio XHTML ainda é limitado em termos de semântica, e fato é que o novo HTML5 está trazendo uma evolução semântica com relação ao significado das novas marcações, que fazem referência à estrutura do layout das páginas.

Caso você não queira aventurar os seus projetos pelo HTML5, já que a especificação definitiva ainda não foi lançada, a melhor opção ainda é, sim, o XHTML, ao menos pela tentativa de criar um código mais limpo, organizado e otimizado. Mas criar um código bem formatado com “XHTML 1.0 Strict” não irá resolver todos os seus problemas. Quem trabalha com desenvolvimento front-end, antes mesmo de se preocupar com a validação, deve procurar compreender e aplicar conceitos como semântica, acessibilidade e SEO, e nenhum validador poderá resolver isso por você.

Não estou dizendo aqui que a validação de código perdeu sua importância. Pelo contrário, ter um código bem formatado é extremamente necessário. Esse não deixa de ser um trabalho mecânico e, por isso mesmo, nada melhor que um validador (uma máquina) para conferir todo esse trabalho. Mas, como eu já disse anteriormente, trabalhar com web standards não é uma questão de trocar tabelas por divs, e sim uma questão de semântica.

Acima de tudo, façam sites para pessoas, e não para validadores.

Gostou? Então siga-me no Twitter: @eduagni.

Fonte: FRONTEND.BLOG