Les éléments structurels de HTML - article, section, nav et de côté - sont, à première vue, les éléments les plus faciles à comprendre et à mettre en œuvre de la spécification HTML5. Cependant, ils sont en réalité certains des éléments les moins bien spécifiés, mal compris et mal implémentés de HTML5.
Créé arbitrairement ils tentent d'introduire une toute nouvelle façon de structurer les pages Web; ils violent les propres principes de conception de HTML; ils nuisent à l'accessibilité pour certains utilisateurs; et vous ne devriez pas les utiliser.
Oui, je sors des armes à feu contre cette partie spécifique de HTML5, mais ne présumez pas que je suis anti-HTML5. J'ai écrit un livre sur HTML5 , J'adore le web ouvert, j'adore les standards du Web et j'adore le fait qu'après avoir traversé une décennie de stagnation, l'innovation dans les technologies Web se déroule désormais à une vitesse fulgurante. Cela ne signifie cependant pas que nous devons accepter tout ce que nous avons reçu. Nous n'avons pas besoin de tout manger sur la plaque HTML5, même si nous trouvons des parties du plat plutôt savoureuses. Certaines pièces doivent probablement être renvoyées au chef.
La spécification HTML5, très volumineuse, comporte des aspects positifs et négatifs et nous allons réfléchir de manière critique à une partie très spécifique de la spécification: les éléments de sectionnement ou «structurels» introduits par HTML5. Mettons donc nos détectives dessus et regardons d'où viennent réellement ces nouveaux éléments, comment ils sont censés être utilisés et comment nous, les concepteurs de sites Web, les avons fondamentalement mal compris, essentiellement en élaborant les spécifications. Nous remettons en question la base même de ces éléments et supprimons quelques mythes à ce sujet en cours de route.
Jetons un coup d'œil au mythe qui a été répété à propos de ces éléments, à savoir qu'ils reposent sur des recherches sur la manière dont nous, les internautes, balisons nos documents. C'est un mythe qui se répète depuis des années dans les livres, les blogs et les discussions, et ce n'est tout simplement pas vrai. Comment puis-je savoir? J'ai demandé.
Lors de mes recherches sur l'origine de ces éléments, j'ai décidé de demander à l'éditeur de la spécification HTML5, Ian Hickson, d'où provenaient ces éléments. Il a répondu:
Moi et d'autres contributeurs de WHATWG [les avons ajoutés], [en] 2004ish, car ils étaient des éléments évidents à ajouter après avoir vu comment les auteurs utilisaient HTML4. Plus tard (fin 2005, début 2006), nous avons effectué des recherches objectives pour déterminer quelles étaient les dix premières classes HTML et il s’est avéré qu’elles correspondaient exactement aux éléments ajoutés, ce qui était pratique.
Décrivons ceci: premièrement, les membres de Hickson et du WHATWG ont ajouté ces éléments avant que des recherches soient effectuées . Vous pouvez vous plonger dans les archives des listes de diffusion (heureusement publiques) du WHATWG et découvrir des discussions précoces sur ces éléments pour vous-même. Par exemple, vous pouvez voir Hickson en discuter en novembre 2004, avec des commentaires tels que celui-là :
Oui, j'ai l'intention d'inclure des éléments tels que [éléments sémantiques] dans les applications Web. Le tableau blanc de mon bureau contient actuellement une liste d’éléments sous le titre "HTML5 BLACK LEVEL ELEMENTS", et j’essaie de déterminer comment les faire fonctionner correctement (les éléments en question sont actuellement mentionnés dans le projet, mais le projet ne gère pas du tout les en-têtes). Je n'ai pas encore regardé le balisage en ligne, mais c'est aussi sur les cartes.
C'est, semble-t-il, comment la sémantique structurelle HTML5 est apparue: un homme, un tableau blanc et des contributions d'autres membres du WHATWG. (Le groupe de travail WHATWG, ou Web Hypertext Application Technology, a été formé par des représentants de navigateurs en réponse à l’abandon du HTML par le W3C pour l’idéal utopique de XHTML 2.0).
Les éléments utilisés par des millions de documents dont nous avons discuté et discuté ont été, semble-t-il, créés arbitrairement sur un coup de tête de l’éditeur HTML5 en 2004. (Et ont été critique astucieuse et certaines prévisions tristement précises presque immédiatement.)
Tantek insiste depuis longtemps sur la recherche avant de spécifier de nouveaux formats dans le contexte des microformats. Enfin, les spécifications de WHATWG seront également conçues avec des données réelles, au lieu que nous retirions des éléments collectifs. - Ian Hickson
Cela nous amène au deuxième point. En décembre 2005, environ un an après avoir mis au point ces nouveaux éléments, Hickson (un employé de Google) a fait des recherches sur la manière dont les documents étaient créés à l'aide de la vaste base de données de documents de Google. La recherche était «une analyse d'un échantillon d'un peu plus d'un milliard de documents, extrayant des informations sur les noms de classe, les éléments, les attributs et les métadonnées associées». Les identifiants n'étaient pas inclus dans la recherche. Les résultats ont été publiés par Google en tant que Statistiques de création Web (2005) .
La partie critique de la recherche, en ce qui concerne les éléments structurels de HTML, était la découvertes de classes , qui, bien qu'utilisant un échantillon où ~ 900 millions des 1 milliard de documents n'avaient apparemment aucune classe, contenait des classes communes que je suis sûr que nous avons toutes utilisées dans nos projets: footer, menu, title, small, text , contenu, en-tête, nav, copyright, bouton, principal, etc.
Hickson fournit ensuite son tour aux données, suggérant que ces classes «cartographient très bien les éléments proposés dans HTML5» et fournit un tableau comparant les résultats de la recherche et les nouveaux éléments de HTML5: un pied de page classe est dans la recherche, un élément de pied de page est en HTML5; une classe d'en- tête est dans la recherche, un élément d'en- tête est en HTML5; les classes text , content , main , body sont dans la recherche, et err ... article en HTML5 qui, comme nous le verrons, ne correspond pas du tout; section est à ne pas trouver du tout, ce qui vaut également la peine de noter.
Pris au pied de la lettre, tout cela est assez raisonnable. J'utilise le pied de page, vous utilisez le pied de page, le pied de page est en HTML5. Quel est le problème?
Le problème est que si vous lisez le réel Spécification HTML5 , les éléments en HTML5 sont définis d'une manière qui n'a rien à voir avec la façon dont nous les utilisons traditionnellement.
D'un côté, Hickson a introduit un tout nouveau concept de structuration d'une page Web en HTML5 avec des éléments de sectionnement . D'autre part, Hickson compare ses éléments de sectionnement HTML5 à des classes utilisées dans la nature sans comprendre en quoi ces classes étaient réellement utilisées. Un exemple classique est "en-tête", que la plupart d'entre nous utiliseraient pour la zone en haut de la page, mais la spécification HTML5, vous suggère de l'utiliser pour l'en- tête de chaque commentaire sur une page . Vraiment. Ce n'est pas parce que les classes dans la recherche et les éléments dans HTML5 ont le même nom que leurs utilisations sont les mêmes.
Maintenant, si on communiquait clairement que de nouveaux éléments avaient été introduits avec un nouvel objectif, et une justification claire, cela ne serait pas si grave. Mais ce n'est pas ce qu'on nous a dit.
Ici c'est Hickson en 2009 , répondant à une question sur le but de la section, de la navigation, de l'article, de la réserve et d'autres:
Ils correspondent plus ou moins aux requêtes les plus courantes des développeurs Web en fonction des valeurs d’attribut class = "" les plus courantes. Leur objectif principal est de simplifier la création et le style.
Malheureusement, cela semble être un cas où l'éditeur HTML5, malgré son bon travail en rassemblant les spécifications, a oublié (soyons généreux) pourquoi il a ajouté ces éléments à ce qui est essentiellement sa spécification. C'est peut-être la différence de temps entre 2009 et 2004, qui sait. Mais nous le savons: les éléments de section HTML5 n'ont pas été ajoutés pour répondre aux demandes les plus courantes des développeurs Web. Comment savons nous? Nous pouvons simplement regarder la liste, et voir les éléments les plus fondamentaux ajoutés, tels que l'élément de section (et l'article associé et les éléments de côté), n'apparaissent pas dans la recherche d'attributs de classe commune.
Même si Hickson a peut-être oublié pourquoi ces éléments ont été ajoutés, nous pouvons quand même lire avec reconnaissance les spécifications qui documentent leur objectif.
Mais que se passe-t-il lorsque vous dites aux concepteurs et aux développeurs Web de ne pas s'inquiéter, ces éléments remplacent simplement ce que vous faites déjà, puis spécifient ces éléments d'une manière qui n'est certainement pas celle des concepteurs Web et des développeurs? Vous les mettez dans un voyage à sens unique dans la ville de confusion.
C'est le pire type de recherche: une interprétation paresseuse des données pour justifier les décisions déjà prises. Un principe de conception souvent répété de HTML5 est de ' paver les chemins de vache ', c’est-à-dire «Quand une pratique est déjà répandue parmi les auteurs, envisagez de l’adopter plutôt que de l’interdire ou d’inventer quelque chose de nouveau». Il semblerait donc que ces nouveaux éléments structurels: section, article, nav et side (et header et footer) ne sont que des «pavés de vaches»?
C'est l'impression que beaucoup d'entre nous ont eue, puisque c'est ce qu'on leur a dit.
En fait, il y a près de cinq ans, lorsque nous avons eu aperçu de HTML5 , il semblait que ces éléments pouvaient simplement remplacer les divs «non sémantiques» que nous avions l'habitude d'utiliser. Qu'est-ce que div id = "header" en haut de la page pourrait maintenant devenir en- tête ; div id = "footer" pourrait maintenant devenir pied de page , et notre div pourrait simplement être article. Simple, non?
Malheureusement, bien que nous fassions ce qui nous a été dit (c.-à-d. Simplement pour en échanger un pour l'autre), nous avons effectivement implémenté ces éléments d'une manière qui n'est pas reflétée dans les spécifications HTML5. Autrement dit, en ce qui concerne la structure HTML5, nous avons essentiellement créé la fourchette des spécifications. Il existe actuellement deux méthodes de structure HTML5: l'interprétation de la communauté, qui est reflétée dans l'article A List Apart 2007 (et d'innombrables autres); et la spécification actuelle de HTML5, qui introduit une toute nouvelle façon de structurer une page Web appelée mise en forme.
C'est la contradiction au cœur de la sémantique structurelle de HTML. D'un côté, nous avons l'éditeur qui nous dit que les nouveaux éléments sont basés sur la recherche de ce que nous faisions déjà, et qui ont donc pour but de faciliter la création; et d'autre part, nous avons ce que l'éditeur a réellement créé dans la spécification HTML5, qui est une nouvelle façon de structurer une page Web de manière à générer un contour de document à l' aide d' éléments de sectionnement .
Il y avait un choix clair à faire ici. Briser les principes de conception HTML5 et introduire quelque chose de nouveau, ou simplement suivre des pratiques de création réelles et spécifier des éléments d'une manière qui reflète la pratique de la conception Web. Hickson a essayé de faire le premier et l'a appelé le dernier, et nous avons maintenant un gros bordel sur nos mains.
Envie de plus? Deuxiè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.
Travaillez-vous avec des éléments structurels HTML5? Les trouvez-vous utiles ou un obstacle? Faites le nous savoir dans les commentaires.
Image / vignette en vedette, utilisations image de structure via Shutterstock.