Fin d’année 2017, HTML 5.2 est devenu une recommandation officielle du W3C (REC). Quand une spécification atteint le stade REC, cela signifie qu’elle a reçu l’approbation officielle des membres du W3C et du directeur, et que le W3C recommande officiellement son déploiement par les agents utilisateurs, et sa mise en œuvre par les auteurs des pages Web.

À l’étape REC, tout nouveau devrait avoir eu au moins deux implémentations indépendantes . C’est le moment idéal pour nous, en tant que développeurs de pages Web, de commencer la mise en œuvre de toute nouvelle fonctionnalité.

Dans HTML 5.2, il y a eu un certain nombre d’ajouts et de suppressions, qui peuvent tous être visualisés sur la page officielle des changements HTML 5.2 . Dans cet article, je vais passer en revue certains des changements qui, selon moi, auront le plus d’impact sur mon développement.

Nouvelles fonctionnalités

Un élément <dialog> natif

De tous les changements dans HTML 5.2, je suis le plus excité à propos de l’introduction de l’ élément <dialog> , une boîte de dialogue native. Les dialogues sont incroyablement répandus sur le Web, mais chaque implémentation est différente d’une certaine manière. Les dialogues sont également très difficiles à faire d’une manière accessible, ce qui rend la plupart des boîtes de dialogue sur le Web pratiquement inutilisables pour les utilisateurs qui ne naviguent pas visuellement sur le Web.

Le nouvel élément <dialog> vise à changer cela, en fournissant un moyen simple d’inclure une boîte de dialogue modale sans avoir à se soucier de la plupart des pièges. Je vais écrire un article séparé et détaillé sur le fonctionnement de cet élément, mais voici les bases.

Quelles sont les nouveautés pour HTML 5.2 ?

La boîte de dialogue est créée en utilisant un élément <dialog> :

<dialog>
 <h2>Dialog Title</h2>
 <p>Dialog content and other stuff will go here</p>
</dialog>

Par défaut, la boîte de dialogue est masquée à la vue (et à partir de l’accès DOM) à moins que l’attribut open soit appliqué.

<dialog open>

L’attribut open peut être basculé en appelant les méthodes show() et close() , disponibles pour tout HTMLDialogElement .

<button id="open">Open Dialog</button>
<button id="close">Close Dialog</button>
<dialog id="dialog">
 <h2>Dialog Title</h2>
 <p>Dialog content and other stuff will go here</p>
</dialog>
<script>
const dialog = document.getElementById("dialog");
document.getElementById("open").addEventListener("click", () => {
 dialog.show();
});
document.getElementById("close").addEventListener("click", () => {
 dialog.close();
});
</script>

L’élément <dialog> a déjà un support dans Chrome, et est derrière un drapeau dans Firefox.

Utilisation de l’API de demande de paiement en iFrames

L’ API de demande de paiement est une alternative native aux formulaires de paiement. Il vise à fournir une méthode normalisée et cohérente pour effectuer des paiements sur le Web pour les utilisateurs, en déplaçant le traitement de la récupération des informations de paiement vers le navigateur, au lieu des formulaires de paiement individuels sur chaque site Web.

Avant HTML 5.2, ces demandes de paiement ne pouvaient pas être faites à partir d’iframes incorporées dans un document. Cela rendait pratiquement impossible l’utilisation de cette API par les solutions de paiement intégrées tierces (par exemple Stripe, Paystack), puisque leur interface de paiement est généralement gérée au sein d’un iframe.

HTML 5.2 a introduit l’attribut allowpaymentrequest qui, lorsqu’il est appliqué à un iframe, lui permet d’utiliser l’API de demande de paiement lorsque l’utilisateur se trouve sur la page Web d’hébergement.

<iframe allowpaymentrequest>

Tailles pour les icônes Apple

Pour définir les icônes de pages Web, nous utilisons l’élément <link rel=”icon”> dans la tête de notre document. Pour définir différentes tailles d’icônes, nous utilisons l’attribut sizes .

<link rel="icon" sizes="16x16" href="path/to/icon16.png">
<link rel="icon" sizes="32x32" href="path/to/icon32.png">

Cet attribut, bien que purement consultatif, permet aux agents utilisateurs de décider quelle taille d’icône utiliser si plusieurs tailles sont disponibles, d’autant plus que la plupart des périphériques ont leur propre taille d’icône “optimale”.

Avant HTML 5.2, l’attribut sizes n’était valide que si la relation de lien était une icon . Cependant, les appareils iOS d’Apple ne prennent pas en charge l’attribut de sizes . Pour contourner ce appple-touch-icon , Apple a introduit une relation spécifique au périphérique, appple-touch-icon , qui pourrait être utilisée pour définir l’icône utilisée sur leurs appareils.

En HTML 5.2, la spécification permet désormais d’utiliser l’attribut sizes si la relation est une apple-touch-icon , et non plus seulement une icon . Cela nous permettra de fournir différentes tailles d’icônes pour différents appareils Apple. Bien que, pour autant que je sache actuellement, les appareils Apple ne supportent toujours pas l’attribut de sizes , ce changement sera utile pour le futur quand ils le feront finalement.

Pratiques nouvellement valides

En plus des nouvelles fonctionnalités, HTML 5.2 a validé certaines pratiques d’écriture HTML qui étaient auparavant invalides.

Plusieurs éléments <main>

L’élément <main> représente le contenu principal d’une page Web. Alors que le contenu répété sur plusieurs pages peut être placé dans des en-têtes, des sections ou tout autre élément, l’élément <main> est réservé au contenu spécifique et unique à la page en question. Par conséquent, avant HTML 5.2, l’élément <main> devait être unique dans le DOM pour que la page soit valide.

Avec la prévalence des applications de page unique, cependant, coller à cette règle pourrait être difficile. Il peut y avoir des cas dans lesquels il existe plusieurs éléments <main> dans le DOM, mais un seul est montré à l’utilisateur à un moment donné.

Avec HTML 5.2, nous pouvons maintenant avoir plusieurs éléments <main> dans notre balisage, à condition qu’un seul soit visible par l’utilisateur à un moment donné. Tout élément supplémentaire doit être masqué à l’aide de l’attribut hidden .

<main>...</main>
<main hidden>...</main>
<main hidden>...</main>

Comme nous le savons, il existe plusieurs façons de masquer un élément avec CSS . Cependant, tout élément <main> supplémentaire doit être masqué à l’aide de l’attribut hidden . Toute autre méthode pour masquer l’élément, par exemple display: none; ou visibility: hidden; ne sera pas valide.

Styles dans le <body>

En règle générale, CSS intégré défini à l’aide de l’élément <style> est placé dans la <head> du document HTML. Avec l’augmentation du développement par composants, les développeurs ont vu l’avantage d’écrire et de placer des styles avec l’élément html pour lequel ils sont pertinents.

En HTML 5.2, définir un bloc <style> n’importe où dans le <body> d’un document HTML est maintenant valide. Cela signifie que nous pouvons avoir des styles plus proches de l’endroit où ils sont utilisés.

<body>
 <p>I’m cornflowerblue!</p>
 <style>
 p { color: cornflowerblue; }
 </style>
 <p>I’m cornflowerblue!</p>
</body>

Cependant, il est toujours noté que les styles devraient de préférence être placés dans la <head> , pour des raisons de performances . Selon la spécification ,

Un élément de style devrait de préférence être utilisé dans la tête du document. L’utilisation du style dans le corps du document peut provoquer un restylage, une mise en page de déclencheur et / ou un repeint, et doit donc être utilisé avec précaution.

Il convient également de noter que, comme indiqué dans l’exemple, les styles ne sont pas définis. Un style en ligne défini plus tard dans le document HTML s’appliquera toujours aux éléments définis avant lui, c’est pourquoi il peut déclencher le repeindre.

Titres dans une <legend>

Dans les formulaires, l’élément <legend> représente une légende pour les champs de formulaire dans un <fieldset> . Avant HTML 5.2, le contenu d’une légende devait être en texte brut. Maintenant, nous pouvons inclure des éléments d’en-tête.

<fieldset>
 <legend><h2>Basic Information</h2></legend>
 <!-- Form fields for basic information -->
</fieldset>
<fieldset>
 <legend><h2>Contact Information</h2></legend>
 <!-- Form fields for contact information -->
</fieldset>

Ceci est vraiment utile lorsque nous voulons utiliser l’élément fieldset pour grouper différentes sections d’un formulaire. Dans de tels cas, il est parfaitement logique d’utiliser des en-têtes, ce qui rendrait ces sections de formulaire plus facilement navigables pour les utilisateurs qui s’appuient sur un plan de document.

Fonctions supprimées

En HTML 5.2, quelques éléments ont été supprimés, à savoir:

* keygen : Utilisé pour aider à générer des clés publiques pour les formulaires
* menu et menuitem : Permet de créer des menus de navigation ou contextuels

Pratiques nouvellement invalides

Enfin, certaines pratiques de développement ont été invalidées.

Aucun enfant en ligne, flottant ou bloc dans <p>

En HTML 5.2, les seuls enfants valides d’un élément <p> devraient être du contenu. Cela signifie que les types d’éléments suivants ne doivent plus être imbriqués dans un paragraphe:

* Blocs en ligne
* Tables en ligne
* Blocs flottants et positionnés

Pas de Doctypes Strictes

Enfin, nous pouvons dire adieu aux types de documents suivants:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *