A HTML5, apesar de ainda demorar para ser uma recomendação oficial do W3C, já está sendo muito usada no desenvolvimento web no mundo inteiro – incluindo este humilde blog. Mas, devido ao “boom do HTML5” causado pela ânsia dos desenvolvedores começarem a usar a linguagem imediatamente, alguns menos atentos estão sujeitos a cometer alguns erros que a nova especificação do HTML pode dar ensejo.
Para o caso, é preciso prestar atenção em alguns detalhes importantes para evitar erros comuns de HTML5.
Não use section como contêiner para estilização
Um dos problemas mais comuns que está acontecendo em relação à implementação da HTML5 é os desenvolvedores, arbitrariamente, estarem substituindo <div> por <section> para usar na estilização. No HTML4 ou XHTML, é normal um código como:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
<div id="wrapper"> <div id="header"> <h1>Título primário</h1> </div> <div id="main"> <!-- conteúdo --> </div> <div id="secondary"> <!-- conteúdo --> </div> <div id="footer"> <!-- conteúdo --> </div> </div> |
Então, sem nenhum motivo plausível, alguns estão alterando seu código para:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
<section id="wrapper"> <header> <h1>Título primário</h1> </header> <section id="main"> <!-- conteúdo --> </section> <section id="secondary"> <!-- conteúdo --> </section> <footer> <!-- conteúdo --> </footer> </section> |
E isso, apesar de poder estar certo, na grande maioria dos casos, está errado… Se é preciso um elemento somente para estilização, não faz nenhum sentido deixar de usar <div>; o elemento <section> não foi criado para isso! Segundo sua documentação,
O elemento
<section>representa um documento genérico ou seção de aplicação[…]. O elemento<section>não é um elemento contêiner genérico. Quando um elemento é necessário para fins de estilo ou como uma conveniência para execução de scripts, os autores são incentivados a utilizar o elemento<div>.
Ou seja, as indicações de uso do <section> para 99% dos casos são:
- Não usá-lo apenas como “gancho” para estilos ou scripts (para isso, já existe
<div>) - Não usá-lo se o
<article>,<aside>ou<nav>forem mais apropriados - Não usá-lo a menos que exista, naturalmente, um título no início da seção
Só use header e hgroup quando forem necessários
Não faz sentindo escrever HTML de forma a ferir a semântica, certo? Infelizmente, não é difícil encontrar elementos <header> e <hgroup> sendo usados de forma inapropriada. Procure se informar mais a respeito da função deles, mas, resumindo:
<header>representa um grupo introdutório e/ou navegacional e, usualmente, contém o(s) título(s) de<section><hgroup>agrupa um conjunto de elentos<h1>–<h6>quando o título de uma seção tem vários níveis, tais como subtítulos, títulos alternativos, etc
Uso excessivo de header
O elemento <header> pode ser usado quantas vezes forem necessários num documento, o que está causando confusões do tipo:
|
1 2 3 4 5 6 7 |
<article> <header> <h1>Título primário</h1> </header> <!-- conteúdo --> </article> |
Se o <header> contém somente um elemento de título, na verdade, ele não precisa ser usado. O elemento <article> já garante que o título vai constar no outline do documento, e, porque <header> não contém múltiplos elementos (como consta em sua definição), por que escrever código desnecessário? A solução é simples:
|
1 2 3 4 |
<article> <h1>Título primário</h1> <!-- conteúdo --> </article> |
Uso incorreto de hgroup
Basicamente, não se deve usar <hgroup> com <header> quando:
- Há somente 1 elemento-descendente de título
- O
<hgroup>funcionaria bem por conta própria (ou seja, sem<header>)
O primeiro problema pode ser visto no código:
|
1 2 3 4 5 6 7 |
<header> <hgroup> <h1>Título primário</h1> </hgroup> <!-- conteúdo --> </header> |
No caso, deve-se, simplesmente, remover o elemento <hgroup>:
|
1 2 3 4 |
<header> <h1>Título primário</h1> <!-- conteúdo --> </header> |
O segundo problema é outro caso de incluir o elemento quando ele não se faz necessário:
|
1 2 3 4 5 6 |
<header> <hgroup> <h1>Título primário</h1> <h2>Título secundário</h2> </hgroup> </header> |
Se não há elementos adicionais dentro de <header> (isto é, irmãos de <hgroup>), basta remover o <header>:
|
1 2 3 4 |
<hgroup> <h1>Título primário</h1> <h2>Título secundário</h2> </hgroup> |
Não englobe todas listas de links com nav
Com mais de 40 novos elementos (no dia da publicação deste artigo), não é incomum haver dúvidas e erros de HTML5 na hora da utilização de alguns destes. Infelizmente, ainda é o caso com o elemento <nav>. Como consta em sua especificação,
Nem todos os grupos de links em uma página precisam estar contidos em um elemento
<nav>– o elemento se destina, principalmente, a seções que consistem em blocos de navegação principal. (Grifo nosso)
Atenção ao grifo “blocos de navegação principal” que, apesar de ser aberto a algumas interpretações, identifica-se mais com:
- Navegação primária
- Navegação secundária
- Navegação in page (dentro de um artigo longo, por exemplo)
Como diretivas gerais (e seguindo a lógica contida na especificação), não se aplica o elemento <nav> a:
- Controles de paginação
- Social links
- Categorias e Tags (de um artigo de blog, por exemplo)
- Navegação terciária
- Rodapés muito elaborados
Nos momentos de dúvida ao usar <nav>, pergunte-se a si mesmo: “Essa é uma navegação principal?”. Para ajudar a responder, considere as seguintes “regrinhas”:
- Não use
<nav>a menos que você pense que<section>também seria apropriado com<hx> - Você adicionaria um link “Pular para o conteúdo” por questões de acessibilidade?
Se a resposta para essas perguntas for “não”, então, provavelmente, não se trata de um <nav>.
Erros comuns com o elemento figure
Nem toda imagem é figure
Os novos elementos não foram criados para que os desenvolvedores tivesse trabalho de escrever código a mais. Pensar isso é um erro comum de HTML5. Algumas pessoas, ao “atualizarem” seus sites para HTML5, colocam o elemento <figure> em todas as imagens! Fazer isso não serve pra nada e a pessoa só está aumentando o próprio trabalho…
A especificação define <figure> como
algum conteúdo de fluxo, opcionalmente com um
<figcaption>, que é auto-contido e, tipicamente, referido como uma unidade única a partir do fluxo principal do documento.
E é aí que reside a beleza do elemento <figure>: ele pode ser afastado do conteúdo principal (para uma barra lateral, por exemplo) sem afetar o fluxo do documento.
Se se tratar de uma imagem puramente de apresentação, que não é referenciada em outras partes do documento, definitivamente não se trata de um <figure>. Outros casos de uso variam, mas, pra começar, pergunte-se a si mesmo: “Esta imagem é necessária para compreender o contexto atual?”. Se não, provavelmente não é um <figure> (pode ser um <aside>, talvez). Se sim, pergunte-se novamente: “Eu poderia movê-lo para um apêndice?”. Se a resposta para ambas as perguntas for “sim”, então, provavelmente, trata-se de um <figure>.
O logo não é um figure
Os mesmos princípios mostrados acima também se aplicam ao logo do site. Não é tão incomum se ver por esses dias códigos parecidos com:
|
1 2 3 4 5 6 7 8 9 |
<header> <h1> <figure> <img src="/img/logo.png" alt="Nome do site" class="hide"> </figure> Nome do site </h1> </header> |
Isso, simplesmente, não está certo… E não estou dizendo sobre o fato de o logo estar dentro de um <h1> – isso, por si só, renderia um artigo inteiro. A real questão é o abuso do elemento <figure>! No caso, a marcação poderia, simplesmente, ser feita assim:
|
1 2 3 |
<header> <h1>Nome do site</h1> </header> |
figure pode ser mais que uma imagem
Ao contrário do que muitos pensam, <figure> pode ser áudio, vídeo, um gráfico (em SVG, por exemplo), uma citação, uma tabela, um bloco de código ou qualquer combinação destes e muito mais!
Não se limite a usar <figure> somente em imagens. Nosso trabalho como aficionados por padrões web também é de descrever com precisão nosso conteúdo através de uma correta marcação.
Não inclua atributos de tipo desnecessariamente
Este é, provavelmente, um dos erros mais comuns de HTML5. Embora não seja, tecnicamente, um erro, é uma boa prática evitar a inclusão de atributos de tipo.
Em HTML5, não há necessidade de incluir o atributo type em <script> e elementos <style>. Embora possa ser um pouco custoso remover o atributo se ele está sendo colocado automaticamente pelo CMS em uso, não há, realmente, nenhuma razão para incluí-lo se você está codificando na mão ou se tiver absoluto controle sobre o código que está sendo usado.
Uma vez que todos os navegadores esperam que scripts sejam JavaScript e estilos sejam CSS, isso se faz desnecessário:
|
1 2 |
<link type="text/css" href="styles.css" rel="stylesheet"> <script type="text/javascript" src="scripts.js"></script> |
Use somente:
|
1 2 |
<link href="css/styles.css" rel="stylesheet"> <script src="js/scripts.js"></script> |
Uso incorreto de atributos de formulários
Provavelmente, você deve estar ciente de que o HTML5 introduziu uma série de novos atributos para formulários (bem, você deveria). Com isso, alguns erros, por parte dos desenvolvedores, também começaram a aparecer.
Atributos booleanos
Vários dos novos atributos de formulário são booleanos, ou seja, sua simples presença na marcação assegura o comportamento esperado. Esses atributos incluem:
autofocusautocompleterequired
Então, alguns desenvolvedores começaram a escrever coisas do tipo:
|
1 2 |
<input type="text" name="name" required="true"> <input type="email" name="email" required="1"> |
O parser do navegador ainda vai considerar o campo como obrigatório pelo simples fato de “required” estar lá, mas, e se o valor pretendido fosse outro?
|
1 |
<input type="email" name="email" required="false"> |
O parser ainda verá o atributo required e implementará o comportamento, mesmo que essa não tenha sido a intenção!
Há 3 maneiras válidas para um atributo booleano ser aplicado (a segunda e a terceira opções só se aplicam para XHTML):
requiredrequired=""required="required"
Portanto, em HTML5 é somente:
|
1 |
<input type="email" name="email" required> |
Conclusão
Certamente, é impossível listar todos os erros de HTML5 que os desenvolvedores cometem, mas estes são alguns dos mais vistos nos códigos – que podem ser encontrados em qualquer site de “galeria HTML5”.
Que outros erros comuns de HTML5 você está vendo por aí? Na sua opinião, quais áreas exigem mais atenção? Comente!