L’écriture d’étiquettes à fermeture automatique pour des éléments n’est-elle généralement pas vider de mauvaise pratique?

Question

J'ai remarqué que jQuery (ou s'agit-il de Firefox) transformera une partie de mes <span class="presentational"></span> into <span class="presentational" />

Maintenant, ma question est la suivante: est-ce correct d’écrire mon balisage comme ceci? Est-ce que les navigateurs vont s'étouffer?

Personnellement, je pense que cela semble plus propre à faire <span class="presentational" /> s'il est vide.

Answer 1

Je suppose que votre question concerne la barre oblique rouge sur les éléments à fermeture automatique lorsque vous affichez la source dans Firefox. Si tel est le cas, vous êtes tombé dans l'un des débats agressifs les plus véhéments, mais aussi les plus passifs, entre les guerres des constructeurs de navigateurs et des développeurs Web. XHTML ne concerne pas uniquement le balisage d'un document. Cela concerne également la manière dont les documents doivent être signifiés sur le Web.

Avant de commencer; J'essaie de ne pas prendre parti ici.

La spécification XHTML 1.1 indique qu'un serveur Web doit servir XHTML avec un type de contenu d'application / xhtml + xml. Firefox supprime ces barres obliques comme non valides, car votre document est présenté sous forme de texte / html plutôt que d'application / xhtml + xml. Prenons ces deux exemples. balisage identique, l'un servant d'application / xhtml + xml, l'autre de texte / html.

http://alanstorm.com/testbed/xhtml-as-html.php

http://alanstorm.com/testbed/xhtml-as-xhtml.php

Firefox marque la barre oblique de fin de la balise meta comme non valide pour le document servi avec text / html et valide pour le document servi avec application / xhtml + xml.

Pourquoi c'est controversé

Pour un développeur de navigateur, le point XHTML est que vous pouvez traiter votre document en tant que XML, ce qui signifie que si quelqu'un vous envoie quelque chose qui n'est pas valide, la spécification indique que vous ne devez pas l'analyser. Ainsi, si un document est servi en tant qu'application / xhtml + xml et que son contenu n'est pas bien formé, le développeur est autorisé à dire & "Pas mon problème &"; Vous pouvez voir cela en action ici

http://alanstorm.com/testbed/xhtml-not-valid.php

Lorsqu'un document est servi sous forme de texte / html, Firefox le traite comme un vieux document HTML ordinaire et utilise le pardon, le corrige pour vous, en analysant les routines

http://alanstorm.com/testbed/xhtml-not -valid-as-html.php

Ainsi, pour un fabricant de navigateur, le format XHTML utilisé en tant que texte / html est ridicule, car il n'est jamais traité en tant que XML par le moteur de rendu du navigateur.

Il y a quelques années, les développeurs Web qui cherchaient à devenir plus que des singes marqueurs (Avertissement: je m'inclue parmi eux) ont commencé à chercher des moyens de développer des pratiques optimales qui ne comportaient pas trois tables imbriquées, mais permettaient tout de même une expérience de conception convaincante. Ils / Nous nous sommes accrochés à XHTML / CSS, car le W3C a déclaré que c’était l’avenir et que le seul autre choix était un monde où un seul fournisseur (Microsoft) contrôlait la spécification de balisage de facto. Le vrai mal, c’est le fournisseur unique , et pas tellement Microsoft. Je jure.

Alors, où est la controverse? Il y a deux problèmes avec application / xhtml + xml. Le premier est Internet Explorer. Il existe un bug / une fonctionnalité héritée dans IE où le contenu servi en tant qu'application / xhtml + xml inviterait l'utilisateur à télécharger le document. Si vous avez essayé de visiter le xhtml-as-xhtml.php mentionné ci-dessus avec IE, c'est probablement ce qui s'est passé. Cela signifie que si vous souhaitez utiliser application / xhtml + xml, vous devez rechercher le navigateur par IE , cocher l'en-tête Accepte et ne servir que application / xhtml + xml aux navigateurs qui l'acceptent. Ceci est pas si simple comme il semble y avoir raison, et a également été contre le & "écrire une fois &"; principe que les développeurs Web recherchaient.

Le deuxième problème est la dureté de XML. Encore une fois, c’est l’un de ces problèmes qui sont sujets à la flamme, mais certaines personnes pensent qu’une seule balise incorrecte ou un seul caractère mal codé ne devrait pas empêcher un utilisateur de se voir.Ng le document qu'ils veulent. En d’autres termes, oui, la spécification dit que vous devez arrêter de traiter XML si elle n’est pas bien formée, mais l’utilisateur ne se soucie pas de la spécification, il se soucie que le site Web de son chat soit cassé.

La spécification XHTML 1.0 (et non la 1.1) ajoute encore plus d’essence à ce problème: les documents XHTML peuvent être servis sous forme de texte / html, en supposant que certains directives de compatibilité sont suivies. Des choses comme la balise img étant à fermeture automatique, etc. Le mot clé ici est may . Dans Parler en RFC , peut signifier facultatif. Firefox a choisi de NE PAS traiter les documents servis avec un doctype XHTML mais un type de contenu text / html identique à XHTML. Cependant, le validateur du W3C signalera avec plaisir que ces documents sont valides.

Je laisserai au lecteur le soin de s'interroger sur les merveilles et l'horreur simultanées d'une culture qui rédige un document pour définir ce qu'elles entendent par le mot may .

Aller de l'avant

Enfin, c’est l’objet même de l’ensemble des HTML 5 . XHTML est devenu un sujet politique tellement brûlant qu'un groupe de personnes désireuses de faire avancer le langage ont décidé d'aller dans une autre direction. Ils ont produit une spécification pour HTML 5. Ceci est en cours de hachage dans le W3C et devrait se terminer au cours de la prochaine décennie. Entre-temps, les éditeurs de navigateurs sélectionnent et choisissent des fonctionnalités dans la spécification en cours et les implémentent.

Mises à jour à partir des commentaires

Dans les commentaires, Alex indique que si vous voulez détecter quelque chose, cochez la case Accepter. en-tête pour voir si application / xhtml + xml est accepté par l'agent utilisateur.

Ceci est absolument correct. En général, si vous voulez renifler, reniflez pour la fonctionnalité, pas pour le navigateur.

Answer 2

Complément aux autres réponses: dans IE, le fait d’avoir des éléments tels que <span /> dans votre balise entraînera toutes sortes de problèmes avec les méthodes de traversée du DOM en JavaScript . Consultez le document XHTML suivant:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <title>Test</title>
    <script type="text/javascript">
        function show() {
            var span = document.getElementById("span");
            alert(span.innerHTML);
        }
    </script>
</head>
<body onload="show();">
<p id="p1">Paragraph containing some text followed by
           an empty span<span id="span"/></p>
<p id="p2">Second paragraph just containing text</p>
</body>
</html>

L’idée est que lors du chargement de la page, le code JavaScript obtiendra une référence à la plage vide et affichera son contenu HTML. Ce sera une chaîne vide, non? Pas dans IE ce ne sera pas. Dans IE, vous obtenez tout le contenu après la fin du document:

</P>
<P id=p2>Second paragraph just containing text</P>

En outre, le deuxième <p> apparaît dans la collection childNodes de la plage. Cette même <=> également dans la collection <=> du corps, ce qui signifie un nœud peut avoir plusieurs parents . Ce n’est pas une très bonne nouvelle pour les scripts qui reposent sur le DOM.

J'ai également publié un blog à ce sujet .

Answer 3

Oui. Il est. Cela causera dans certains cas des problèmes pour les anciens navigateurs.

<script type='text/javascript' src='script.js' />

Dans ce cas, l'ancien navigateur peut ne pas comprendre que la <script> balise est terminée.

Answer 4

Servi en tant qu'application / xhtml + xml, < span / > signifie créer un élément span sans contenu.

Servi comme texte / html, < span / > signifie créer un élément span où le contenu de l'élément suit cette balise jusqu'à ce que < / span > Une balise est rencontrée ou une autre balise (ou EOF) qui ferme implicitement l’élément est rencontrée. dans ce cas, < span / > signifie la même chose que < span >.

De plus: HTML 5 définit à la fois les sérialisations HTML et XHTML. Par conséquent, cela n'affecte pas ce problème d'une manière ou d'une autre. Comme XHTML 1.1, il faut que XHTML soit servi en tant qu'application / xhtml + xml, contrairement à XHTML 1.0. En réalité, cela ne change rien, car tous les navigateurs traitent toute version de XHTML utilisée comme texte / html comme une balise soupe.

Answer 5

Il convient également de noter qu'une déclaration <?xml ...?> avant le doctype jette IE en mode quirks.

Answer 6

Voir la note sur le sujet du groupe de travail XHMTL: http: // www.w3.org/TR/xhtml-media-types/

En bref & # 8212; c'est bien si votre XHTML doit être traité comme XHTML. Si vous prétendez que c'est du HTML (ce que vous devez faire si vous voulez qu'il soit chargé par Internet Explorer (y compris la version 8, la plus récente au moment de la rédaction), vous devez alors sauter d'un panier à l'autre).

Les cerceaux sont suffisamment agaçants pour que je recommande à la plupart des gens de s'en tenir à HTML 4.01.

Answer 7

En règle générale, l'utilisation d'un raccourci pour les éléments vides ne pose pas de problème, mais il existe certaines exceptions où cela peut poser problème.

<script> est un élément important qui doit être fermé avec </script> pour éviter les problèmes.

Un autre est <meta> qui fonctionne beaucoup mieux avec les araignées écrites avec <meta></meta> au lieu de <meta />

Pas exactement la question, mais en ce qui concerne le formatage, les versions d’IE ont des problèmes avec des éléments vides tels que <div></div> ou <div />. Dans ce cas, <div>&nbsp;</div> est requis pour conserver la mise en forme.

Answer 8

Il devrait être explicitement indiqué qu’il n’existe pas de balises à fermeture automatique en HTML. Ainsi, chaque fois qu'un navigateur décide de traiter votre XHTML comme du code HTML, il ne reconnaît pas que la balise est fermée. Pas de problème pour les balises qui n'ont pas besoin d'être fermées en HTML, comme <img>, mais manifestement mauvaises avec des balises comme <span>.