La balise html est-elle fermée ou non ?
Lorsque vous écrivez du code HTML5, vous êtes-vous déjà demandé si vous deviez écrire
ou
, s'il fallait écrire ou . Pourquoi est-il mal d'écrire ? Quoi qu'il en soit, j'ai eu du mal avec cela et j'ai trouvé que ce sujet est en fait beaucoup plus intéressant que je ne le pensais.
Si mon processus de recherche ne vous intéresse pas, vous pouvez accéder directement à la section « Légitimité » pour obtenir la réponse.
Éléments vides
Un élément sans contenu est un élément spécial qui ne peut contenir aucun contenu. D'autres éléments, tels que
, peuvent ne contenir aucun contenu ou contenir un autre élément ou texte.
Les éléments sans contenu les plus courants sont :
n'est pas du HTML légal car il implique que br peut contenir du contenu (mais
Bonjour ! n'a aucun sens).
et
, il n'y a aucune exigence explicite en HTML. Historique de traçage Afin de bien comprendre l’élément sans contenu, nous devons comprendre son histoire. HTML, XML et XHTML sont tous basés sur SGML. Le nom complet de SGML est « Standard General Markup Language », rédigé en 1986.
HTML et XML sont tous deux dérivés de SGML, où XML est un sous-ensemble contraint de SGML et XHTML est basé sur XML.
XHTML est fondamentalement identique à HTML, mais basé sur XML.Ensuite, une balise qui ne contient aucun contenu peut être écrite sous la formeSGML possède une fonctionnalité appelée "Null End Tag (NET)". Lorsqu'il n'y a qu'un texte simple dans l'étiquette, l'utilisation d'une étiquette sans queue élimine le besoin de fermer l'étiquette. Par exemple, vous pouvez écrire
Texte citésous la forme.)
Si, selon cette logique, la première moitié de
, alors
ne sera-t-il pas analysé comme
> ? Si vous pensez comme moi, vous pensez aussi que cette syntaxe est stupide. Malheureusement, les créateurs de la spécification HTML4 ne l'ont pas pensé et l'ont écrit dans la spécification. Cependant, il est évident que les fabricants de navigateurs de l’époque ne se souciaient pas de cette syntaxe et ne la supportaient pas dans une large mesure. (À ce stade, peut-être que les fabricants de navigateurs ont fait une bonne chose.) Les créateurs de la spécification XML (également applicable au XHTML) se sont rendu compte que cette syntaxe n'était pas très bonne, ils n'ont donc tout simplement pas inclus la fonctionnalité de balises sans queue,En même temps, il fournit une syntaxe relativement facile à comprendre pour les balises sans contenu. Le nom de cette syntaxe est "balises sans élément", et elle ressemble à ceci :
. Cette syntaxe semblait si naturelle que la plupart des développeurs de l’époque pensaient que c’était la bonne façon de l’écrire.Heureusement, le HTML s'améliore constamment et les membres du W3C apprennent des erreurs qu'ils ont commises dans le passé. C'est pourquoi HTML5 a fait de si grands progrès par rapport aux versions précédentes.
Lors de l'introduction de la nouvelle syntaxe HTML5, le W3C a déclaré :
La syntaxe de HTML5 est entièrement compatible avec HTML4 et XHTML1, mais n'est pas compatible avec ces obscures fonctionnalités HTML4 de SGML. Par exemple, pas de balise de queue ( HTML5 Bravo !
(Je pense qu'ils devraient conserver la fonctionnalité "balises courtes", comme Nice, ce que je trouve cool. Mais au moins le HTML est moins encombré maintenant.)
Légalité Bon, revenons à la question sur la légalité au début de l'article. L'explication actuelle des balises de non-contenu dans la spécification HTML5 est la suivante :. Ces balises doivent être constituées des parties suivantes, dans le même ordre que le tableau ci-dessous :
Un caractère "<".
Nom de la balise.
Cet élément est facultatif, un ou plusieurs attributs, chaque attribut doit être précédé d'un ou plusieurs espaces.
Ceci est facultatif, un ou plusieurs espaces.
Cet élément est facultatif, un caractère "/", cet élément ne peut apparaître que dans des éléments sans contenu.
Un caractère ">".
Le caractère "/" dans l'avant-dernière partie est facultatif et n'a aucune signification réelle. Il n'y a donc en fait aucune réelle différence entre
et
.Exactitude
Les développeurs qui aiment XML et XHTML peuvent dire : "Oui, bien que / soit facultatif,
est 'plus correct'. Je dois te dire que tu as tort. En fait, certains soutiennent que / dans les balises sans contenu est en fait une erreur grammaticale tolérée. Cette tolérance est basée sur des considérations de compatibilité, ce qui amène tous les navigateurs et analyseurs à traiter
et
Sur ce point, le guide de style de code de Google stipule également clairement de ne pas fermer la balise content-free.
Inconvénients
Bien sûr, il y a aussi des inconvénients à ne pas fermer les balises sans contenu, mais je ne pense pas que cela puisse masquer ses avantages : rendre votre code propre et concis.
Le premier inconvénient est que le développeur doit savoir quelles balises n’ont pas de balises de contenu. Supposons que vous ne sachiez pas si
est une balise sans contenu, alors lorsque vous ne trouvez pas sa balise de fermeture, vous vous demanderez si vous devez fermer cette balise. Cependant, il n'y a que quelques balises sans contenu au total, et vous pouvez généralement savoir d'un coup d'œil si une certaine balise est une balise sans contenu.
Le deuxième inconvénient est que l'éditeur peut ne pas bien gérer les balises sans contenu non fermées. Les développeurs d'éditeurs doivent comprendre les balises sans contenu et fournir une coloration syntaxique et une complétion de code appropriées. Lorsque vous écrivez un dans l'éditeur, celui-ci doit savoir qu'il ne sera jamais suivi de .
Mais ces fonctions sont très simples à mettre en œuvre, et les éditeurs que je connais supportent assez bien cet aspect, ce n'est donc pas vraiment un inconvénient.
Mes réflexions sur les balises sans contenu
Je pense que le concept de balises sans contenu peut en fait être éliminé du HTML. Nous pouvons ajouter du contenu à ces balises pour remplacer certains de ses attributs.
Prenons l'exemple de la balise
. Elle possède un attribut alt obligatoire. Cet attribut existe pour empêcher les utilisateurs qui ne peuvent pas voir les images (peut-être en raison de défauts physiques ou parce que l'appareil qu'ils utilisent ne prend pas en charge les images). est à propos (si l'image est juste pour des raisons esthétiques, vous ne devriez vraiment pas ajouter l'attribut alt).
Ma question est la suivante : pourquoi ne pas utiliser le contenu de
au lieu de l'attribut alt ? Je pense que c'est plus intuitif de l'écrire de cette façon :
Image du doge.
La balise possède même un attribut appelé content ! Pourquoi ne pas simplement écrire la valeur du contenu directement dans le contenu de la balise ? doit être écrit sous la forme Value content, tout comme