Quelles nou­veau­tés propose HTML 5.1 ?

Sans HTML (« Hypertext Markup Language » ou langage de balisage d’hy­per­texte en français), Internet ne serait pas ce qu’il est aujourd’hui : ce langage de marquage structure les textes, images ou liens et constitue la base du World Wide Web. Le Web a toutefois bien changé au fil du temps. L’aspect mul­ti­mé­dia est devenu un facteur important pour les Web­de­sig­ners. Les contenus audio et vidéo ainsi que l’affichage sur mobile gagnent sans cesse en im­por­tance. Pour répondre aux diverses attentes des Web­de­sig­ners et uti­li­sa­teurs, le langage de balisage HTML a été développé par le Web Con­sor­tium (W3C) et le Web Hypertext Ap­pli­ca­tion Tech­no­logy Working Group (WHATWG) après plusieurs années de stag­na­tion. Un nouveau HTML est dis­po­nible depuis l’automne 2014, HTML5, que nous avons présenté dans notre guide digital IONOS. Il permet d’intégrer de nombreux contenus plus fa­ci­le­ment. Nombre de plugins et autres al­ter­na­tives sont ainsi devenus obsolètes. La petite mise à jour HTML 5.1 est aujourd’hui dis­po­nible. Mais comment fonc­tionne la procédure jusqu’à ce qu’un nouvel HTML soit publié ? Et quelles sont les prin­ci­pales nou­veau­tés de la mise à jour actuelle ? Quelles fonc­tion­na­li­tés ne seront pro­ba­ble­ment pas ap­pli­cables dans sa nouvelle version ? Et que cela signifie-t-il pour les ex­ploi­tants de sites Web ?

Il avait fallu quinze années pour qu’une nouvelle version d’HTML, 4.01, ap­pa­raisse au grand jour. Cette fois-ci, la mise à jour était bien plus rapide : près de deux ans après HTML5, l’adap­ta­tion HTML 5.1 est apparue. Cette ac­cé­lé­ra­tion des évo­lu­tions est logique au regard des chan­ge­ments massifs et rapides du World Wide Web ac­tuel­le­ment. De premières ébauches ont été préparées par groupes de travail et les ca­rac­té­ris­tiques HTML ont été sé­lec­tion­nées parmi une liste de pro­po­si­tions. La fai­sa­bi­lité des dif­fé­rents éléments a été étudiée dans le cadre d’une vaste phase de test. Une fois cette phase de test achevée vient la pu­bli­ca­tion of­fi­cielle des re­com­man­da­tions de standards. Dans le cas de HTML 5.1, ce processus s’est produit dans un dialogue avec la com­mu­nauté : c’est ainsi que le W3C a publié ce nouveau HTML sur GitHub. La com­mu­nauté avait alors plus que jamais la pos­si­bi­lité de faire avancer de manière intensive le nouveau standard du Web ainsi que de donner des retours rapides et faciles. GitHub est un service de gestion des versions de projets logiciels. Ainsi la con­tri­bu­tion de nombreux dé­ve­lop­peurs peut être fusionnée au­to­ma­ti­que­ment avec le logiciel librement ac­ces­sible, y compris dans le cas de HTML 5.1.

Une nouveauté avec HTML 5.1 est qu’il est com­pa­tible avec la plupart des na­vi­ga­teurs Web courants. Au centre des in­no­va­tions se trouve l’adap­ta­tion du contenu selon le Res­pon­sive Web design. Le problème jusqu’à présent était prin­ci­pa­le­ment celui d’un mauvais affichage des contenus avec des ré­so­lu­tions variables. Dans ce but, HTML 5 devait déjà proposer l’élément <picture> comme standard mais il n’en était rien pour des raisons de temps. Les dé­ve­lop­peurs Web uti­li­saient toutefois l’élément sans que cela ne soit publié of­fi­ciel­le­ment. Tous les na­vi­ga­teurs courants sont entre-temps devenus com­pa­tibles avec l’élément <picture> : sa stan­dar­di­sa­tion avec le nouveau HTML l’a rendu officiel.

L’élément <picture> est un container : des fichiers image peuvent être intégrés via dif­fé­rents éléments source. Grâce à cela, seules les sources d’images adaptées à la ré­so­lu­tion et la taille de l’écran utilisé sont chargées, ce qui économise un temps de trans­mis­sion précieux et avantage la con­cep­tion mobile d’un site Internet. Pour éco­no­mi­ser de la bande passante, un contenu al­ter­na­tif peut être livré sur les écrans à haute ré­so­lu­tion. Cependant, cela nécessite l’attribut <srcset>, introduit avec HTML 5.1 : il place les images de dif­fé­rentes tailles en relation.

L’exemple suivant montre comment intégrer l’élément Fallback avec <img> :

De nouveaux types d’éléments <input> ont déjà été in­tro­duits avec HTML5. Parmi ces derniers, « email », « url » ou « date », per­met­tant d’entrer des adresses email, URL, ou encore la date. Le type de champ de saisie avec <input> est toujours défini avec des attributs « type ». Avec type = « month » et type = « week », vous pouvez, en dehors du jour et de l’heure, sé­lec­tion­ner le mois et la semaine du ca­len­drier. La fonction est également déjà prise en charge par la plupart des na­vi­ga­teurs. Ainsi, sa nor­ma­li­sa­tion peut être con­si­dé­rée comme une con­sé­quence logique avec HTML 5.1.

Une nouvelle fonction HTML doit être re­com­man­dée par au moins deux na­vi­ga­teurs in­dé­pen­dants via le W3C pendant la phase de test. Elle est ca­rac­té­ri­sée par « at risk » (« à risque ») si elle ne présente pas les di­men­sions né­ces­saires pour la nor­ma­li­sa­tion avec les na­vi­ga­teurs ou dé­ve­lop­peurs.

Moins répandu que l’élément <picture>, la balise <dialog> est ac­tuel­le­ment, dans son état actuel, uni­que­ment prise en charge sur les na­vi­ga­teurs Chrome et Opera. Des rapports ont été par con­sé­quent reçus peu avant HTML 5.1 : certains articles évo­quaient une stan­dar­di­sa­tion, mais le site officiel du W3C indiquait cependant que l’élément <dialog> était supprimé. Avec ce dernier, l’in­té­gra­tion de fenêtres pop-up se fait plus fa­ci­le­ment. Un code Ja­vaS­cript est en temps normal né­ces­saire pour cela. Les dif­fi­cul­tés se trou­vaient au­pa­ra­vant prin­ci­pa­le­ment dans l’ouverture et la fermeture. Les na­vi­ga­teurs Web qui ne sont pas encore com­pa­tibles avec <dialog> peuvent certes afficher la fenêtre, mais pas la fermer. Pra­ti­que­ment tout contenu peut être mis en œuvre au sein de l’élément <dialog> : textes purs ou images.

En dehors de l’élément <dialog>, <keygen> et <menu> sont aussi sur la liste des cibles à risque pour le nouveau HTML. Ces deux derniers, cependant, ont été conservés selon les in­di­ca­tions du W3C. Ils com­pren­nent <menuitem> et l’attribut « con­text­menu ». Avec les éléments et attributs, vous pouvez créer des barres d’outils et des menus con­tex­tuels tels que nous les con­nais­sons sur les ap­pli­ca­tions de bureau. Via l’élément <menu>, vous pouvez modifier le type de barre d’outils. 

Une destinée également in­cer­taine est celle de l’élément <keygen>. Le gé­né­ra­teur de paires de clés cryp­to­gra­phiques a ini­tia­le­ment été développé par Mozilla. Microsoft n’avait pas d’intérêt pour une im­plé­men­ta­tion et Google a même demandé un retrait de la norme en juillet 2015. La stig­ma­ti­sa­tion de l’Alt-risk n’était ainsi pas sur­pre­nante. La re­com­man­da­tion proposée par W3C pour HTML 5.1 de septembre 2016 gardait déjà l’élément. Cependant, ce dernier est affiché comme « en cours de sup­pres­sion » : son uti­li­sa­tion n’est pas re­com­man­dée.

Les ex­ploi­tants de sites Web peuvent fa­ci­le­ment utiliser les éléments re­com­man­dés et les attributs du nouveau HTML. Comme décrit pré­cé­dem­ment, nombreux sont ceux à déjà utiliser ces pratiques. Il convient de regarder de plus près la liste à risque et à sup­pres­sions, en plus de la norme of­fi­cielle. Si vous avez utilisé des éléments men­tion­nés comme à risque par le passé, vous devriez mettre en œuvre dif­fé­rem­ment votre projet. Une forte com­pa­ti­bi­lité avec autant de na­vi­ga­teurs et de terminaux que possible devrait être le but de tout ex­ploi­tant de site Internet, aujourd’hui plus que jamais.

Il s’avèrerait judicieux pour les Web­mas­ters à l’avenir de jeter un coup d’œil à la page of­fi­cielle du W3C. Après l’achè­ve­ment d’HTML 5.1, on parle déjà de la version suivante, HTML 5.2. Un premier projet des chan­ge­ments né­ces­saires est déjà dis­po­nible. Ainsi, le rythme des mises à jour HTML semble s’accélérer de manière sig­ni­fi­ca­tive. Cela signifie pour les ex­ploi­tants de sites Web qu’ils pourront réagir plus ra­pi­de­ment aux bugs et s’adapter à l’évolution des besoins. La pu­bli­ca­tion d’HTML 5.1 via GitHub propose par ailleurs la pos­si­bi­lité de par­ti­ci­per ac­ti­ve­ment aux processus d’amé­lio­ra­tion en tant que dé­ve­lop­peur.