Dans HTML5, il manque quand même la balise `panier` pour aller avec `article`
. Ce début de réflexion que je partageais sur Twitter m’est venu en lisant les tables de la loi spécifications de HTML5, notamment la partie semantics. Là, j’ai eu comme une révélation : Les balises HTML et surtout HTML5 sont orientées vers les contenus littéraires (`dialog`), le monde de la presse (`article`) et les publications à caractère scientifique (`section`).
C’est normal si on considère que le web est issu du monde de la recherche universitaire mais ça l’est moins au regard des autres pratiques du web en général et du commerce en ligne en particulier. Du coup, mon côté réactionnaire a pris le dessus et je me suis mis à regarder HTML5 comme un sous-produit de XHTML réservé aux contenus dits de « qualité » vs le commerce qui ferait partie du côté « obscur » de la force.
Pour prendre le contre-pied de ce que j’écrivais dans Favoriser les sites de contenus, n’est-ce pas exclure de fait les sites d’entreprises ? je pense qu’il est peut-être temps de se pencher sur la structure sémantique des sites de vente en ligne.
Les balises qui manquent à HTML5
Et là, je ne parle pas que de e-commerce. Quelqu’un pourra-t-il m’expliquer la présence d’une balise `dialog` alors qu’il manque la balise `logo`, élément bien plus largement utilisé sur le web ? Idem pour une éventuelle balise `motto` ou `baseline` ? Je veux bien y mettre de la bonne volonté, mais HTML5 est quand même un truc bancal quand on regarde de près la structuration des contenus présents sur le web.
Et le e-commerce, ça pue ?
Et oui, à côté des blogs, des articles d’information et des sites corporate (qui partagent la même structure), le gros du web est composé de sites de vente en ligne. Quand on y regarde de plus près, les éléments composant la notice d’un article (produit) sont autrement plus complexes que ceux d’un article (billet) : on retrouve les mêmes éléments (titre, sous-titre, résumé, etc.) en plus des éléments spécifiques au commerce comme le prix (`price` ?), le nombre d’éléments en stock (`item` ?), etc. Sans compter tous les éléments qui caractérisent un produit comme la taille, la couleur, etc.
Vous vous doutez bien qu’il ne serait pas très pratique d’avoir autant de balises dites « sémantiques » pour caractériser chaque élément de personnalisation possible pour un article donné. C’est pourquoi, je propose d’inventer un mécanisme permettant de spécifier un élément sous forme ce classe CSS histoire de s’en sortir avec tous les micro-contenus… Mais attendez, on me souffle dans l’oreillette que les microformats existent déjà…
En (très) bref
HTML5 sera parfait pour structurer l’exemplaire papier de Roméo et Juliette qui se trouve dans ma bibliothèque. En ce qui concerne les contenus disponibles sur le web le travail ne fait que commencer.
On ne peut pas malheureusement créer des balises HTML pour tout ! C’est vrai que les choix qu’ils ont fait sont discutables mais c’est déjà mieux que uniquement des <div> et des <p>
Si tu veux ajouter de la semantique, n’oublie pas les microformats. Pour le commerce, il existe le microformat hProduct, utilisé, entre autres, sur Amazon et Best Buy –> http://microformats.org/wiki/hproduct
J’ai cité les microformats comme alternative (cf le dernier paragraphe avant la conclusion). Je ne dis pas que les choix effectués sont mauvais, mais simplement qu’ils sont très orientés.
Je vais me pencher sur hProduct, merci pour le lien o/
Oui, je suis assez d’accord. Le HTML5, dont j’étudiais ici les éléments de structure, me semble bancal et également incomplet, et me donne le sentiment étrange de retourner à l’université faire des dissertations…
Effectivement à la sortie de ses spécifications, la première chose que je me suis dite, c’est : « tiens il n’y a plus de place que pour l’écrit? blogs et cie ? »
quid du Ecommerce comme tu le dis, mais aussi des portfolios d’artistes visuels, audio ect… Je trouve cette spécification très web2.0-blog et pas assez ouverte aux nouveaux usage qui pourraient naitre dans les mois à venir….
@tetue — J’ai également pensé à la fac et aux dissertations en deux partie, quatre sous-parties 😉
@Le Zla — oui, le web 2.0 et la littérature 1.0 sont privilégié. Pour le reste, il existe les balises
audio,figure,img,canvas, etc. qui peuvent être utilisées dans le cadre de portfolios.Pour créer tes propres balises, il y a XBL2, dont les specifications sont terminées, reste plus que des implémentations, qui sont en cours chez Mozilla et Webkit. Associés avec ARIA, voilà de quoi combler les manques de HTML5, qui n’est pas là non plus pour prendre en charge tout les besoins de tout le monde 😉
http://www.w3.org/TR/xbl/
http://ljouanneau.com/blog/post/2009/06/26/Chantiers%3A-XBL2-et-multi-processes
http://ljouanneau.com/standards/pw2007/
Pour le ecommerce, en plus des microformats, il y a rdfa. 😉
Comme le dit Vinch, on ne peut pas tout avoir. Puis avec hProduct, c’est bien plus complet.
Mais petite question, lorsque tu parle de site de « qualité » ou du coté « obscur ». Désignes-tu le contenu ou l’architecture de la page ?
Je parlais en terme de contenu et de thématique des sites web : Google a tendance à privilégier les sites de contenus (en gros, les thèses, les articles d’information, etc.) au détriment des sites de vente en ligne.
Entre les deux, Google nous met dans l’embarras (du choix) avec les sangsues du web que sont les comparateurs de prix et autres MFA ^_^v
Quand j’ai vu la liste des nouvelles balises HTML5, je me suis étonné de ne voir que si peu de nouvelles finalement. Quand on voit le nombre d’année qu’il faut pour passer à une nouvelle version de HTML, je pense que les évolutions sont trop peu nombreuses au niveau des nouvelles balises. Peur du « trop de balises » ? Quand on voit le nombre de propriétés CSS existante, ou même le nombre de fonctions PHP, ce n’est pas une trentaine de balises HTML qui auraient été difficiles à retenir.
Je suis d’accord avec Bruno Bichet, lorsque je fais un blog avec du HTML5, pas de problème, lorsque je veux faire une structure plus e-commerce, alors rien de vraiment nouveau par rapport à HTML4.
Autant je comprends la difficulté d’implémenter des balises ayant un rôle dans le navigateur (telle que et par exemple), autant je ne comprends pas pourquoi autant se limiter au niveau des baliser uniquement sémantiques. Il y a peut-être (surement ?) une raison mais elle m’échappe.
Pour les microformats, je les considère comme un échec quand on voit le nombre de personnes qui les connaissent et surtout qui les utilisent à leur plein potentiel. Sur papier le potentiel est énorme, mais pour l’instant ils ne sont pas assez documentés, et surtout peu utilisé par les grosses entreprises du Web (d’ailleurs Google apparemment les prend en compte depuis 2009, mais je n’ai jamais entendu parler un seul marketeur qui parle des bénéfices de les utiliser pour le référencement). Je pense qu’il faut continuer à les suivre et en parler, l’avenir peut-être changera la donne (ou pas).
Bref, HTML5 c’est bien, mais ça aurait pu peut-être être mieux (probablement).
(Pour signaler un problème : lorsque j’écris la balise video et audio en HTML, au lieu de m’encoder les chevrons, ça me supprime le tag.)
Bon constat, comme je suis en retard sur html5 (trop de boulot ^^), je découvre en ce moment petit à petit la spécification etc. Il est vrai que tous les exemples de mise en pratique s’attachent souvent sur le mode blog, à croire que le Web ne serait constitué que de cela.
« ça aurait pu peut-être être mieux », tu sais, rien n’est figé au W3C, tu peux rejoindre le groupe de travail et proposer :).
Je ne suis pas d’accord avec toi Bruno. HTML, a pour but de structurer du contenu, pas des concepts. Le but premier étant une utilisabilité dans les navigateurs (user agent comme on dit dans le jargon). Une balise « panier » ne représente rien en terme de contenu, il ne justifie pas une exception au sens structurel.
Le problème avec les concepts c’est qu’il peuvent diverger (que ce soit en fonction de la culture, de la langue ou du temps). Donc, il serait impossible de s’en servir sans s’en mordre les doigts plus tard.
Tu fais l’amalgame entre sémantique du document et sémantique du contenu. HTML permet de décrire le contenu du point de vue du document, ça ne sert pas à grand chose (si ce n’est les user agents). RDFa ou les microformats permettent de décrire le contenu du point de vue de l’humain.
En ce qui concerne la balise dialog, il me semble qu’elle a été abandonnée depuis longtemps :).
Je pense que tu es assez bien placé pour remarquer qu’HTML aurait pu être beaucoup plus orienté littéraire. Mais au final, qui doit se servir de HTML ? Tout le monde ! Et surtout pas des spécialistes.
« HTML, a pour but de structurer du contenu, pas des concepts »
Peut-être que le problème vient de là : le niveau d’abstraction n’est pas assez élevé. Ce qui dénote un manque de réflexion évident de la part du What WG. A la limite personne ne leur demandait quoique se soit, et perso, j’aurais largement attendu quelques années de plus, ne serait-ce que pour avoir les balises
logoetmotto;))J’ai l’air de plaisanter, mais en fait pas tant que ça. Je pense qu’il y a eu du boulot à certains niveaux comme la persistance des données, les balises
audio,vidéo, etc. qui ne me manquaient pas du tout.Mais il ne faut pas se faire avoir : ce HTML5 est une bataille entre les géants de l’industrie ; les besoins des intégrateurs sont le cadet de leurs soucis et encore… C’est dans ce sens qu’il faut comprendre le côté bâclé sur les balises pour structurer les contenus.
Ça me conforte dans mes développements XSLT pour les sites conséquents.
@Neovov:
Sans rentrer dans la question de savoir si « panier » serait une balise utile ou pas, HTML est là pour permettre à un lecteur de rendre efficacement un contenu.
Pour un logiciel savoir ce qu’est le panier, pouvoir le faire disparaitre de l’écran et le faire revenir sur demande, savoir s’il est vide ou pas, pouvoir y accéder via un menu du navigateur, c’est utile. Du coup si, ça a du sens au niveau contenu.
Ou plutot ça a autant ou plus de sens que certaines autres balises de HTML comme « kbd », « var », « address » ou autres trucs qui finalement ne servent à personne parce que aucun logiciel ne sait quoi en faire pour l’utilisateur.
@Eric Giovannetti : Pas assez de nouvelles balises ? Moi je trouve qu’on en a déjà beaucoup plus que la version précédente. Je ne pense pas qu’on en ait eu autant de nouvelles entre HTML 3.2 et HTML 4 ! Ensuite, tu te plains qu’il manque des balises pour les sites e-commerce (par exemple) mais ensuite, tu dis que les microformats (et hProduct entre autres) ne sont pas utilisés. C’est peut-être que c’est pas si utile aux webmasters que ça en fait ? Si ça avait été vraiment utile, on en aurait sans doute plus parlé, non ? Faut arrêter de vouloir une balise HTML pour le moindre de vos besoins. Pourquoi pas une balise « tweet » tant qu’on y est ?
N’oubliez pas que vous avez vos attributs « class » et « id » toujours à disposition.
J’ai l’impression que HTML5 va faire naître une nouvelle maladie : la « non-classite » c’est-à-dire le refus absolu de vouloir utiliser l’attribut class, juste pour la beauté du geste.
Gardons le langage simple et abordable, ça sert à rien d’avoir 1000 balises pour que 80% des gens n’en utilisent que 20% (loi de Pareto).
@Vinch:
Sauf que microformats dans les faits c’est super limité, mal implémenté, lourd à utiliser … et non, il n’y a pas de class= »panier » 😉
Class et id ne sont pas là pour la même chose. Ils permettent les styles, les comportements internes à la page. Ce n’est pas du tout le même but qu’une balise. La balise elle elle est là pour le navigateur. Une balise panier le navigateur pourra présenter le panier, savoir que c’en est un, le mettre dans un menu, etc. Un class= »panier » ou un id= »panier », ben ça ne lui sert à rien.
Sinon la loi de Pareto elle ne donne rien. Avoir uniquement 100 balises n’est pas meilleure si on en utilise toujours que 20% mais qu’en plus il en manque (20% de 1000 c’est toujours mieux que 20% de 100). L’idée qu’on n’utilise pas tout ne doit pas être un frein aux idées intelligentes (encore une fois je dis ça sans prendre partie sur le fait qu’une balise panier soit intelligente ou pas, je n’ai pas assez réfléchit à la question pour le dire)
@Eric:
Dans le cas des microformats, l’attribut class est effectivement sémantique. Je ne vois pas pourquoi tu dis que les microformats sont super limités et mal implémentés. Là, je demande un peu d’argumentation 😉
Ton calcul à propos des 80/20 est un peu bizarre, par ailleurs. Pour l’instant, j’ai l’impression d’utiliser + de 75% du langage HTML. Le fait d’ajouter 900 nouvelles balises ne me fera pas garder ce pourcentage, je descendrai sans doute à 40%/30%. Le fait d’ajouter de nouvelles balises ne va pas forcer les gens à s’y mettre. Tout le monde n’est pas dingue de sémantique comme nous. Donc l’apparition d’une balise « panier » donnerait surement la trique à quelques geeks comme nous, mais le webmaster moyen continuerait sans doute à utiliser un bon vieux div id= »panier ».
Pourquoi n’a t-on pas imaginé de pouvoir étendre le HTML comme c’est le cas pour XML, ce qui pourrait donner naissance à de nouveaux sous-standards ? (par exemple le « commerceHTML »). Ca mettrait sans doute tout le monde d’accord…
@Éric : En fait, le problème n’est pas au niveau du langage, mais du navigateur plutôt, non ?
C’est pareil avec les microformats. C’est bien beau, mais on en fait quoi, comment l’utilisateur peut s’en servir ?
Je suis d’accord, si « panier » était dans HTML, mais surtout si les navigateurs savaient s’en servir et proposer une bonne interaction ce serait bien, mais à ce moment là ça revient à dire qu’il vaut revoir l’interface du navigateur tel qu’on le connait et l’adapter en fonction du contexte.
Peut-être que ça arrivera hein, Office 20xx (je sais plus combien), propose un bande d’actions qui change en fonction du contexte…
@Vinch : « Tout le monde d’accord » c’est une utopie sur Internet :).
Mozilla travaille sur XBL qui permet de créer ses propres balises il me semble. Je crois que Webkit et Microsoft sont très intéressés. Reste qu’il faut quand même définir comment le navigateur interprète les balises. Une image il faut récupérer le fichier, le mettre en cache, l’afficher, proposer d’enregistrer sur le bureau, etc.
Et au final, avec une multitude de langage, comment on ferait pour se mettre d’accord, ou pour faire des parsers, des éditeurs, des serveurs, des frameworks, des navigateurs 🙂 ?
@Neovov : Moi je pense que ça règlerait pas mal de problèmes. On ne devrait plus attendre 10 ans pour que le W3C sorte une nouvelle version de HTML qui correspond à l’époque dans laquelle on vit. On aurait un HTML de base, je trouve que HTML5 tel qu’il a été concu est un candidat parfait pour être un HTML de base. Ensuite, on pourrait proposer des extensions (comme c’est le cas du XML avec des namespaces) qui seraient approuvées par un grand comité des sages du W3C ou par d’autres instances « officielles » voire pas approuvées du tout. A la vitesse où les navigateurs modernes s’adaptent aujourd’hui (cfr. la course au test ACID3), je ne me fais pas de soucis pour l’implémentation dans les navigateurs. A priori, si les balises sont uniquement sémantiques, ça ne devrait pas être difficile du point de vue purement « affichage ». On ne parle pas de balise « video » ou « audio » ici…
Le problème est que les espaces de nom ont été mis à la poubelle avec XHTML et que ceux qui ont jeté le bébé avec l’eau du bain n’ont proposé aucune solution viable de remplacement (en fait ils ne croient tout simplement pas à ce modèle d’extensibilité donc on risque de ne rien voir venir d’intéressant).
Sinon oui, un langage html documentaire, à croiser avec un autre langage orienté application, un autre orienté commerce, puis du rdf pour les niches ou les méta … ça c’est l’avenir auquel je croyais pour le web, mais ils l’ont mis à la poubelle
Moi tout ce que je reproche à HTML5 c’est déjà de ne pas imposer le support de codec libre pour les balises audio et video (encore une fois merci Apple pour le bordel), et surtout d’être une mise à jour de HTML4. Personnellement je préfère le xHTML au HTML, entre la souplesse du HTML et les corrections faites par les navigateurs modernes (surtout firefox) tu peux coder ton site comme un porc avec des erreurs de balisages dans tous les sens et avoir un rendu correct. Quand je regarde le code source de certaines pages ça fait peur à voir, le xHTML étant moins souple il « oblige » au moins à baliser correctement sa page ce qui est la base.
Ce n’est pas parce que la majorité des balises sont inconnues par la majorité des développeurs et intégrateurs qu’on doit se limiter aux balises déjà existantes, tout comme je connais peu de développeurs qui connaissent l’ensemble des fonctions PHP, pourtant il existe des centaines de fonctions, c’est d’ailleurs comme ça qu’on arrive à reconnaitre plus facilement les experts, ce sont des bibliothèques vivantes évolutives.
Pour moi, les attributs « class » et « id » n’ont strictement aucune valeur sémantique par défaut. Je ne veux pas de nouvelles balises
pour les styler en CSS, pour ça en effet l’attribut « class » est là pour ça, je veux des nouvelles balises pour rendre plus pertinent mon contenu pour le référencement naturel, et mon site plus accessible (parce que ARIA…).
On parle souvent de « divite », mais la « paragraphite » et « listite » c’est pas franchement mieux.
Pour l’extensibilité du XML, j’espérais qu’on y parviendrait à l’époque avec XHTML 2.0, mais c’est une époque révolue, plus d’espoir de ce côté.
C’était la solution idéale car l’utilisation de balises est vraiment la manière la plus simple de mettre en place de nouvelles couches sémantiques, et surtout d’industrialiser tout ça.