Dentro a primeira parte desta série olhamos para as falhas que levam aos elementos estruturais novos no HTML5; dentro a segunda parte da série examinamos detalhadamente as conseqüências dessas falhas; Nesta parte final, vamos procurar um caminho a seguir e tirar algumas conclusões sobre o estado atual do jogo.
Este não é um problema abstrato: as pessoas realmente têm que ensinar essas coisas. A próxima geração de web designers e desenvolvedores será ensinada com HTML5 como ponto de partida. Eu sinto muito por quem tem que tentar explicar e delinear e seccionar a safra atual e futura de estudantes. Talvez eles sigam sabiamente o formato simples que temos que ainda funciona bem: use divs com um ID ou classe / es.
É razoável sugerir que talvez os agentes do usuário no futuro, como navegadores e leitores de tela, façam mais com os elementos estruturais do HTML5, e isso os tornará mais aceitáveis para nós como autores.
Bruce Lawson, da Opera, sugeriu apenas que no Lista de discussão do WHATWG em 2009 :
Afinal, não conheço nenhum agente de usuário que possa usar o tempo, a seção, o rodapé, o datagrid etc, mas a maioria espera que haja em breve.
E aqui está o que Hickson, o editor de HTML5, disse em resposta:
Eu não. A maioria dos novos elementos serve apenas para tornar o estilo mais fácil, para que não tenhamos que usar classes.
Tudo isso, e o editor não vê agentes de usuários usando esses elementos. Eles estão lá, diz ele, para nos salvar de usar classes. Dito de outra forma, o criador desses elementos parece não saber por que eles estão na especificação, exceto por tornar o estilo mais fácil.
Há uma escola de pensamento que diz que só precisamos de um punhado de novas semânticas de qualquer maneira. Afinal, a especificação ficaria inchada se houvesse dezenas ou centenas de novos termos adicionados.
Por um lado, eu concordo. Em termos de estruturação de uma página web básica, eu diria que estaríamos melhor sem os elementos de seção do HTML. O que antes era um exercício direto no uso de divs se tornou uma bagunça complicada no HTML5 sem ganho líquido.
No entanto, em termos de semântica em geral, há casos em que mais significado pode ser adicionado no topo da estrutura da nossa página web (seja HTML4, 5 ou o que vem a seguir) usando atributos adicionais em nossos elementos existentes.
Uma das coisas mais fáceis de implementar em um site novo ou existente são os pontos de referência da ARIA. (ARIA significa Accessible Rich Internet Applications e é uma especificação que define uma maneira de tornar os aplicativos da Web e as páginas da Web mais acessíveis.)
Os pontos de referência do ARIA são um subconjunto da especificação geral do ARIA e um tipo simples de metadados que permite que usuários cegos e deficientes visuais, com leitores de tela, passem para as partes significativas de uma página, ou seja, os "pontos de referência". Nós simplesmente adicionamos role = "landmark-name" a um elemento existente, da mesma forma que adicionamos class = "class-name" a um elemento. Os marcos da AIRA são discutido em comparação com HTML5 aqui .
Os marcos ARIA são muito melhores para o que fazemos atualmente. A nomenclatura é um pouco instável, mas pelo menos eles refletem a prática real de autoria na web. Por exemplo, podemos usar:
(Lembre-se de que as informações de banner, principal e de conteúdo só devem ser usadas uma vez por documento.)
Os marcos da ARIA são uma solução simples que melhora as opções de navegação para usuários de leitor de tela, sem entrar no território obscuro do esboço de documentos do HTML. Eles são rápidos e fáceis de implementar, e realmente devem fazer parte do seu modelo básico de projeto HTML.
Portanto, temos mais semântica para acessibilidade, mas também temos mais semântica disponível para mecanismos de pesquisa.
Primeiro, deixe-me ser absolutamente claro que elementos HTML5 não têm nenhum benefício para SEO. É um mito e precisamos colocá-lo na cama. Usar uma tag de artigo não ajudará você ou seu cliente a ficar acima do próximo. Você pode confiar que o Google descobriu como encontrar e classificar seu conteúdo até agora.
No entanto, os mecanismos de busca estão interessados em entender como melhor exibir (nota: não classificar ) o conteúdo da web de maneira mais estruturada.
Portanto, os principais mecanismos de pesquisa têm, ao longo dos anos, desenvolvido ou adotado maneiras padrão existentes de marcar dados estruturados em uma página da Web para que possam extrair as informações apropriadas. Por exemplo, ao pesquisar por avaliações, você deve ter notado que as classificações por estrelas aparecem nos principais resultados do Google. Esse é um caso de mecanismos de busca capazes de extrair a pontuação da revisão de maneira padronizada e melhorar a exibição de seus resultados. Receitas são outro exemplo, onde o tempo de cozimento é listado para cada resultado. Embora esses dados não melhorem a classificação de um site, o resultado mais detalhado pode incentivar mais usuários a clicá-lo. Portanto, há um possível benefício para um site, e geralmente é necessário em uma situação de corrida armamentista em que todos os concorrentes o fazem. de qualquer forma.
Enquanto este tipo de dados ricos já existe há algum tempo em vários aspectos, apenas no ano passado os principais motores de busca lançado um vasto novo conjunto de padrões para esse tipo de dados estruturados. Eles estão chamando-os de "esquemas", e eles estão alojados em Schema.org . Eles usam o padrão de microdados do HTML e já foram implementados por empresas como eBay, IMDB, Rotten Tomatoes e muito mais.
Este é o maior salto em direção a uma teia mais semântica em anos, e ainda assim foi feito a portas fechadas com pouca fanfarra e sem nenhum processo de padronização. Ela foi lançada sobre nós sem aviso prévio e, desde então, passou pela maior parte sob o radar da comunidade de web design. Há muita sobreposição com a semântica HTML5 também, por exemplo, há esquemas para Artigos , rede Páginas e web elementos da página , entre muito mais esquemas que incluem tudo, desde Episódios de TV para condições médicas . É também o maneira recomendada de descrever vídeos na web.
Depois de todo o debate sobre a semântica do HTML (e a falta dele), os mecanismos de busca deixaram claro que querem muito mais dados semânticos em nossa marcação, mas isso vai acontecer no topo das estruturas existentes, e não com novos elementos.
Mas certamente para nós, como uma comunidade interessada em semântica e padrões da web, nem a abordagem limitada e sem falhas do HTML à semântica, nem a abordagem fechada dos grandes mecanismos de busca é o melhor caminho a seguir.
Em alguns sentidos, o cavalo semântico HTML5 foi trancado; é apenas para nós conter o dano. Quanto ao schema.org, é um mundo totalmente novo, e um que deveríamos estar examinando muito de perto, ou outro pequeno grupo vai determinar o que está em nossos - e os da web - os melhores interesses para nós. Na verdade, isso já pode ter acontecido.
Vamos concluir algumas conclusões.
Há muitas partes boas na especificação HTML5, desde novos recursos de formulários até a implementação da API de histórico e do Canvas. De fato, sem o WHATWG, que tem sido a força motriz por trás do HTML5, ainda estaríamos presos ao HTML4 / XHTML 1.0 enquanto esperávamos que o W3C agisse em conjunto. No entanto, só porque o HTML5 e toda a tecnologia relacionada em torno dele é nova e excitante, isso não significa que temos que aceitar tudo o que nos é dado.
Às vezes vale a pena ver como a salsicha HTML é feita, então sabemos o que estamos comendo. E no caso da semântica estrutural do HTML, eu prefiro passar.
Faminto por mais? O livro de Luke "A Verdade Sobre o HTML5" está disponível por tempo limitado através do nosso site irmão MightyDeals.com com um incrível desconto de 50%.
Você já usou marcos ARIA ou Schema.org? Você vê um futuro para os elementos estruturais do HTML5? Deixe-nos saber nos comentários.
Imagem / miniatura em destaque, usa imagem da estrutura via Shutterstock.