Não validou. E agora?
Voltei!!! Andei meio sumido, mas aqui estou de volta, e prometo ficar (tá, agora é pra valer mesmo). Fiquei meio enrolado com o FrameWorX, e acabei desistindo dele por um tempo, deixa ele descansar. Cortando o papo furado, vamos ao assunto de hoje: Validação. Será ela tão importante?
Quando os padrões “apareceram” aqui no Brasil, e ganharam uma certa forcinha, acredito que a maioria dos desenvolvedores conscientes correu para o validador da W3C, para ver os trabalhos validados e colocar aqueles selinhos de validação. Se não validasse, tudo de novo, até estar 100% validado. Isso leva, várias vezes, em um bom tempo ajustando em todos os navegadores, para que fique igualzinho ou pelo menos apresentável.
Creio que hoje essa “mania” passou. Claro que temos vários sites validados, mas é realmente necessário todo esse trabalho? Essa é mais uma questão filosófica, e discutiremos aqui.
Como todo mundo sabe, o validador do W3C (seja ele (X)HTML ou CSS) verifica apenas se o código está bem escrito, avisando sobre tags não fechadas, erros de código e etc. Ele não diz se o site está apresentável em todos os navegadores, não verifica semântica, não mede desempenho, nada. Então, “ser ou não ser” validado?
Analisemos a nossa situação. Temos um documento não validado, e pra ajudar um browser horrível (não quero citar o nome IE para não constranger), mas nosso documento funciona perfeitamente nele e em outros browsers decentes. Existe apenas um único erro de código, que serve exatamente para nosso querido amigo azul. Ahh! Temos um prazo também, e só existe uma solução para corrigir o tal bug, mas a solução é enorme, e demoraria séculos para terminar. Temos as seguintes opções:
- Suicidar-se
- Começar a chorar
- Apelar pra tudo quanto é santo
- Perder o emprego
- Entregar o trabalho não validado
Tempo… E aí, já decidiu? Considere que as três primeiras opções não são de grande ajuda. Sobram-nos duas. Perder o emprego também não é bom…
Os nossos browsers de hoje em dia não conferem nossa marcação. Se está errado, e funcionando, tudo certo. É lógico que um trabalho validado é uma conquista, mas quando se tem um prazo pequeno não vale a pena perder boa parte do tempo para consertar um bug.
Em um futuro muito distante, os browsers lerão tudo como XML. Aí sim precisaremos de marcações impecáveis. Mas se você serve seus documentos como “text/html”, não há problema (muito).
Cortando toda minha enrolação, resuminho pra vocês: não perca tempo para consertar um bug, se está tudo certo deixe assim. Mas é lógico que se você tiver um tempinho de sobra, faça o possível para validar tudinho. Tempo = dinheiro. Validação = menos tempo. Validação + tempo extra = tudo validado. Captou? Até!

Opa, e ae Julio, beleza?
Bom, primeiramente gostaria de dizer que não estou gostando nada dessa moda anti-validação heheh
E agora fiquei feliz em achar um blog mais calmo de um conhecido meu pra poder discutir a questão.
bom, vamos lá friendi:
1) Na validação do HTML: Não é difícil deixar as tags organizadas de forma que o W3C aceite. É a coisa mais simples do mundo. Não vejo nenhum problema. É como escrever o português correto.
2) Na validação do CSS: Hoje em dia, é muito, muito fácil fazer um CSS que valide. Já existem hacks que validam, comentários condicionais, etc. Diversas formas de fazer seu CSS validado.
3) Por que o pessoal anti-validação costuma colocar semântica e validação como inimigas? Pôxa, as duas não podem andar juntas não?
Eu não sou anti-validação! Pelo contrário, sou um fã dela. Mas é que tem um pessoal meio “maníaco” por aí. Se vc tem tempo suficiente (não de sobra, acho que exagerei), faça o possível para validar. Já se o tempo é curto, e seu chefe nem quer saber de WS, aí são outros 500…
heheh. Certo.
Mas eu ainda acho que é costume.
Sei lá, to acostumado. Não vejo muita dificuldade.
Mas como vc disse: se tem um item que não valida e dá erro no validador da w3c (sim, há erros por lá. Já me pediram atributo xml:lang para scripts), não compensa você perder tempo pra corrigir algo que sabe que está certo.
É isso aí.