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 est-ce que Firefox) va transformer certains de mes <span class="presentational"></span> into <span class="presentational" />

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

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

Je vous remercie

Answer 1

Je suppose que votre question a à voir avec le rouge slash sur l'auto-éléments de fermeture lorsque vous afficher la source dans Firefox. Si oui, vous avez trébuché dans l'un des plus véhéments, mais en même temps le comportement passif-agressif débats dans le navigateur maker vs développeur web guerres. XHTML n'est PAS seulement un document de balisage. C'est aussi sur la façon dont les documents sont destinés à être diffusé sur le web.

Avant que je ne commence; je suis en train dur de ne pas prendre parti ici.

Le XHTML 1.1 spécification dit qu'un serveur web devrait servir XHTML avec un Type de Contenu application/xhtml+xml. Firefox est de distinguer ces barres obliques comme invalide parce que votre document est en train d'être servi en tant que texte/html plutôt que application/xhtml+xml. Prendre que ces deux exemples; identique de balisage, on a servi en tant que application/xhtml+xml, l'autre en tant que text/html.

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

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

Firefox drapeaux le slash dans la balise meta comme non valide pour le document a servi avec le texte/html, et est valable pour le document a servi avec l'application/xhtml+xml.

Pourquoi cela est Controversé

Pour un navigateur développeur, le point de XHTML est que vous pouvez traiter votre document au format XML, ce qui signifie que si quelqu'un vous envoie quelque chose qui n'est pas valide, la spec dit que vous n'avez pas à l'analyser. Donc, si un document est signifié en application/xhtml+xml et non un contenu bien formé, le développeur a le droit de le dire "n'est pas mon problème". Vous pouvez voir en action ici

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

Lorsqu'un document est signifié en tant que text/html, Firefox traite comme un simple vieux document HTML et utilise le pardonneur, le corriger pour vous, des routines d'analyse

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

Donc, à un navigateur maker, XHTML servi en tant que text/html est ridicule, car il n'est jamais traitée comme XML par le navigateur du moteur de rendu.

Un tas d'années, les développeurs web à la recherche de plus de balise singes (Disclaimer: je le fais moi-même en tant que l'un d'entre eux) ont commencé à chercher des moyens de développer les meilleures pratiques qui n'ont pas participé trois fois tables imbriquées, mais encore permis à un design convaincant de l'expérience. Ils/Nous verrouillé sur le XHTML/CSS, parce que le W3C a dit que c'était l'avenir, et le seul autre choix est un monde où un seul vendeur (Microsoft) contrôlés defacto balisage spec. Le mal réel qu'il soit le seul fournisseur, et pas tellement de Microsoft. Je le jure.

Alors où est la polémique? Il y a deux problèmes avec l'application/xhtml+xml. La première est Internet Explorer. Il y a un héritage bug/feature dans IE où le contenu a servi en tant que application/xhtml+xml invite l'utilisateur à télécharger le document. Si vous avez essayé de visiter le xhtml-as-xhtml.php ci-dessus avec IE c'est probablement ce qui s'est passé. Cela signifie que si vous voulez utiliser l'application/xhtml+xml, vous devez navigateur sniff pour IE, vérifier l'Accepte d'en-tête et qui ne servent application/xhtml+xml pour les navigateurs qui l'acceptent. Ce n'est pas aussi anodin qu'il y paraît pour obtenir le droit, et s'est également rendue à l'encontre de la "écrire une fois" principe que les développeurs web sont battus pour.

Le deuxième problème est la dureté de XML. C'est, encore une fois, l'un de ceux de la flamme sujettes à des problèmes, mais il y a certaines personnes qui pensent qu'un simple mauvais tag, ou à caractère unique mal codés ne devrait pas permettre à un utilisateur de ne pas voir le document qu'ils veulent. En d'autres termes, oui, la spec dit que vous devriez arrêter de traitement XML si ce n'est pas bien formé, mais l'utilisateur ne se soucie pas de la spec, ils se soucient que de leur chat site est cassé.

En ajoutant encore plus de l'essence de la question est le XHTML 1.0 (1.1) spécification dit que les documents XHTML peut être servi en tant que text/html, en supposant que certaines compatibilité des directives sont suivies. Des choses comme la balise img être à fermeture automatique et la comme. Le mot clé ici est peut. Dans la RFC parler, peut signifie en option. Firefox a choisi de ne PAS traiter les documents servi avec un doctype XHTML, mais un type de contenu text/html au XHTML. Cependant, le validateur du W3C sera heureux de signaler ces documents comme valide.

Je vais laisser le lecteur à réfléchir à la simultanée merveille/horreur d'une culture qui écrit un document de définir ce qu'ils entendent par le mot peut.

Aller De L'Avant

Enfin, c'est ce que tout le HTML 5 chose est sur. XHTML est devenue une telle politique de la patate chaude qu'un tas de gens qui voulaient aller de la langue vers l'avant a décidé d'aller dans une autre direction. Ils ont produit une spécification HTML 5. C'est actuellement haché dans le W3C, et devraient se terminer dans le courant de la prochaine décennie. Dans l'intervalle, les vendeurs de navigateur sont la cueillette et le choix des caractéristiques de l'en-cours spec et leur mise en œuvre.

Les mises à jour à partir des Commentaires

Dans les commentaires, Alex points que si vous allez à renifler pour quelque chose, vous devez vérifier l'en-tête Accept pour voir si l'application/xhtml+xml est accepté par l'agent utilisateur.

Ce qui est absolument correcte. En général, si vous allez sniff, sniff, pas pour le navigateur.

Answer 2

Un plus pour les autres réponses: par exemple, avoir des éléments tels que l' <span /> dans votre mark-up va causer toutes sortes de problèmes avec le DOM de la traversée des méthodes en JavaScript. Jetez un oeil à la suite de document XHTML:

<?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 lorsque la page se charge, le JavaScript obtenir une référence à vide durée et afficher son contenu HTML. Qui sera une chaîne vide, non? Pas sous IE ça ne marche pas. Dans IE, vous obtenez tout le contenu après la durée de l'ensemble du document:

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

Aussi, le deuxième <p> s'affiche dans la durée de l' childNodes de la collecte. Même <p> est également dans le corps de l' childNodes de la collecte, de la signification d'un nœud peut effectivement avoir plusieurs parents. Ce n'est pas très bonne nouvelle pour les scripts qui s'appuient sur la traversée de la DOM.

J'ai également écrit un billet au sujet de cette.

Answer 3

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

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

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

Answer 4

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

Servi en tant que text/html, < / span> signifie créer un élément span où le contenu de l'élément suivre cette balise jusqu'à ce que le </span> balise est rencontré, ou une autre balise (ou EOF) qui, implicitement, ferme l'élément est rencontré. c'est à dire dans ce cas < / span> signifie la même chose que <span>.

De côté: HTML 5 définit à la fois et le HTML et le XHTML serializations, de sorte qu'il n'affecte pas ce problème d'une façon ou d'une autre. Il nécessite, comme XHTML 1.1, que XHTML être servi en tant que application/xhtml+xml, contrairement XHTML 1.0. En effet, si, cela ne change rien que tous les navigateurs traiter n'importe quelle version de XHTML servi en tant que text/html comme la soupe de tags.

Answer 5

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

En bref - c'est très bien si votre XHTML va être traités comme XHTML. Si vous allez faire semblant c'est du HTML (que vous devez faire si vous voulez être chargé par Internet Explorer (y compris la version 8, au plus tard au moment de l'écriture), alors vous devez sauter à travers des cerceaux).

Les cerceaux sont suffisamment ennuyeux que je recommanderais la plupart des personnes s'en HTML 4.01.