Um Outro Olhar Sobre Validação

Tradução do artigo Another Way to Look at Validation de Aaron Gustafson para o WaSP em Março de 2007

O debate sobre validação já ocorre há muito tempo, com argumentos irados de ambos os lados. No artigo de Ethan Where Our Standards Went Wrong essa discussão é reduzida a duas opiniões contrastantes.

1. Toma a linha dura, afirmando correctamente de que se falharmos ao seguirmos as convenções de uma linguagens, então produzimos algo totalmente diferente e bem, inválido.
2. Tem uma visão pragmática, afirmando correctamente que a geração de código inválido devido a ferramentas com erros ou código de terceiros com erros não nega o comprometimento geral de cada um com os web standards.

Depois ele pergunta "Se as duas visões são correctas, onde é que isso nos deixa?" e diz-nos que estamos num impasse.

Mais tarde no artigo, Ethan [Marcotte na A List Apart] discute modos de «vender» os standards. Faz notar por exemplo que se podem usar balas mais «sexys».

• ciclos de desenvolvimento mais curtos
• custos de manutenção mais baratos, e
• peso descrecente das páginas.

Mas também lamenta as nossas falhar na venda de outras vantagens tais como:

• acessibilidade acrescida
• independência de dispositivo, e
• capacidade de tornar o seu sítio à prova de futuras evoluções

O que me leva de volta à validação e de como devemos de facto usá-la para vender standards.

Ao olhar para trás no ano passado, Ethan nota que cerca de 15% do seu tempo foi gasto a contornar código inválido. Com essa descoberta conclui que os sítios "[i]nválidos podem parecer-se com os construídos com uma fundação válida, código bem formado, mas que na minha experiência invariavelmente o custo para o manter é mais elevado." Isso pode parecer óbvio para si, mas ele argumenta que não é normalmente uma característica que se venda aos nossos clientes como parte do pacote dos standards.

Quando se está a orçamentar um projecto para um cliente ou quando se discute os standards com eles, quais são as vantagens que realça? Porquê?

Seguem-se alguns dos comentários:

1. Rick Curran diz:

   Penso que os dois pontos indicados como falhas que ele menciona são pontos importantes para a venda [dos standards]:

   • acessibilidade acrescida
   • a possibilidade de tornar o sítio à prova de futuro

   Sei que muitos clientes não se preocupam com estas coisas por acharem não terem consequências, mas trata-se realmente de tomar algum tempo para tentar e ajudá-los a compreenderem as vantagens. Tornar à prova de futuro um sítio ao torná-lo mais fácil para se adaptar a novo design mais tarde deve equivaler a uma poupança a longo prazo.

   A acessibilidade é por vezes difícil de vendas para o "homem comum" mas está a tornar-se um ponto a realçar. É aqui que o aspecto da "independência de dispositivo" (que considero parte da acessibilidade) de codificar em conformidade com um standard vale a pena para evitar ter que criar 2 versões separadas de um sítio. Novamente persuadir o homem comum das vantagens pode ser difícil.

2. Robert respondeu:

   Não é difícil escrever código válido. É difícil levar os clientes a escreverem código válido.

   Quando codifica os seus modelos para um CMS, torne-os válidos. Se o cliente acrescentar código inválido, não há nada que se possa esperar que possa fazer. Se vendo a alguém uma arma para caça e ele assalta uma loja, não se pode esperar que eu o prenda. Se for um programador de fundo com muitos recursos, tudo o que o cliente introduza poderá ser corrido através do HTML Tidy antes de o acrescentar à base de dados. Isto pelo menos reduz a potencialidade de o seu cliente bater no 711.

   Como eu disse várias vezes, o XHTML tem o seu lugar. O HTML desculpa mais. Num sítio sobre o qual não tenha controlo sobre aquilo que um utilizador introduz é mais provável que as páginas em HTML continuem a validar. Usar HTML em vez de XHTML não significa que não está a usar Web Standards. Aplique os mesmos standards estritos aos seu código HTML como faria com o XHTML e deixe o seu cliente fazer o que ele irá fazer com o CMS.

   Se a página acabar por não validar devido àquilo que o cliente inseriu não é nada que você tenha feito como designer. Não é um erro seu; o seu comprometimento com os standards foi alcançado quando o sítio limpinho que carregou foi válido. O web design comercial não tem problemas com a validação. O conteúdo gerado pelo cliente tem problemas com a validação. Usar ferramentas para clientes, gráficas, do género do XStandards em conjunto com o HTML Tidy irão ajudar a tornar a coisa mais fácil. Alguma formação simples sobre marcação (ou a utilização de uma marcação alternativa, tal como a Markdown) pode ajudar ainda mais.

   A única outra alternativa é fazer as actualizações você mesmo para se assegurar que o sítio continua a validar. Contudo julgo que isto não é necessário. A situação não é assim tão aborrecida. As ferramentas de que dispomos podem fazer o trabalho.

3. Peter respondeu:

   Não há nada de inerentemente errado com ter elevados ideais, mas por vezes esses ideais são irrealizáveis ou difícieis de realizar em desenvolvimento web na prática.

   O desenvolvimento baseado em standards pode promover as qualidades de perfeição, desejabilidade e excelência para o benefício de todas as partes.

   Como pessoas envolvidas no desenvolvimento, não devemos ter receio a aspirar a oferecer xhtml completamente válido por meio de ferramentas que designamos para serem o nosso CMS.

   Mas a realidade prática é a de alguém com (relativamente) pouco conhecimento, corta e cola a partir de um processador de texto para o nosso modelo válido em XHTML e a não utiliza ferramentas apropriadas para estruturar o documento antes de o publicar.

   Os Web Standards estão a tornar-se mais visíveis fora da redoma dos blogues das pessoas que produzem sítios e de sítios excelentes como este.

   A publicação na web está a mudar e os web standards estão a começar a fazer uma diferença como comunidade, cabe-nos tornar algo anteriormente idealista numa realidade pragmática.

4. Martin diz:

   A aproximação pragmática vende sempre pois é "fazível".

   Se estamos a mudar-nos para uma visão idealista para assegurar que as páginas web sejam 100% código válido, temos que ter algumas ajudas de todos os lados tais como das ferramentas de autoria de web, cms, etc...