Dans la première partie de cette série Nous avons couvert les défaillances qui ont conduit aux éléments structurels de HTML5. Dans cette deuxième partie, nous examinerons en détail les conséquences de ces défaillances.
J'ai dit à plusieurs reprises que HTML5 introduit une nouvelle méthode de structuration d'une page Web, et vous vous demandez probablement ce que c'est réellement. Il est juste là dans la spécification, qui introduit le concept de «contenu de sectionnement» ': la section contenu est un contenu qui définit la portée des titres et des pieds de page. Chaque élément de contenu de sectionnement a potentiellement un en-tête et un contour.
La spécification documente son approche de les titres, les sections et les contours pour rendre le concept clair. Eh bien, clair pour ceux qui doivent implémenter la fonctionnalité dans les navigateurs. Pour que nous comprenions les éléments structurels de HTML (section, article, nav, side et leurs éléments et en-tête) et ce concept obscur de «contenu de section» ou de «contour», nous devons faire un petit tour dans l'histoire de HTML.
Le concept de présentation présenté dans HTML5 peut être retracé jusqu'en 1991 et a été inclus dans la spécification XHTML 2.0 sans issue, pour finalement voir le jour en HTML5 ... pour être si mal communiqué que l'idée est à peu près mort à l'arrivée.
Avant HTML5, la structure hiérarchique d'une page était déterminée par les éléments de titre - nos anciens amis h1 à h6. Nous pourrions structurer une page en disant que le titre de la page est h1, l'en-tête de l'article peut être h2 et peut-être que les sous-titres de l'article sont h3 et h4, etc.
Cela convient parfaitement à un document simple, mais il est très difficile d’utiliser des balises d’en-tête pour créer une hiérarchie logique ou une «esquisse de document» pour une page Web complexe et moderne. Le problème tient en partie à l’absence de moyen de déterminer où une section de page commence et s’arrête. Par exemple, disons que nous avions notre document mentionné précédemment avec h1 pour le titre de la page, h2 pour le titre de l'article, h3 pour les sous-titres, mais que nous voulions également marquer le titre de nos sections de barre latérale avec h3.
Le document que cette structure créerait ressemblerait à ceci:
My Old Blog
My Latest Blog Post
My Blog Post Sub Heading
My Blog Post Sub Heading
About Me
Archives
Social Links
Ici, les éléments h3 sont «possédés» par le h2 au-dessus d'eux, même si cela n'a pas beaucoup de sens. Bien sûr, nous les séparerons avec quelque chose comme div pour l'article et div pour la barre latérale, mais ceux-ci sont ignorés par les agents utilisateurs (tels que les lecteurs d'écran) qui déterminent le contour de la page uniquement.
En liant directement la hiérarchie des pages à des niveaux de présentation souvent présentés, nous sommes limités dans la manière de structurer une page.
Pour tenter de résoudre ce problème, HTML5 introduit le concept de «sectioning elements», c'est-à-dire des éléments spéciaux qui divisent la page en - vous l'avez deviné - des sections, et ces sections déterminent le niveau d'imbrication des en-têtes et de la hiérarchie , ou 'contour' de la page.
C'est-à-dire que la hiérarchie de la page est découplée des éléments d'en-tête et que ces nouveaux éléments de sectionnement déterminent plutôt le niveau réel d'un élément d'en-tête.
Dans le premier projet Spécification XHTML 2.0 , sectioning a travaillé avec un élément de section et un élément générique header h. En écrivant HTML, nous ne spécifions pas quel niveau de titre nous voulions utiliser, nous laisserions simplement le navigateur déterminer le niveau d'imbrication pour un titre donné. Nous pourrions imbriquer des éléments de section de 99 niveaux de profondeur et un élément h au 99ème niveau serait équivalent à un élément h99. De cette façon, nous pouvons structurer nos documents de manière logique, sans nous soucier de la façon dont nous pouvons utiliser les éléments h1-h6 limités.
(Cette idée remonte vraiment à 1991, soit dit en passant: comme Jeremy Keith a souligné, Tim Berners-Lee a évoqué l'idée d'un élément de section et h pour structurer une page à la fin de cet email d'octobre 1991 .)
Hickson a tenté d'introduire ce même concept dans HTML5, mais avec un degré de difficulté supplémentaire: il voulait maintenir la compatibilité ascendante et introduire de nouvelles sémantiques pour «simplifier la création» au démarrage. Par conséquent, au lieu d'avoir simplement un élément de section en HTML5, nous avons également un élément article, nav et side qui font tous la même chose que la section, mais avec des noms différents, pour être utilisés de différentes manières.
Que dit la spécification sur ces éléments? Je vous encourage à lisez les spécifications par vous-même , mais voici un goût:
L'élément de section est la base de la section pour créer un contour de document.
L'élément section représente une section générique d'un document ou d'une application. Une section, dans ce contexte, est un regroupement thématique de contenu, généralement avec un en-tête.
Des exemples de sections seraient les chapitres, les différentes pages à onglets dans une boîte de dialogue à onglets ou les sections numérotées d'une thèse. La page d'accueil d'un site Web peut être divisée en sections pour une introduction, des nouvelles et des informations de contact.
Une note dans la spécification indique que l'élément ne doit pas être utilisé à des fins purement stylistiques - une div serait mieux là, et cela se comprend, car les sections jetées dans le style créeraient un contour de document très cassé.
La note continue en disant: «Une règle générale est que l'élément de section est approprié uniquement si le contenu de l'élément est répertorié explicitement dans le contour du document» et que c'est la déclaration la plus claire concernant l'élément de section dans la spécification.
Lorsque nous comprenons le concept de section et de contour, l'inclusion de l'élément de section a du sens. Il n'apparaissait pas dans la recherche sur les valeurs de classe communes, mais il apparaissait dans XHTML 2.0 et date de 1991.
Les autres éléments structurels introduits par HTML5 - ceux qui étaient censés se refléter dans la recherche - font exactement la même chose que l'élément de section, en ce qui concerne la structure du document. Ils créent également la hiérarchie de la page, et donc le contour du document.
Prenez l'élément article par exemple. Beaucoup de gens supposent que c'est simplement pour des articles comme celui-ci. Mais ce n'est pas ça du tout. C'est «article» dans le sens de «un vêtement». Il vaut mieux le considérer comme un «objet» comme dans un «vêtement», car sa définition est aussi large.
Lorsque les éléments de l'article sont imbriqués, les éléments de l'article interne représentent des articles qui sont en principe liés au contenu de l'article externe. Par exemple, une entrée de blog sur un site qui accepte les commentaires soumis par l'utilisateur peut représenter les commentaires en tant qu'éléments d'article imbriqués dans l'élément article de l'entrée de blog.
Dans HTML5, les commentaires des utilisateurs, l'article proprement dit, les publications sur le forum et même les «widgets et gadgets interactifs» sont tous des articles. La définition est si large qu'elle est inutile - la sémantique est censée donner un sens, mais l'utilisation d'un terme collectif pour une si grande variété d'éléments rend l'élément insignifiant.
Voici un exemple où nous avons créé la fourchette des spécifications - quelques personnes suivent correctement les spécifications et font presque tout un article (résumés d'articles de blog, messages de blog, commentaires, widgets, messages sur les forums, etc.), alors que d'autres ne le conservent que pour l'article principal sur une page, qui n'est qu'une partie de sa définition large. Vous pensez peut-être que cela n'a aucune importance, et dans une large mesure, vous auriez raison. Mais pensez à tous les services de lecture qui visent à analyser le contenu principal de la page. Quelle implémentation de la spécification devrait-elle suivre? Devraient-ils suivre ce que la spécification dit réellement, ou devraient-ils suivre la mise en œuvre générale de la communauté où il n'y a généralement qu'un seul «article» canonique sur une page?
C'est une opportunité manquée, et ce qui se passe lorsque la spécification ne parvient pas à spécifier , et que l'éditeur et, pour être juste, la communauté, ne parviennent pas à communiquer ce que la spécification dit réellement.
Imaginez si l'article n'était pas également utilisé pour les commentaires. Imaginez, par exemple, que les commentaires aient leur propre élément et que l’adoption se généralise. Les fabricants de navigateurs pourraient ajouter une fonction de «commentaire muet» qui pourrait facilement masquer (ou analyser autrement) les commentaires sur les pages Web. Mais Hickson a spécifiquement refusé une demande pour un élément de commentaire . En HTML5, ce sont des articles tout en bas.
Aside est un autre élément qui n'apparaît nulle part dans la recherche de noms de classes de Hickson, et qui donne une définition très particulière au démarrage:
L'élément side représente une section d'une page constituée d'un contenu lié tangentiellement au contenu de l'élément side et pouvant être considéré comme distinct de ce contenu. Ces sections sont souvent représentées sous forme de barres latérales dans la typographie imprimée.
L'élément peut être utilisé pour des effets typographiques tels que des guillemets ou des barres latérales, pour la publicité, pour des groupes d'éléments de navigation et pour d'autres contenus considérés comme distincts du contenu principal de la page.
Qui sait pourquoi la mise à part devrait couvrir à la fois les guillemets, les barres latérales, la publicité et les groupes d'éléments de navigation, mais elle crée également de nouvelles sections dans la structure du document. Cela signifie que les guillemets ont leur propre point dans le document, ce qui semble, disons, "impair". Encore une fois, son utilisation aléatoire par des concepteurs Web bien intentionnés a créé de nombreux contours de documents.
L'élément nav semble le plus explicite des éléments de sectionnement et, heureusement, la définition n'a pas été étendue au-delà de la rupture.
L'élément nav représente une section d'une page qui renvoie à d'autres pages ou à des parties de la page: une section avec des liens de navigation.
Ce qui est bien, et pourrait avoir des avantages théoriques sur l'accessibilité (un agent utilisateur pourrait ignorer ou passer directement aux liens de navigation, ce qui n'est pas le cas, mais ils pourraient le faire).
Le problème est que dans un esprit de «simplification de la création» et de remplacement de div par l’élément nav, le style de navigation d’un autre sous-ensemble d’utilisateurs est supprimé. Utilisateurs d' IE6-8 avec JavaScript désactivé (La recherche de Yahoo suggère 1-2% de tous les utilisateurs ont désactivé JavaScript ) sont victimes de ce problème. Avec JavaScript désactivé, le calque HTML5 basé sur JavaScript qui aide IE6-8 à comprendre les éléments HTML5 ne fonctionne pas, de sorte que le navigateur ne personnalise pas les éléments HTML5. Cela ne peut affecter qu'un petit nombre d'utilisateurs, mais pourquoi les affecter?
Les éléments d'en-tête et de pied de page constituent un cas classique de prise de termes communs et de leur utilisation très différente.
La spécification précise qu’aucun de ces éléments ne crée de nouvelles sections dans l’esquisse du document, en dépit du fait qu’elles sont souvent représentées comme étant à égalité avec la section, la navigation, l’article et l’autre. En fait, ils ne font rien du tout. Ils sont juste inclus pour délimiter les zones d'une section spécifique dans la structure du document.
Voici ce que dit la spécification à propos de l’en-tête: l’élément d’en-tête représente un groupe d’aides d’introduction ou de navigation.
Remarque: Un élément d'en-tête est généralement destiné à contenir l'en-tête de la section (un élément h1-h6 ou un élément hgroup), mais ce n'est pas obligatoire. L'élément d'en-tête peut également être utilisé pour envelopper la table des matières d'une section, un formulaire de recherche ou tout logo pertinent.
et pied de page: l'élément de pied de page représente un pied de page pour son contenu de section d'ancêtre ou élément de sectionnement le plus proche. Un pied de page contient généralement des informations sur sa section, par exemple: qui l'a écrit, les liens vers les documents associés, les données de copyright, etc.
En HTML5, l'élément body est en fait l'élément de la section racine, donc un en-tête et un pied de page généraux sont destinés à décrire la section du corps racine. N'importe quelle section peut avoir un en-tête et / ou un pied de page, ils ne sont pas destinés uniquement aux en-têtes et aux pieds de page généraux, comme nous l'avons peut-être supposé. Les commentaires individuels peuvent avoir chacun un en-tête et un pied de page, par exemple. En fait, comme nous l’avons déjà mentionné, la spécification donne en fait un exemple de pied de page utilisé dans un commentaire au-dessus du contenu du commentaire. C'est vrai, dans HTML5 les commentaires sont des articles, et ils peuvent avoir un pied de page pour un en-tête, et c'est dans la spécification réelle. Voulez-vous un élément de bas de page pour l’en-tête de vos commentaires? Non? Eh bien, vous en avez un.
Là encore, HTML5 prend des termes communs et les utilise de manière non reconnaissable pour l'auteur Web commun.
Mais il y a quelque chose que nous n'avons pas examiné dans l'implémentation de la section HTML. Vous l'avez repéré? Nous avons les éléments de section, mais nous n'avons pas d'élément h générique. Ne vous inquiétez pas, la solution est dans les spécifications :
Les sections peuvent contenir des en-têtes de n'importe quel rang, mais les auteurs sont fortement encouragés à utiliser uniquement des éléments h1 ou à utiliser des éléments du rang approprié pour le niveau d'imbrication de la section.
HTML5 veut être rétrocompatible, le WHATWG a donc décidé de ne pas introduire d'élément h (malgré l'introduction de nombreux nouveaux éléments de sectionnement), mais de réutiliser l'élément h1 pour qu'il devienne l'élément générique h. Utilisez h1 partout et laissez l'algorithme de mise en page HTML5 déterminer son vrai niveau ... ou alors la théorie va.
C'est une idée terrible pour plusieurs raisons, les deux principales étant l'accessibilité et le style.
Utiliser h1 partout est très mauvais pour l'accessibilité. Les utilisateurs aveugles comptent beaucoup sur la structure des en-têtes d'un site. Il est important de nous rappeler à quel point la structure de la rubrique est cruciale pour l’accessibilité. Par exemple, un décembre Enquête 2008 auprès de plus de 1000 utilisateurs de lecteurs d'écran WebAIM a montré que 76% des utilisateurs aveugles ou malvoyants naviguaient «toujours ou souvent» par rubriques lorsqu'ils étaient disponibles. Et une enquête de mai 2012 a révélé que 82,1% des niveaux de titre étaient «très utiles» ou «assez utiles» pour naviguer sur une page Web. (Ceci est une bonne recherche pratique, alors prenez note.)
Avoir des h1 partout rendra les sites plus difficiles à naviguer pour les utilisateurs aveugles. En théorie, les lecteurs d’écran utiliseraient plutôt l’algorithme de description de HTML et navigueraient selon les grandes lignes du document, mais compte tenu de la manière dont les auteurs devaient implémenter des éléments de section, les contours ne sont pas pensés. être encore pire pour les utilisateurs aveugles.
Les spécifications HTML5 offrent un moyen de sortir: continuez à utiliser les niveaux h1-h6 appropriés pour maintenir la compatibilité ascendante. Mais maintenant, nous conservons deux plans de document dans le document et, compte tenu des problèmes rencontrés par les auteurs, même en tenant compte de l’esquisse du document, il est probable que quiconque maintienne un plan logique h1-h6 Le contour HTML5 à sections multiples semble, au mieux, distant.
Mais ça empire. Disons que nous voulons exécuter avec un contour HTML5 pur, et nous utilisons h1s partout. Rappelez-vous, dans la spécification HTML5, le h1 est juste un élément h générique; son niveau réel est déterminé par la profondeur de son imbrication dans les éléments de sectionnement.
Alors, comment pouvons-nous le coiffer? Eh bien, nous pourrions ajouter des noms de classe à tous nos éléments h1 pour pouvoir les choisir, mais cela est contraire à l’objectif HTML5 de simplifier la création; et nous pouvons aussi nous en tenir à h1-h6 (qui sont tous traités comme des éléments h génériques dans un contour HTML5).
Nous pourrions essayer de les coiffer à travers la cascade, mais cela devient vite absurde, car Nicole Sullivan a souligné . En fait, «absurde» commence seulement à le décrire. Lorsque vous considérez les combinaisons possibles de section, article, nav et side, et que vous voulez créer un style générique pour un titre qui, par exemple, cinq niveaux de profondeur (l'équivalent de h5), vous devez écrire des styles pour tous combinaisons possibles, qui obtient absolument ridicule . Voici le style générique pour un élément 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;}C'est pourtant ce que les éléments structurels de HTML nous donnent. Quel bordel.
Envie de plus? Troisième partie de cet article est maintenant disponible et le livre de Luke "The Truth About HTML5" est disponible pour un temps limité via notre site partenaire MightyDeals.com à un incroyable 50% de réduction.
Utilisez-vous des éléments d'article à plusieurs reprises dans un document? Les sections sont-elles utiles ou devons-nous nous en tenir aux divs? Faites-nous savoir vos pensées dans les commentaires.
Image / vignette en vedette, utilisations image de structure via Shutterstock.