Entenda a Validação HTML5 de uma vez por todas!

Um programador quando faz a transição de HTMl4 para HTML5 deve perceber como funciona a validação HTMl5, pois esta funciona de uma maneira bastante diferente da sua antecessora. Antes de mais deve-se ter em conta que o validador HTML5 da W3C ainda é experimental, e por isso mesmo, irá garantidamente sofrer algumas mudanças durante os próximos meses. A primeira mudança que verificámos foi que quando se faz a validação de uma página é-nos mostrado um aviso que diz que o validador verificou o documento com uma ferramenta experimental: Verificador de conformidade HTMl5. A partir de agora o termo Validação será substituído por Verificação de Conformidade. É certo que estando o termo “validar” tão enraizado no vocabulário de cada um, será difícil implementar esta alteração num curto espaço de tempo. Nada de grave, certamente!

Para termos uma ideia geral das diferenças, vamos fazer uma comparação de validação entre HTMl5 e XHTML, utilizando o mesmo código base:

<!DOCTYPE html>
<head>
<meta charset="UTF-8" />
<title>Validação HTML5 Escola Criatividade</title>
<link rel="stylesheet" href="style.css">
<script></script>
</head>  

<embed>  

Teste #1<br>  

<p>  

<p>Teste #2</P>  

<form>  

<input>  

</form>  

<textarea>Teste</textarea>  

<a href=index.html target="_blank"><div>& Teste #3</div></a>

1. VALIDAÇÃO HTML5

Vejamos então como correu a validação HTML5 do código mencionado acima:

Validação HTML5

Na validação HTML5, não foram encontrados erros e o documento passou na inspeção. Isto significa que o código utilizado é 100% HTMl5. Como iremos verificar, a validação entre HTML5 e XTHML tem imensas diferenças.

2. VALIDAÇÃO XHTML

Para a validação XHTML fizemos 2 alterações no código base: Alterámos o Doctype e a codificação de caracteres:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Validação HTML5</title>
<link rel="stylesheet" href="style.css">
<script></script>
</head>  

<embed>  

Teste #1<br>  

<p>  

<p>Teste #2</P>  

<form>  

<input>  

</form>  

<textarea>Teste</textarea>  

<a href=index.html target="_blank"><div>& Teste #3</div></a>

E este é o resultado:

Validação XHTML

Como se verifica, na validação XHTML foram apontados 23 erros (Este código tem apenas 25 linhas!), ao contrário da validação HTML5 onde não foram apontados erros. A esta altura você já deve estar pensando: “Não falta nada nesse código?”

3. ANÁLISE

Os leitores mais atentos certamente que terão notado os erros XHTML nas nossas 25 linhas de código. No entanto, em HTML5 não são erros, é toda uma nova forma simplificada de programação. No nosso código nem sequer existe a tag <html>!

Vejamos ao pormenor aquilo que são considerados erros em XHTML e que em HTML5 é aceite:

Como referido antes, o elemento <html> não existe.
Tag <body> não existe.
Fecho das tags <body> e <html> não existe.
O elemento <script> não tem o atributo type.
Os elementos <meta>e <link> não estão fechados.
Um elemento <br> sem / de fecho.
Um elemento parágrafo sem tag de fecho.
Um elemento form sem atributo action.
Um elemento <textarea> sem atributos rows e cols.
Um elemento âncora com um atributo href sem quotação.
Um elemento de nível de bloco <div> dentro de um elemento em linha <a>

Neste momento já constatou que existem efectivamente muitas diferenças na validação de código entre HTML5 e XHTML. No entanto HTML5 foi programado para ser compatível com versões anteriores, HTML4 e XHTML. Na validação HTML5 tivemos o prazer de obter a validação, enquanto que na validação XHTML foram apontados 23 erros. Aquilo que suporta esta diferença e permite que não sejam apontados os erros, é a separação da validação HTML5 do chamado “linting”. Um validador não deverá apontar erros para inconsistências de estilização de código, mas apenas apontar erros de código propriamente dito. Um pouco por todo o mundo, os desenvolvedores têm pedido uma ferramenta de “lint” HTML. De momento existe pelo menos uma ferramenta online que o permite fazer, embora não seja certa a sua qualidade, poderá visitá-la aqui.

4. CONCLUSÃO

Resumindo, o facto de os validadores não apontarem erros, não quer dizer que eles não existam e que o código está bom. Os programadores deverão sempre adoptar um estilo de código completo e consistente, de modo a mantê-lo limpo e organizado. Deste modo irão reduzir drasticamente a possibilidade de criar erros de código, e facilitar a sua leitura. Um bom código não é só aquele que passa nos validadores, é também aquele que está organizado, optimizado e limpo.

Para finalizar, um obrigado aos nossos colegas da ImpressiveWebs.

Até já!