L'une des erreurs les plus courantes commises lors de l'utilisation de balises est d'assimiler la <section> du HTML5 à <div> - en particulier, de l'utiliser directement en remplacement (à des fins de style). En XHTML ou HTML4, on voit souvent du code comme celui-ci :
<!-- Code HTML 4 styles --><div id=wrapper> <div id=header> <h1>Ma super page duper</h1> Contenu de l'en-tête </div> <div id=main> Contenu de la page < /div> <div id=secondary> Contenu secondaire </div> <div id=footer> Contenu du pied de page </div></div>
Maintenant en HTML5, cela ressemblera à ceci :
Merci de ne pas copier ce code ! C'est faux !
<section id=wrapper> <header> <h1>Ma page super duper</h1> <!-- Contenu de l'en-tête --> </header> <section id=main> <!-- Contenu de la page --> </ section> <section id=secondary> <!-- Contenu secondaire --> </section> <footer> <!-- Contenu du pied de page --> </footer></section>
Cette utilisation est incorrecte :**
Ce n'est pas un conteneur de style. L'élément **section représente la partie sémantique du contenu utilisée pour aider à créer un résumé de document. Il doit contenir un en-tête. Si vous recherchez un élément qui agit comme un conteneur de page (comme le style HTML ou XHTML), envisagez d'écrire le style directement dans l'élément body, comme le suggère Kroc Camen. Si vous avez encore besoin de conteneurs de style supplémentaires, restez fidèle aux divs.
Sur la base des idées ci-dessus, voici des exemples d'utilisation correcte de HTML5 et de certaines fonctionnalités des rôles ARIA (notez qu'en fonction de votre propre conception, vous devrez peut-être également ajouter des divs)
<body><header> <h1>Ma page super duper</h1> <!-- Contenu de l'en-tête --></header><div role=main> <!-- Contenu de la page --></div>< side role=complementary> <!-- Contenu secondaire --></aside><footer> <!-- Contenu du pied de page --></footer></body>2. Utilisez les en-têtes et les hgroups uniquement lorsque cela est nécessaire
Cela ne sert bien sûr à rien d’écrire des étiquettes qui n’ont pas besoin d’être écrites. Malheureusement, je vois souvent des en-têtes et des hgroups utilisés à mauvais escient sans but. Vous pouvez lire les deux articles sur les éléments header et hgroup pour une compréhension détaillée. Je résume brièvement le contenu comme suit :
Étant donné que les en-têtes peuvent être utilisés plusieurs fois dans un document, cela peut rendre ce style de codage populaire :
Merci de ne pas copier ce code ! Aucun en-tête n'est nécessaire ici ->
<header> <h1>Mon meilleur article de blog</h1> </header> <!-- Contenu de l'article --></article>
Si votre élément d'en-tête ne contient qu'un seul élément d'en-tête, supprimez l'élément d'en-tête. Étant donné que l'élément article garantit déjà que l'en-tête apparaîtra dans le résumé du document et que l'en-tête ne peut pas contenir plusieurs éléments (comme défini ci-dessus), pourquoi écrire du code supplémentaire. Écrivez-le simplement comme ceci :
<article> <h1>Mon meilleur article de blog</h1> <!-- Contenu de l'article --></article>
utilisation incorrecte de
En ce qui concerne les en-têtes, je vois aussi souvent des hgroups utilisés de manière incorrecte. Parfois, hgroup et header ne doivent pas être utilisés ensemble :
La première question ressemble généralement à ceci :
Veuillez ne pas copier ce code ! Aucun hgroup n'est nécessaire ici –> <hgroup> <h1>Mon meilleur article de blog</h1> </hgroup> <p>par Rich Clark</p></header>
Dans cet exemple, supprimez simplement le hgroup et laissez le titre suivre son cours.
<header> <h1>Mon meilleur article de blog</h1> <p>par Rich Clark</p></header>
La deuxième question est un autre exemple inutile :
Veuillez ne pas copier ce code ! Aucun en-tête n'est requis ici ->
<hgroup> <h1>Mon entreprise</h1> <h2>Créée en 1893</h2> </hgroup></header>
Si le seul sous-élément de l’en-tête est hgroup, que fait l’en-tête ? S'il n'y a pas d'autres éléments dans l'en-tête (comme plusieurs hgroups), supprimez simplement l'en-tête directement.
<hgroup> <h1>Mon entreprise</h1> <h2>Créée en 1893</h2></hgroup>3. Ne mettez pas tous les liens de type liste dans la navigation
Avec l'introduction de 30 nouveaux éléments dans HTML5 (au moment de la publication originale), nos choix dans la construction de balises sémantiques et structurées sont devenus quelque peu imprudents. Cela dit, il ne faut pas abuser des éléments hyper-sémantiques. Malheureusement, nav est un exemple d'un tel abus. La spécification de l'élément nav est décrite comme suit :
L'élément nav représente un bloc dans la page qui renvoie vers d'autres pages ou d'autres parties de cette page ; un bloc qui contient des connexions de navigation.
Remarque : Tous les liens de la page n'ont pas besoin d'être placés dans l'élément nav ; cet élément est destiné à être utilisé comme bloc de navigation principal. Pour donner un exemple précis, il y a souvent de nombreux liens dans le pied de page, tels que les conditions d'utilisation, la page d'accueil, la page de déclaration de droits d'auteur, etc. L'élément footer lui-même est suffisant pour gérer ces situations. Bien que l'élément nav puisse également être utilisé ici, nous pensons généralement qu'il est inutile.
Les mots clés sont la navigation principale. Bien sûr, nous pouvons nous gicler toute la journée sur ce qui est important. Voici comment je le définis personnellement :
Pour un accès plus facile, ajouterez-vous un lien vers cette balise de navigation dans un raccourci ?
Si la réponse à ces questions est non, saluez-vous et partez seul.
4. Erreurs courantes dans les éléments de la figureL’utilisation correcte de la figure et de la légende est en effet difficile à maîtriser. Jetons un coup d'œil à quelques erreurs courantes,
Toutes les images ne sont pas des chiffres
Ci-dessus, je vous ai dit de ne pas écrire de code inutile. Il en va de même pour cette erreur. J'ai vu de nombreux sites Web étiqueter toutes les images comme des chiffres. Pour le bien de l'image, veuillez ne pas y ajouter de balises supplémentaires. Vous vous faites simplement du mal et vous ne rendez pas votre page plus claire.
Les figures sont décrites dans la description sous forme de contenu fluide, parfois avec leur propre description de titre. Généralement, ils sont référencés comme unités indépendantes dans le flux de documents. C'est la beauté de la figure : elle peut être déplacée de la page de contenu principale vers la barre latérale sans affecter le flux de documents.
Ces problèmes sont également couverts par l'organigramme des éléments HTML5 mentionné précédemment.
Si le diagramme est uniquement destiné à la présentation et n'est pas référencé ailleurs dans le document, alors il n'est certainement pas
. Le reste dépend de la situation, mais commencez par vous demander : cette image doit-elle être pertinente par rapport au contexte ? Sinon, ce n’est probablement pas le cas non plus (peut-être que c’est le cas). Passons à autre chose : puis-je déplacer ceci vers une annexe ? Si les deux questions s’appliquent, c’est probablement le cas.
Le logo n'est pas une figure
De plus, les logos ne s’appliquent pas non plus aux figures. Voici quelques extraits de code courants que j’utilise :
<!-- Veuillez ne pas copier ce code ! C'est faux--><header> <h1> <figure>  </figure> Nom de ma société </h1 > </header><!-- Veuillez ne pas copier ce code ! C'est également faux--><header> <figure>  </figure></header>
Il n'y a plus rien à dire. C'est une erreur très courante. Nous pouvons nous disputer jusqu’à ce que les vaches rentrent chez elles pour savoir si le logo doit être une étiquette H1, mais ce n’est pas le sujet ici. Le vrai problème est la surutilisation de l’élément figure. Les figures ne doivent être référencées que dans le document ou entourées d'éléments de section. Je pense qu'il est peu probable que votre logo soit référencé de cette manière. C'est simple, n'utilisez pas de chiffres. Il vous suffit de faire ceci :
<header> <h1>Nom de mon entreprise</h1> <!-- Plus de détails ici --></header>
La figure n'est pas qu'une image
Une autre idée fausse très répandue à propos des figures est qu’elles ne sont utilisées que par les images. Une figure peut être une vidéo, un audio, un graphique, une citation, un tableau, un code, une prose ou toute combinaison de ceux-ci ou d'autres. Ne limitez pas les chiffres aux images. C'est le travail des standards du Web de décrire avec précision le contenu à l'aide de balises.
5. N'utilisez pas d'attributs de type inutilesC'est un problème courant, mais pas une erreur, et je pense que nous devrions éviter ce style grâce aux meilleures pratiques.
En HTML5, les éléments de script et de style ne nécessitent plus l'attribut type. Cependant, ceux-ci sont susceptibles d’être automatiquement ajoutés par votre CMS, il n’est donc pas si simple de les supprimer. Mais si vous codez à la main ou si vous avez un contrôle total sur vos modèles, il n'y a vraiment aucune raison d'inclure l'attribut type. Tous les navigateurs pensent que les scripts sont du javascript et que les styles sont des styles css, vous n'avez donc plus besoin de le faire.
<!-- Veuillez ne pas copier ce code ! Il est trop redondant ! --><link type=text/css rel=stylesheet href=css/styles.css /><script type=text/javascript src=js/ scripts /></script>
En fait, il suffit d'écrire :
<link rel=stylesheet href=css/styles.css /><script src=js/scripts /></script>
Même le code spécifiant le jeu de caractères peut être omis. Mark Pilgrim l'explique dans le chapitre Sémantique de Dive into HTML5.
6. Utilisation incorrecte de l'attribut de formulaireHTML5 introduit de nouveaux attributs de formulaire. Voici quelques notes d'utilisation :
Propriétés booléennes
Certains éléments multimédias et d'autres éléments ont également des propriétés booléennes. Les mêmes règles s'appliquent ici.
Certains des nouveaux attributs du formulaire sont booléens, ce qui signifie que tant qu'ils apparaissent dans l'étiquette, le comportement correspondant est garanti. Ces propriétés comprennent :
Franchement, je vois rarement ça. En prenant requis comme exemple, les plus courants sont les suivants :
<!-- Veuillez ne pas copier ce code ! C'est faux ! --><input type=email name=email requirejs=true /><!-- Un autre exemple d'erreur --><input type=email name = email requis=1 />
À proprement parler, ce n’est pas grave. Tant que l'analyseur HTML du navigateur voit l'attribut requis apparaître dans une balise, sa fonctionnalité sera appliquée. Mais que se passe-t-il si vous écrivez require=false dans l’autre sens ?
<!-- Veuillez ne pas copier ce code ! C'est faux ! --><input type=email name=email requirejs=false />
L'analyseur traitera toujours l'attribut requis comme valide et exécutera le comportement correspondant, même si vous essayez de lui dire de ne pas l'exécuter. Ce n'est évidemment pas ce que vous voulez.
Il existe trois manières valides d'utiliser les propriétés booléennes. (Ces deux derniers ne sont valables qu'en xthml)
La bonne façon d’écrire l’exemple ci-dessus est :
<input type=email name=email requis />Résumer
Ce qui précède est ce que l'éditeur vous présente sur la façon d'éviter 6 utilisations incorrectes courantes de HTML5. J'espère que cela vous sera utile. Si vous avez des questions, veuillez me laisser un message et l'éditeur vous répondra à temps. Je tiens également à remercier tout le monde pour votre soutien au site d'arts martiaux VeVb !