Os elementos estruturais do HTML - artigo, seção, nav e lado - são, à primeira vista, algumas das partes mais fáceis da especificação HTML5 para entender e implementar. No entanto, são na verdade algumas das partes mais mal especificadas, mal compreendidas e mal implementadas do HTML5.
Criado arbitrariamente; eles tentam introduzir uma maneira totalmente nova de estruturar páginas da web; eles violam os princípios de design do próprio HTML; eles prejudicam a acessibilidade para alguns usuários; e você não deveria usá-los.
Sim, estou lançando armas contra essa parte específica do HTML5, mas, por favor, não pense que sou "anti-HTML5". Eu escrevi um livro sobre HTML5 Eu adoro a web aberta, adoro bons padrões da web e adoro o fato de que, depois de passar por uma década de estagnação, a inovação nas tecnologias da web está acontecendo agora a uma velocidade extremamente impressionante. Isso, no entanto, não significa que temos que aceitar tudo o que nos é dado. Nós não temos que comer tudo na placa HTML5, mesmo se acharmos partes do prato bastante saborosas. Algumas partes provavelmente precisam ser enviadas de volta para o chef.
Há partes boas e ruins na enorme especificação HTML5, e vamos pensar criticamente sobre uma parte muito específica da especificação: a seção, ou elementos "estruturais" introduzidos pelo HTML5. Então, vamos colocar nossos chapéus de detetive e olhar de onde esses novos elementos realmente vieram, como eles devem ser usados, e como nós, a comunidade de web design, fundamentalmente os entendeu mal, essencialmente fazendo a especificação. Vamos questionar a própria base para esses elementos e acabar com alguns mitos sobre eles ao longo do caminho.
Vamos acabar com um mito que foi repetido ad nauseum sobre esses elementos: a ideia de que eles são baseados em pesquisas sobre como nós, a comunidade da web, estávamos marcando nossos documentos. É um mito que tem sido repetido em livros, blogs e palestras há anos, e simplesmente não é verdade. Como eu sei? Eu perguntei.
Quando estava pesquisando as origens desses elementos, decidi perguntar ao editor da especificação HTML5, Ian Hickson, de onde vinham esses elementos. Ele respondeu:
Eu e outros colaboradores do WHATWG [os adicionamos], [em] 2004ish, porque eles eram elementos óbvios para adicionar depois de ver como os autores usavam HTML4. Mais tarde (final de 2005, início de 2006) fizemos uma pesquisa objetiva para descobrir quais eram as dez principais classes HTML e descobrimos que elas combinavam exatamente com os elementos que adicionamos, o que era conveniente.
Vamos dividir isso: primeiro, Hickson e os membros do WHATWG adicionaram esses elementos antes que qualquer pesquisa fosse feita . Você pode mergulhar nos arquivos da lista de discussão do WHATWG (felizmente públicos) e descobrir as primeiras discussões sobre esses elementos por si mesmo. Por exemplo, você pode ver Hickson discutindo-os em novembro de 2004, com comentários como este :
Sim, pretendo incluir coisas como [elementos semânticos] em Web Apps. Atualmente, o quadro branco do meu escritório tem uma lista de elementos sob o título “ELEMENTOS DE NÍVEL DE BLOCO HTML5” e estou tentando descobrir como fazê-los funcionar bem (os elementos em questão são mencionados no rascunho, mas o rascunho não lida bem com cabeçalhos). Eu não olhei para a marcação inline ainda, mas isso também está nas cartas.
Isto é, parece que a semântica estrutural do HTML5 veio a ser: um homem, um quadro branco e alguma entrada de outros membros do WHATWG. (O WHATWG, ou Web Hypertext Application Technology Working Group, foi formado por representantes de navegadores em resposta ao abandono do HTML pela W3C para o ideal utópico de XHTML 2.0).
Os elementos usados por milhões de documentos que estivemos discutindo e debatendo foram, ao que parece, criados arbitrariamente por capricho do editor de HTML5 em 2004. (E foram recebidos com um crítica astuta e algumas previsões tristemente precisas quase imediatamente.)
Tantek tem insistido em pesquisas antes de especificar novos formatos por um longo tempo no contexto de microformatos e, finalmente, as especificações do WHATWG serão projetadas de forma similar com dados reais, em vez de extrairmos material de nossas atividades coletivas. - Ian Hickson
Isso nos leva ao segundo ponto. Em dezembro de 2005, cerca de um ano depois de apresentar esses novos elementos, Hickson (funcionário da Google) fez uma pesquisa sobre como os documentos eram escritos usando o vasto banco de dados de documentos do Google. A pesquisa foi "uma análise de uma amostra de pouco mais de um bilhão de documentos, extraindo informações sobre nomes de classes populares, elementos, atributos e metadados relacionados". IDs não foram incluídos na pesquisa. Os resultados foram publicados pelo Google como Estatísticas de Autoria na Web (2005) .
A parte crítica da pesquisa, no que diz respeito aos elementos estruturais do HTML, era a descobertas de classes que, apesar de usar uma amostra onde ~ 900 milhões dos 1 bilhão de documentos aparentemente não tinham nenhuma classe, continham algumas classes comuns que tenho certeza que já usamos em nossos projetos antes: rodapé, menu, título, texto pequeno , conteúdo, cabeçalho, nav, copyright, botão, principal e assim por diante.
Hickson, em seguida, fornece seu giro nos dados, sugerindo que essas classes "realmente [mapeiam] muito bem os elementos que estão sendo propostos em HTML5" e fornece uma tabela comparando as descobertas da pesquisa e os novos elementos em HTML5: um rodapé classe está na pesquisa, um elemento de rodapé está em HTML5; uma classe de cabeçalho está na pesquisa, um elemento de cabeçalho está em HTML5; as classes text , content , main , body estão na pesquisa, e, err… o artigo está em HTML5 que, como veremos, não combina de forma alguma; seção não é encontrada, o que também é digno de nota.
Tomado pelo valor de face, isso é bastante razoável. Eu uso rodapé, você usa rodapé, rodapé está em HTML5. Qual é o problema?
O problema é, se você ler o real Especificação HTML5 , os elementos em HTML5 são definidos de uma maneira que tem pouco a ver com o modo como tradicionalmente os usamos.
Por um lado, Hickson introduziu um conceito totalmente novo de estruturar uma página web em HTML5 com elementos de corte . Por outro lado, Hickson está comparando seus elementos de seção HTML5 com as classes usadas na natureza sem entender o que essas classes foram realmente usadas. Um exemplo clássico é o "cabeçalho", que a maioria de nós usaria para a área na parte superior da página, mas a especificação HTML5 sugere que você possa usá-lo para o cabeçalho de cada comentário em uma página . Mesmo. Só porque as classes na pesquisa e os elementos em HTML5 têm o mesmo nome não significa que seus usos sejam os mesmos.
Agora, se fosse comunicado claramente que novos elementos foram introduzidos com um novo propósito, e um raciocínio claro, então isso não seria tão ruim. Mas não foi isso que nos disseram.
Aqui Hickson em 2009 , respondendo a uma pergunta sobre o propósito da seção, nav, article, aside e outros:
Eles estão, mais ou menos, preenchendo as solicitações mais comuns dos desenvolvedores da Web com base nos valores de atributos de classe mais comuns. Seu principal objetivo é simplificar a criação e o estilo.
Infelizmente, este parece ser um caso em que o editor de HTML5, por todo o seu bom trabalho em reunir as especificações, tem (vamos ser generosos) esquecido por que ele adicionou esses elementos ao que é essencialmente sua especificação. Talvez seja a diferença de tempo entre 2009 e 2004, quem sabe. Mas sabemos disso: os elementos de seção HTML5 não foram adicionados para preencher as "solicitações mais comuns dos desenvolvedores da Web". Como nós sabemos? Podemos apenas olhar para a lista e ver os elementos mais fundamentais adicionados, como o elemento de seção (e o artigo relacionado e os elementos de lado), que não aparecem na pesquisa de atributos de classe comum.
Embora Hickson possa ter esquecido por que esses elementos foram adicionados, ainda podemos, felizmente, ler a especificação que documenta sua finalidade.
Mas o que acontece quando você diz aos web designers e desenvolvedores que não se preocupem, esses elementos apenas substituem o que você já está fazendo, e então especificam esses elementos de uma forma que certamente não é o que os web designers e desenvolvedores estavam fazendo? Você os coloca em uma viagem só de ida para a cidade da confusão.
Este é o pior tipo de pesquisa: uma interpretação preguiçosa dos dados para justificar as decisões que já foram tomadas. Um princípio de design frequentemente repetido do HTML5 é ' pavimente as trilhas ', isto é' Quando uma prática já é difundida entre os autores, considere adotá-la em vez de proibi-la ou inventar algo novo '. E assim pareceria com esses novos elementos estruturais: seção, artigo, nav e aparte (e cabeçalho e rodapé) - certamente esses são apenas "pavimentar os caminhos da vaca"?
Essa é a impressão que muitos de nós têm, como foi o que nos disseram que são.
De fato, quase cinco anos atrás, quando recebemos um visualização de HTML5 , parecia que esses elementos poderiam simplesmente substituir os divs "não-religiosos" que estávamos acostumados a usar. O que foi div id = "header" no topo da página agora pode se tornar apenas header ; div id = "footer" agora poderia se tornar rodapé , e nosso div poderia ser apenas artigo. Simples, certo?
Infelizmente, apesar de fazermos o que nos foi dito (ou seja, apenas trocar um pelo outro), implementamos esses elementos de uma maneira que não está refletida nas especificações do HTML5. Ou seja, quando se trata de estrutura de HTML5, nós essencialmente bifurcamos a especificação. Existem atualmente dois métodos de estrutura HTML5 por aí - a interpretação da comunidade, que se reflete no artigo A List Apart de 2007 (e inúmeros outros); e a especificação HTML5 atual, que introduz uma maneira totalmente nova de estruturar uma página da Web chamada de estrutura de tópicos.
Essa é a contradição no coração da semântica estrutural do HTML. Por um lado, temos o editor nos dizendo que os novos elementos são baseados na pesquisa sobre o que já estávamos fazendo e, portanto, pretendemos apenas tornar a criação um pouco mais fácil; e, por outro lado, temos o que o editor realmente criou na especificação HTML5, que é uma nova maneira de estruturar uma página da Web de uma maneira que gera um esboço de documento usando elementos de seção .
Houve uma escolha clara a ser feita aqui. Rompa com os princípios de design do HTML5 e introduza algo novo, ou simplesmente siga as práticas reais de criação e especifique os elementos de uma forma que reflita a prática de web design. Hickson tentou fazer o primeiro e chamar o último, e agora temos uma grande bagunça em nossas mãos.
Faminto por mais? Parte dois deste artigo já está disponível e o livro de Luke "The Truth About HTML5" está disponível por tempo limitado através de nosso site irmão MightyDeals.com com um incrível desconto de 50%.
Você trabalha com elementos estruturais HTML5? Você acha que eles são úteis ou um obstáculo? Deixe-nos saber nos comentários.
Imagem / miniatura em destaque, usa imagem da estrutura via Shutterstock.