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 a um certo tempo, comecei a prestar atenção em algumas listas de discussão e nos posts de alguns blogs, e vejo 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”. Refiro-me por “bem formatados” os códigos sem erros de sintaxe (sem tag’s abertas ou fora da hierarquia correta), e “bem estruturados” aqueles que são montados de forma inteligente (usando o correto significado das tag’s 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 tag’s com os seus significados corretos e ter um documento além de válido, mais semântico e com um melhor SEO. Eu poderia ainda criar um documento CSS sem erros de sintaxe, porem excessivamente grande e de difícil manutenção, ou trabalhar de uma forma inteligente a estrutura e as classes, e deixa-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?
Assim como o atributo target=’_blank’, que foi excluído do XHTML devido a intrusividade de abrir uma outra janela. Porém hoje 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 outros meios, apenas para que o código seja validado, mesmo sabendo que o seu código está bem estruturado e com boa acessibilidade.
Alias, se quisermos seguir a 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õe o front-end devem se complementar, mas ainda assim serem 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 a 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 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 a 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 div’s, e sim uma questão de semântica.
Acima de tudo, façam sites para pessoas, e não para validadores.
