Dentro a primeira parte desta série nós cobrimos as falhas que levam aos elementos estruturais do HTML5, nesta segunda parte veremos em detalhes as conseqüências dessas falhas.
Eu já disse várias vezes que o HTML5 introduz um novo método de estruturação de uma página da web, e você provavelmente está se perguntando o que realmente é. Está bem aí na especificação, que introduz o conceito de 'conteúdo de seccionamento ': seção de conteúdo é o conteúdo que define o escopo de cabeçalhos e rodapés. Cada elemento de conteúdo de corte tem potencialmente um cabeçalho e um esboço.
A especificação documenta sua abordagem para cabeçalhos, seções e contornos para tornar o conceito claro. Bem, claro para aqueles que têm que implementar a funcionalidade em navegadores. Para entendermos os elementos estruturais do HTML (seção, artigo, nav, aparte e seus elementos relacionados cabeçalho e rodapé) e esse conceito obscuro de 'conteúdo de seção' ou 'contorno', precisamos fazer uma pequena viagem através do histórico de HTML.
O conceito de delineamento introduzido no HTML5 pode ser rastreado até 1991 e foi incluído na especificação do XHTML 2.0, e finalmente vê a luz do dia em HTML5… apenas para ser tão mal comunicado que a ideia está praticamente morto na chegada.
Antes do HTML5, a estrutura hierárquica de uma página era determinada pelos elementos de título - nossos velhos amigos de h1 a h6. Poderíamos estruturar uma página dizendo que o título da página é h1, o cabeçalho do artigo pode ser h2 e talvez os subtítulos do artigo possam ser h3 e h4, e assim por diante.
Isso é bom para um documento simples, mas é muito difícil usar tags de cabeçalho para criar uma hierarquia lógica, ou 'esboço de documento', para uma página web complexa e moderna. Parte do problema é a falta de uma maneira de determinar onde uma seção da página é iniciada e interrompida. Por exemplo, digamos que o nosso documento mencionado anteriormente com h1 para o título da página, h2 para o título do artigo, h3 para os subtítulos, mas que também quisesse marcar o título de nossas seções da barra lateral com títulos h3.
O esboço do documento que tal estrutura criaria seria algo como isto:
My Old Blog
My Latest Blog Post
My Blog Post Sub Heading
My Blog Post Sub Heading
About Me
Archives
Social Links
Aqui, os elementos h3 são 'propriedade' do h2 acima deles, mesmo que não faça muito sentido. Naturalmente, nós os dividiríamos com algo como div para o artigo e div para a barra lateral, mas eles são ignorados pelos agentes do usuário (como leitores de tela) que determinam o contorno da página apenas pela estrutura de títulos.
Ao vincular a hierarquia de páginas diretamente ao que geralmente são níveis de cabeçalho de apresentação, estamos limitados em como podemos estruturar uma página.
Na tentativa de resolver este problema, o HTML5 introduz o conceito de 'elementos de corte', isto é, elementos especiais que dividem a página em - você adivinhou - seções, e essas seções determinam o nível de aninhamento dos cabeçalhos, e na verdade a hierarquia , ou 'contorno' da página.
Ou seja, a hierarquia da página é desacoplada dos elementos de cabeçalho e, em vez disso, esses novos elementos de corte determinam qual nível um elemento de título realmente é.
No primeiro rascunho Especificação XHTML 2.0 , seccionamento trabalhado com um elemento de seção e um elemento genérico de cabeçalho h. Quando escrevíamos HTML, não especificávamos qual nível de cabeçalho queríamos usar, simplesmente deixávamos que o navegador determinasse o nível de aninhamento de um determinado título. Poderíamos aninhar elementos de seção com 99 níveis de profundidade, e um elemento h no nível 99 seria equivalente a um elemento h99. Dessa forma, podemos estruturar nossos documentos de maneira lógica, sem nos preocupar com a maneira como podemos usar os elementos h1-h6 limitados.
(Essa ideia realmente data de 1991, a propósito: como Jeremy Keith salientou, Tim Berners-Lee discutiu a idéia de uma seção e um elemento h para estruturar uma página no final de este e-mail de outubro de 1991 .)
Hickson tentou introduzir esse mesmo conceito no HTML5, mas com um grau adicional de dificuldade: ele queria manter a compatibilidade com versões anteriores e introduzir algumas novas semânticas para "simplificar a criação" para inicializar. Portanto, em vez de apenas ter um elemento section em HTML5, também temos um elemento article, nav e aside que fazem a mesma coisa que section, mas com nomes diferentes, para serem usados de maneiras diferentes.
O que a especificação diz sobre esses elementos? Encorajo-vos a leia a especificação por si mesmo , mas aqui está um gosto:
O elemento de seção é a base do corte para criar um esboço do documento.
O elemento section representa uma seção genérica de um documento ou aplicativo. Uma seção, nesse contexto, é um agrupamento temático de conteúdo, normalmente com um cabeçalho.
Exemplos de seções seriam capítulos, as várias páginas tabuladas em uma caixa de diálogo com guias ou as seções numeradas de uma tese. A home page de um site pode ser dividida em seções para uma introdução, itens de notícias e informações de contato.
Uma nota na especificação diz que o elemento não deve ser usado para propósitos de estilo puramente - um div seria melhor lá, e compreensivelmente assim, como seções lançadas a toa para estilização criariam um esboço de documento muito quebrado.
A nota continua dizendo: "Uma regra geral é que o elemento de seção é apropriado somente se o conteúdo do elemento fosse listado explicitamente no esboço do documento" e essa é a declaração mais clara sobre o elemento de seção na especificação.
Quando entendemos o conceito de seccionamento e delineamento, a inclusão do elemento de seção faz sentido. Ele não apareceu na pesquisa de valores de classes comuns, mas apareceu em XHTML 2.0 e remonta conceitualmente a 1991.
Os outros elementos estruturais introduzidos pelo HTML5 - os que foram supostamente refletidos na pesquisa - fazem exatamente a mesma coisa que o elemento de seção, no que se refere ao esboço do documento. Eles também criam a hierarquia da página e, portanto, o contorno do documento.
Tome o elemento do artigo, por exemplo. Muitas pessoas assumem que é simplesmente por artigos como este. Mas não é nada disso. É 'artigo' no sentido de 'uma peça de roupa'. É melhor pensado como 'item' como em 'uma peça de roupa', já que sua definição é tão ampla.
Quando os elementos do artigo são aninhados, os elementos internos do artigo representam artigos que, em princípio, estão relacionados ao conteúdo do artigo externo. Por exemplo, uma entrada de blog em um site que aceita comentários enviados por usuários pode representar os comentários como elementos de artigos aninhados no elemento article da entrada do blog.
Em HTML5, os comentários dos usuários, o artigo adequado, as postagens do fórum e até mesmo os 'widgets e gadgets interativos' são todos artigos. A definição é tão ampla a ponto de ser inútil - supõe-se que a semântica dê sentido, mas usar um termo coletivo para uma variedade tão ampla de itens torna o elemento sem sentido.
Este é um exemplo onde nós bifuramos a especificação - algumas pessoas seguem a especificação corretamente e fazem de quase tudo um artigo (resumos de postagens de blog, postagens de blog, comentários, widgets, posts em fóruns, etc.), enquanto outros mantiveram apenas para o artigo principal em uma página, que é apenas uma parte de sua definição ampla. Você pode pensar que isso não importa de nenhuma maneira e, em grande medida, você estaria certo. Mas pense em todos os serviços de leitura que visam apenas analisar o conteúdo principal da página. Qual implementação da especificação eles devem seguir? Eles devem seguir o que a especificação realmente diz, ou devem seguir a implementação geral da comunidade, onde geralmente há apenas um 'artigo' canônico em uma página?
Esta é uma oportunidade perdida, e o que acontece quando a especificação falha em realmente especificar , e o editor e, para ser justo, a comunidade, falha em comunicar o que a especificação realmente diz.
Imagine se o artigo não fosse usado também para comentários. Imagine se os comentários tivessem o seu próprio elemento, por exemplo, e a adoção se generalizasse. Os criadores de navegadores poderiam adicionar uma função de 'comentários silenciosos' que poderiam facilmente ocultar (ou analisar de outra forma) comentários em páginas da web. Mas Hickson recusou especificamente um pedido para um elemento de comentário . Em HTML5, são artigos até o final.
Além disso, há outro elemento que não aparece em nenhum lugar na pesquisa de nome de classe de Hickson e obtém uma definição muito peculiar para inicializar:
O elemento aside representa uma seção de uma página que consiste em conteúdo tangencialmente relacionado ao conteúdo em torno do elemento aside e que pode ser considerado separado desse conteúdo. Essas seções são frequentemente representadas como barras laterais na tipografia impressa.
O elemento pode ser usado para efeitos tipográficos, como cotações de tração ou barras laterais, para publicidade, para grupos de elementos de navegação e para outro conteúdo considerado separado do conteúdo principal da página.
Quem sabe o porquê deve cobrir tanto as citações de tração, barras laterais, publicidade e grupos de elementos de navegação, mas também cria novas seções no esquema do documento. Isso significa que aspas recebem seu próprio ponto no contorno do documento, o que parece, digamos, "estranho". Mais uma vez, seu uso aleatório por web designers bem-intencionados criou e criará muitos contornos de documentos quebrados.
O elemento nav parece o mais auto-explicativo dos elementos de corte, e felizmente a definição não foi esticada além de quebrar.
O elemento nav representa uma seção de uma página que se vincula a outras páginas ou a partes da página: uma seção com links de navegação.
O que é bom, e poderia ter benefícios teóricos de acessibilidade (um agente do usuário poderia pular, ou pular para, os links de navegação - eles não, mas poderiam).
O problema é que, no espírito da "simplificação da criação" e da substituição do div pelo elemento nav, explodimos o estilo de navegação para outro subconjunto de usuários. Usuários do IE6-8 com JavaScript desativado (Pesquisa do Yahoo sugere 1-2% de todos os usuários têm o JavaScript desativado ) são vítimas deste problema. Com o JavaScript desativado, o shim HTML5 baseado em JavaScript que ajuda o IE6-8 a entender elementos HTML5 não funciona, portanto, o navegador não estiliza elementos HTML5. Isso pode afetar apenas um pequeno número de usuários, mas por que afetá-los?
Os elementos de cabeçalho e rodapé são um caso clássico de usar termos comuns e dar a eles usos muito diferentes.
A especificação declara que nenhum desses elementos cria novas seções no esboço do documento, apesar do fato de que eles são frequentemente descritos como estando no nível da seção, nav, article e aside. Na verdade, eles não fazem nada. Eles são incluídos apenas para demarcar áreas de uma seção específica no esboço do documento.
Aqui está o que a especificação diz sobre o cabeçalho: o elemento de cabeçalho representa um grupo de auxílios introdutórios ou de navegação.
Nota: Um elemento de cabeçalho deve conter geralmente o cabeçalho da seção (um elemento h1 – h6 ou um elemento hgroup), mas isso não é necessário. O elemento de cabeçalho também pode ser usado para agrupar o índice de uma seção, um formulário de pesquisa ou qualquer logotipo relevante.
e rodapé: o elemento de rodapé representa um rodapé para seu conteúdo de corte de ancestral mais próximo ou elemento de raiz de seção. Um rodapé normalmente contém informações sobre sua seção, como quem a escreveu, links para documentos relacionados, dados de direitos autorais e afins.
Em HTML5, o elemento body é, na verdade, o elemento da seção raiz, portanto, um cabeçalho e um rodapé gerais têm a intenção de descrever a seção do corpo raiz. Qualquer seção pode ter um cabeçalho e / ou um rodapé - eles não são destinados apenas a cabeçalhos e rodapés gerais, como podemos presumir. Comentários individuais podem ter um cabeçalho e rodapé, por exemplo. Na verdade, como mencionamos anteriormente, a especificação realmente fornece um exemplo de rodapé sendo usado em um comentário acima do conteúdo real do comentário. É isso mesmo, em comentários em HTML5 há artigos, e eles podem ter um rodapé para um cabeçalho, e isso está na especificação real. Você queria um elemento de rodapé para o cabeçalho dos seus comentários? Não? Bem, você tem um.
Novamente, é aqui que o HTML5 usa termos comuns e os usa de maneiras que são irreconhecíveis para o autor da Web comum.
Mas há algo que não vimos na implementação do HTML de seccionamento. Você viu isso? Nós temos os elementos de seção, mas não temos um elemento h genérico. Não se preocupe, a solução é na especificação :
As seções podem conter títulos de qualquer classificação, mas os autores são fortemente encorajados a usar apenas elementos h1 ou a usar elementos da classificação apropriada para o nível de aninhamento da seção.
HTML5 quer ser retrocompatível, então o WHATWG decidiu não introduzir um elemento h (apesar de introduzir um monte de novos elementos de corte), e ao invés disso quer redirecionar o elemento h1 para ser o elemento h genérico. Use h1 em todos os lugares, e deixe o algoritmo HTML5 delinear determinar seu verdadeiro nível ... ou assim a teoria vai.
Esta é uma ideia terrível por várias razões, sendo as duas principais a acessibilidade e o estilo.
Usar h1 em todos os lugares é muito ruim para acessibilidade. Usuários cegos dependem muito da estrutura de títulos de um site. É importante que todos nós nos lembremos de como a estrutura de cabeçalho é crucial para fins de acessibilidade. Por exemplo, um dezembro Pesquisa de 2008 com mais de 1000 usuários de leitores de tela realizado pela WebAIM descobriu que 76% dos usuários cegos e com deficiência visual 'sempre ou frequentemente' navegavam por títulos quando estavam disponíveis. E uma pesquisa de maio de 2012 descobriu que 82,1% dos níveis de títulos eram "muito úteis" ou "um pouco úteis" ao navegar em uma página da web. (Isso é bom, pesquisa prática, então tome nota.)
Ter h1s em todos os lugares dificultará a navegação em sites para usuários cegos. Em teoria, os leitores de tela usariam o algoritmo de delineamento HTML e navegariam usando o esboço do documento, mas dada a forma como os autores foram instruídos a implementar elementos de corte, o contorno é uma bagunça e tentar navegar pelos contornos de documentos que não foram considerados. ser ainda pior para usuários cegos.
A especificação HTML5 oferece uma saída: continue usando os níveis h1-h6 apropriados para manter a compatibilidade com versões anteriores. Mas agora estamos mantendo dois contornos de documento no documento único e, considerando os problemas que os autores tiveram, mesmo considerando o esboço do documento, em primeiro lugar, a probabilidade de alguém manter tanto um esboço lógico h1-h6, quanto um lógico, propriamente dito. O contorno HTML5 de seção parece remoto, na melhor das hipóteses.
Mas fica pior. Vamos dizer que queremos executar com um esboço HTML5 puro, e usamos h1s em todos os lugares. Lembre-se, na especificação HTML5, h1 é apenas um elemento h genérico; Seu nível real é determinado pela profundidade de seus elementos de seção.
Então, como nós estilizamos isso? Bem, poderíamos adicionar nomes de classes a todos os nossos elementos h1 para que possamos selecioná-los, mas isso é contrário ao objetivo declarado de HTML5 de simplificar a criação; e também podemos nos ater a h1-h6 (todos os quais são tratados como elementos h genéricos em um esquema HTML5).
Poderíamos tentar modelá-los através da cascata, mas isso rapidamente se torna absurdo, como Nicole Sullivan apontou . Na verdade, "absurdo" só começa a descrevê-lo. Quando você considera as possíveis combinações de seção, artigo, nav e de lado, e deseja criar um estilo genérico para um título que tenha, digamos, cinco níveis de profundidade (ou seja, o equivalente a h5), você teria que escrever estilos para todos combinações possíveis, o que absolutamente ridiculo . Aqui está o estilo genérico para um elemento h3:
article aside nav h1, article aside section h1,article nav aside h1, article nav section h1,article section aside h1, article section nav h1, article section section h1,aside article nav h1, aside article section h1,aside nav article h1, aside nav section h1,aside section article h1, aside section nav h1, aside section section h1,nav article aside h1, nav article section h1,nav aside article h1, nav aside section h1,nav section article h1, nav section aside h1, nav section section h1,section article aside h1, section article nav h1, section article section h1,section aside article h1, section aside nav h1, section aside section h1,section nav article h1, section nav aside h1, section nav section h1,section section article h1, section section aside h1, section section nav h1, section section section h1 {font-size: 1.00em;}No entanto, é isso que os elementos estruturais do HTML nos dão. Que bagunça.
Faminto por mais? Parte três deste artigo já está disponível e o livro de Luke "The Truth About HTML5" está disponível por tempo limitado através do nosso site irmão MightyDeals.com com um incrível desconto de 50%.
Você usa elementos de artigo várias vezes em um documento? As seções são úteis ou devemos ficar com as divs? Deixe-nos saber seus pensamentos nos comentários.
Imagem / miniatura em destaque, usa imagem da estrutura via Shutterstock.