Le 1^er novembre 2016, le World Wide Web Consortium, plus connu sous l’acronyme W3C, a enfin validé – en tant que recommandation – la version 5.1 de sa spécification de l’HyperText Markup Language généralement abrégé HTML. A l’étude depuis décembre 2012, celle-ci va définir les standards et nouveaux usages du web.
 

Un peu d’histoire

Certains d’entre vous ne le savent peut être pas mais le W3C est l’organisme à but non lucratif qui fut chargé de promouvoir, lors de sa fondation par Tim Berners-Lee en 1994, la compatibilité des technologies du World Wide Web telles que HTML5, HTML, XHTML, XML, RDF, SPARQL, CSS, XSL, PNG, SVG et SOAP. Le W3C est un consortium regroupant 439 membres parmi lesquels on retrouve des grands noms du web comme la fondation Mozilla, Apple, Microsoft, Opera, Google mais également Dell, Ebay, le CERN, Bloomberg etc.
Le consortium n’impose rien aux éditeurs, fabricants et utilisateurs. Celui-ci se contente de mettre à disposition des recommandations qui standardisent les technologies du web qu’il gère. Chacun peut suivre s’il le souhaite ces recommandations. Le vocabulaire utilisé par la suite sera plutôt autoritaire mais cela ne veut pas dire que le W3C impose et fixe ce qui doit être fait ou non. Le W3C ne possède pas de programme de certification.
Les groupes de travail sont tenus, depuis novembre 1997, de produire un rapport d’implémentation pendant la phase de « Candidate Recommendation » (3éme étape dans le processus de production d’une recommandation), en vue d’améliorer le niveau d’implémentation des spécifications. La plupart des groupes de travail produisent et publient à cette occasion des suites de tests afin que des développeurs puissent tester leur implémentation.
La W3C ne gère pas uniquement le standard HTML, mais un peu plus d’une trentaine dont ceux cités plus haut. Pour se faire, il s’appuie sur une centaine d’employés chargés des groupes d’études, de l’administration, de l’infrastructure réseau etc. La rigueur et la qualité du travail de la W3C sont mondialement reconnues et de nombreux développeurs s’investissent bénévolement pour tester et vérifier les recommandations.
Le W3C fournit également un validateur permettant de vérifier que le code source produit pour votre site ou votre application web est en accord avec la recommandation.
 

Une révision mineure

Cette première révision, à savoir le passage d’HTML 5 à HTML 5.1, n’est pas si mineure que ça. Même si elle n’apporte pas de gros bouleversements, à l’inverse de la version 5, celle-ci clarifie des fonctionnalités antérieures et en introduit de nouvelles. Je ne vais bien entendu pas tout aborder. D’une part, ce n’est pas l’objectif de cet article. Ensuite certains points sont très techniques.

Les différences entre la version 5 et sa première révision

Il y a eu 13 suppressions dans la recommandation. Je ne trouve pas ces dernières particulièrement intéressantes. Par contre, parmi les modifications de certaines fonctionnalités, plusieurs points sont à soulever.
La recommandation ne permettait pas d’encapsuler un <header> dans un <footer> et vice-versa. Par exemple, on ne pouvait pas faire ce genre de chose :

<article>
  <header>
    <h1>Un super titre</h1>
    <aside>
  <header>
    <h2>Découvrez moi</h2>
    <p><a href="#">Email</a><a href="#">Facebook</a></p>
  </header>
    <img src="photo.jpg" alt="ma photo">
    <p>Ma biographie </p>
    </aside>
  </header>
    <p>Introduction</p>
    <p>Blablabla ...</p>
</article>

 
C’est maintenant autorisé. Avouez que c’est quand même plus propre que si on avait juste des <div> ou des <section> avec un attribut indiquant que c’est le header ou le footer de notre article.
Deux petits changements qui me semblent plutôt sympathiques également :

• La possibilité de pouvoir laisser à vide l’élément <option>. De cette manière, une liste de choix peut par exemple contenir un choix vide.
• L’élément <figcaption> permettant de faire une légende dans un élément <figure> peut dorénavant être placé n’importe où dans cette dernière.

HTML 5.1 rend également possible la définition à 0 de la largeur d’une image. Mais quel est l’intérêt d’une image dont la taille serait de 0 pixel ? Et bien pour faire du tracking par exemple ou pour des animations et plein d’autres sujets. Attention, le W3C recommande cependant de ne pas remplir l’attribut alt indiquant le titre de l’image. Et ce, dans l’optique de garder celle-ci totalement invisible à l’utilisateur.
Voilà pour les suppressions qui me paraissent les plus importantes et intéressantes entre HTML 5 et HTML 5.1. Il y en a bien entendu d’autres, que vous pourrez retrouver ici.

N’hésitez pas à partager celles que vous avez découvert en commentaires de cet article !

Encore des nouveautés

C’est maintenant que ça devient passionnant. Si si, vous allez voir.
Pour cette nouvelle mouture, le W3C nous a réservé plein de surprises tel qu’un menu contextuel, des nouveaux types pour le champ de saisie, une optimisation des animations, des balises pour afficher et masquer du contenu sans JavaScript, une gestion des images qui va rendre fou de jalousie le tag <video> et plein d’autres choses.
 

Le menu contextuel

C’est pour moi surement une des plus importantes nouveautés, si ce n’est la plus importante de cette révision. On parle ici de la possibilité d’ajouter des fonctionnalités au menu contextuel de votre navigateur.
Avec une ou plusieurs fonctionnalités, le menu contextuel peut être assigné à une infinité d’éléments tels que des boutons, des images ou même un lien.
Chaque fonctionnalité peut être de type « case à cocher », « commande » ou « bouton radio ».
Malheureusement le support actuel des navigateurs n’est pas idéal. Seul Firefox l’implémente.
Vous pouvez consulter la démo suivante mise en place par Mozilla et fonctionnelle sur le navigateur Firefox : https://bug617528.bmoattachments.org/attachment.cgi?id=554309
Le code source de la démo

<div contextmenu="supermenu">
   <h1>Yo. Look at the source code.</h1>
   <img src="http://people.mozilla.com/~prouget/bugs/context-menu-test/b.gif">
</div>
&nbsp;
<menu type="context" id="supermenu">
   <menuitem label="rotate" onclick="rotate()" icon="http://cdn1.iconfinder.com/data/icons/silk2/arrow_rotate_clockwise.png"></menuitem>
   <menuitem label="resize" onclick="resize()" icon="http://cdn3.iconfinder.com/data/icons/fugue/icon/image-resize.png"></menuitem>
   <menu label="share">
     <menuitem label="twitter" onclick="alert('foo')"></menuitem>
     <menuitem label="facebook" onclick="alert('bar')"></menuitem>
   </menu>
</menu>

 
Niveau de compatibilité et polyfill disponible ici : http://caniuse.com/#search=menuitem
 
 

Les éléments Summary et Details

Les nouveaux tags <summary> et <details> permettent d’afficher et de masquer dynamiquement du contenu sans faire appel à du Javascript ou du CSS.
Le comportement par défaut va masquer le contenu de la partie <details> et afficher une flèche (rendu par défaut) pour que l’utilisateur puisse afficher ce qui est caché. Inversement, il pourra en cliquant de nouveau sur la flèche, faire disparaitre le contenu.
Ces nouvelles balises vont être très pratiques pour les rédacteurs ou contributeurs de contenu.
Demo : https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_details
Niveau de compatibilité et polyfill disponible ici : http://caniuse.com/#feat=details
 

Des nouveaux types pour le champ de saisie

Cette évolution mineure est également l’occasion de voir apparaitre trois nouveaux types pour le champ de saisie.
Le type « week » permet de sélectionner une semaine spécifique sous la forme semaine/année.
Démo : https://www.w3schools.com/Html/tryit.asp?filename=tryhtml_input_week
 
Le type « month » permet de faire la même chose mais sous la forme mois/année.
Démo : https://www.w3schools.com/Html/tryit.asp?filename=tryhtml_input_month
 
Quant au type « datetime-local », celui-ci permet de sélectionner une date complète avec l’heure et les minutes.
Démo : https://www.w3schools.com/Html/tryit.asp?filename=tryhtml_input_datetime-local
 
Le niveau de comptabilité de l’ensemble des trois types est le même, actuellement non supporté dans Firefox ou sous Internet Explorer.
 

Des images encore plus responsives

C’est l’autre gros morceau de cette révision qui va faire plaisir aux intégrateurs. A partir d’HTML 5.1, on peut utiliser une nouvelle balise <picture> similaire à sa sœur <video>.
Celle-ci permet de définir plusieurs sources pour une image. Elle représente un conteneur d’image.
Le navigateur pourra ainsi sélectionner la source adéquate en fonction de plusieurs critères que sont la disposition de l’image dans la page et l’écran utilisé par l’internaute.
A l’aide de l’attribut media, on pourra définir une media-querie qui sera évaluée par le navigateur. Si l’évaluation correspond, le navigateur pourra sélectionner la source pour afficher la ressource. Dans le cas contraire, la source est ignorée.
Cependant, le conteneur n’affichera pas l’image, ce n’est pas son objectif. Vous devez toujours déclarer, à l’aide du tag <img>, l’image par défaut et placer le tout entre les balises <picture>. La source de l’image par défaut sera changée si une autre source est évaluée comme valable.
Les écrans n’ayant pas tous la même densité de pixel ou résolution, vous pouvez avoir besoin de charger une image d’une meilleure qualité sur un écran 4k et faisant 40 pouces que sur un écran toujours 4k mais faisant 20 pouces. Il existe donc un grand nombre de critères pour définir le bon usage d’une source et un critère peut avoir également plusieurs sources correspondantes, dans le cas de la densité de pixel par exemple.
Je vous invite à consulter la démo suivante : https://googlechrome.github.io/samples/picture-element/ et à consulter https://www.html5rocks.com/en/tutorials/responsive/picture-element/ pour approfondir le sujet. Si l’anglais ne vous fait pas peur.
Niveau de compatibilité et polyfill disponible ici : http://caniuse.com/#search=picture
 

L’anti-phishing

Avant de vous expliquer la petite nouveauté, je dois aborder un exploit.
Lorsqu’on ajoute un lien dans une page en html, on peut décider que ce lien s’ouvrira dans un nouvel onglet. Ça ce n’est un secret pour personne. Mais savez-vous que la page nouvellement ouverte peut agir sur la page source ? A l’aide de JavaScript et notamment de « window.opener », on peut agir sur la page source et y exécuter du code malveillant voir même rediriger sur un faux site et du coup faire du phishing.
Vous pouvez tester sur ce site : https://mathiasbynens.github.io/rel-noopener/ (En anglais)
Dans l’optique d’éviter ce genre de comportement et de protéger l’internaute, le W3C a standardisé un nouvel attribut disponible sur le lien mais également sur <area> : rel= « noopener ». Ce dernier permet la séparation des contextes. Le contexte de la page source ne sera plus partagé à la page destinataire ou nouvellement ouverte dans un onglet.
Cet attribut n’est actuellement pas totalement supporté. Chrome et Opera le gèrent depuis plusieurs versions. Quant à Firefox, la 52 aura l’implémentation. De même avec la prochaine version de safari.
Niveau de compatibilité et polyfill disponible ici : http://caniuse.com/#feat=rel-noopener
 
 

L’avenir

Le consortium travaille déjà depuis longtemps sur la prochaine version d’HTML 5.1, sa révision mineure 2. Le premier brouillon est sorti le 18 aout 2016. L’objectif étant de faire valider cette spécification et de rendre publique la recommandation en fin d’année 2017.
On peut également espérer que les premiers cours traitant de cette recommandation arriveront rapidement sur le site du w3schools.
Il y a bien entendu beaucoup d’autres fonctionnalités que je n’ai pas souhaité aborder, mais je vous invite fortement à consulter les liens suivants pour en apprendre davantage !
 
Sources :
Le rapport d’implémentation : https://w3c.github.io/test-results/html51/implementation-report.html
Liste des changements : https://www.w3.org/TR/2016/REC-html51-20161101/changes.html#changes