Pourquoi les éléments de script à fermeture automatique ne fonctionnent-ils pas?


1346

Quelle est la raison pour laquelle les navigateurs ne reconnaissent pas correctement:

<script src="foobar.js" /> <!-- self-closing script element -->

Seul cela est reconnu:

<script src="foobar.js"></script>

Cela brise-t-il le concept de prise en charge XHTML?

Remarque: Cette déclaration est correcte au moins pour tous les IE (6-8 beta 2).


12
Works in Chrome and Opera
corymathews

46
Une version récente de Chrome semble avoir rompu cela, les balises de script à fermeture automatique ne fonctionnent plus dans Chrome
Adam Ness

13
Ce ne sont pas seulement des balises de script. Je ne pense pas non plus que les balises div à fermeture automatique fonctionnent.
DOK

6
Depuis juillet 2011, Chrome et Firefox ont ce problème. "Ce n'est pas un bug, c'est une fonctionnalité" - vraiment ennuyeux.
Martin Konicek

4
La version la plus générale a été posée deux jours plus tard: stackoverflow.com/questions/97522/…
Ciro Santilli 郝海东 冠状 病 六四 事件 法轮功

Réponses:


481

La spécification XHTML 1 dit:

С.3. Minimisation des éléments et contenu des éléments vides

Étant donné une instance vide d'un élément dont le modèle de contenu n'est pas EMPTY(par exemple, un titre ou un paragraphe vide), n'utilisez pas la forme minimisée (par exemple, use <p> </p>and not <p />).

La DTD XHTML spécifie les éléments de script comme suit:

<!-- script statements, which may include CDATA sections -->
<!ELEMENT script (#PCDATA)>

111
Pourtant, «ne pas» n'est pas la même chose que «ne doit pas». Il s'agit d'une directive (pour la compatibilité, comme le suggère le titre de la section), pas d'une règle.
Konrad Rudolph

42
En fait, je ne trouve aucune utilité à cette restriction :) Elle semble complètement artificielle.
squadette

22
La bonne réponse a été donnée par olavk. L'Appendice C de XHTML 1.0 n'est pas la raison pour laquelle les choses sont comme elles sont, mais juste comment contourner les choses.
hsivonen

32
Ce n'est pas une partie normative de la spécification. Ce n'est qu'une annexe sur la façon de gérer les navigateurs qui ne prennent pas en charge XHTML
Kornel

12
Le problème <script />n'est pas que la spécification l'interdit, mais que les navigateurs ne l'interprètent pas comme "non-tag-soup" si le type de contenu n'est pas application / xhtml + xml. Voir: stackoverflow.com/questions/348736/… @shabunc: les navigateurs peuvent sembler le comprendre, mais ce qui se passe en réalité, c'est de mettre le contenu après le <p /> à l' intérieur du paragraphe, car l'interprétation de la citation de squadette signifie que depuis < p> n'est pas vide, il ne peut pas se fermer automatiquement. Dans XHTML 1.1, il peut se fermer automatiquement.
Joe

241

Pour ajouter à ce que Brad et squadette ont dit, la syntaxe XML à fermeture automatique est<script /> en fait du XML correct, mais pour que cela fonctionne dans la pratique, votre serveur Web doit également envoyer vos documents en XML correctement formé avec un type de mime XML comme application/xhtml+xmldans le HTTP En-tête Content-Type (et non as text/html).

Cependant, l'envoi d'un type mime XML empêchera l'analyse de vos pages par IE7, qui n'aime que cela text/html.

De w3 :

En résumé, 'application / xhtml + xml' DEVRAIT être utilisé pour les documents de la famille XHTML, et l'utilisation de 'text / html' DEVRAIT être limitée aux documents XHTML 1.0 compatibles HTML. 'application / xml' et 'text / xml' PEUVENT également être utilisés, mais chaque fois que cela est approprié, 'application / xhtml + xml' DEVRAIT être utilisé plutôt que ces types de supports XML génériques.

Je me suis posé la question il y a quelques mois, et la seule solution réalisable (compatible avec FF3 + et IE7) était d'utiliser l'ancienne <script></script>syntaxe avec text/html(syntaxe HTML + type MIME HTML).

Si votre serveur envoie le text/htmltype dans ses en-têtes HTTP, même avec des documents XHTML autrement correctement formés, FF3 + utilisera son mode de rendu HTML ce qui signifie que <script />cela ne fonctionnera pas (ceci est un changement, Firefox était auparavant moins strict).

Cela se produira indépendamment de toute manipulation des http-equivméta-éléments, du prologue ou du doctype XML à l'intérieur de votre document - Firefox se branche une fois qu'il obtient l'en- text/htmltête, qui détermine si l'analyseur HTML ou XML regarde à l'intérieur du document, et l'analyseur HTML ne comprend pas <script />.


3
Est-il correct de conclure que si vous abandonnez la prise en charge d'IE7, l'envoi de texte / xml vous permettra d'obtenir une large prise en charge du navigateur pour <script />?
Chris Moschini

7
Donc, en bref, <script /> ne fonctionnera que si votre type MIME de la page est xhtml / xml. Pour les pages texte / html normales, cela ne fonctionnera pas. ET si nous essayons d'utiliser le type MIME "xhtml / xml", cela cassera la compatibilité IE. Pour résumer, restez calme et utilisez <script> ... </script> Merci Joe ;-)
Navin Israni

1
Excellente explication. Un autre point à noter est que Firefox aura également des .htmlfichiers locaux rendus sous forme de soupe-tag indépendamment des balises META, pour des raisons similaires. Pour les fichiers XHTML, Firefox ne les rendra en conséquence que s'ils sont nommés .xhtml.
alecov

@ChrisMoschini. Probablement, mais n'utilisez application/xhtml+xmlpas text/xml.
TRiG

167

Au cas où quelqu'un serait curieux, la raison ultime est que HTML était à l'origine un dialecte de SGML, qui est le frère aîné étrange de XML. Dans SGML-land, les éléments peuvent être spécifiés dans la DTD comme à fermeture automatique (par exemple BR, HR, INPUT), implicitement fermables (par exemple P, LI, TD) ou explicitement fermables (par exemple TABLE, DIV, SCRIPT). XML, bien sûr, n'a aucune idée de cela.

Les analyseurs tag-soup utilisés par les navigateurs modernes ont évolué à partir de cet héritage, bien que leur modèle d'analyse ne soit plus pur SGML. Et bien sûr, votre XHTML soigneusement conçu est traité comme une soupe de balises d'inspiration SGML mal écrite, sauf si vous l'envoyez avec un type mime XML. C'est aussi pourquoi ...

<p><div>hello</div></p>

... est interprété par le navigateur comme:

<p></p><div>hello</div><p></p>

... qui est la recette d'un joli bug obscur qui peut vous mettre en crise lorsque vous essayez de coder contre le DOM.


4
Je suis curieux. pourquoi le navigateur choisit-il de l'interpréter de cette façon?
Ahmed Aeon Axan

32
@AhmedAeonAxan: L' Pélément ne peut pas contenir d' DIVéléments (ce n'est pas du HTML valide), donc le navigateur ferme implicitement l' Pélément (défini comme " pouvant être fermé implicitement") avant la DIVbalise d' ouverture . Cependant, les navigateurs ont tendance à se comporter différemment à cet égard (comme ils peuvent le faire avec tout HTML non valide).
MrWhite

5
@ColeJohnson Non, ce n'est pas de la soupe tag; Greim brouille la frontière entre HTML valide et invalide. La soupe aux étiquettes est ce que vous obtenez lorsque les auteurs ne se soucient pas des règles, car les navigateurs utilisent la correction d'erreurs. En </p>revanche, une balise de fin manquante fait partie de la définition du HTML!
M. Lister

3
@MrLister - En quelque sorte. "Tag soup" décrit comment le HTML est analysé, pas comment il est créé. C'était un terme utilisé pour décrire les stratégies disparates utilisées par les navigateurs pour donner un sens au HTML, et contraste avec l'analyse syntaxique XML stricte. L'analyse XML n'est autorisée que pour les types MIME XML, mais comme ceux-ci n'ont jamais été largement utilisés, les navigateurs sont revenus à divers schémas de "soupe de balises", même pour des documents par ailleurs valides.
greim

8
HTML5 a en fait normalisé l'analyse de la «soupe de tag», y compris un moyen cohérent de gérer le balisage non valide. Jusque-là, les navigateurs devaient en quelque sorte déterminer quoi faire avec un balisage non valide, ce qui provoquait des incohérences. L'analyseur HTML dans les navigateurs actuels est l'un des logiciels les plus avancés jamais écrits. Extrêmement rapide et peut gérer la plupart des entrées, produisant des résultats cohérents.
Stijn de Witt

161

D'autres ont répondu «comment» et cité des spécifications. Voici la vraie histoire de "pourquoi non <script/>", après de nombreuses heures à fouiller dans les rapports de bogues et les listes de diffusion.


HTML 4

HTML 4 est basé sur SGML .

SGML a quelques shorttags , comme <BR//, <B>text</>, <B/text/ou <OL<LI>item</LI</OL>. XML prend la première forme, redéfinit la fin comme ">" (SGML est flexible), pour qu'il devienne <BR/>.

Cependant, HTML n'a pas redéfini, donc <SCRIPT/> devrait signifier <SCRIPT>> .
(Oui, le «>» doit faire partie du contenu et la balise n'est toujours pas fermée.)

De toute évidence, cela est incompatible avec XHTML et va briser de nombreux sites (les navigateurs temps étaient assez matures pour prendre soin de cette ), de sorte que personne ne shorttags mis en œuvre et la spécification conseille contre eux .

En effet, toutes les balises auto-terminées «en fonctionnement» sont des balises avec une balise de fin interdite sur les analyseurs techniques non conformes et sont en fait invalides. C'est le W3C qui a proposé ce hack pour faciliter la transition vers XHTML en le rendant compatible HTML .

Et <script>la balise de fin n'est pas interdite .

La balise "auto-terminante" est un hack en HTML 4 et n'a aucun sens.


HTML 5

HTML5 a cinq types de balises et seules les balises 'void' et 'foreign' sont autorisées à se fermer automatiquement .

Parce qu'il <script>n'est pas nul (il peut avoir du contenu) et n'est pas étranger (comme MathML ou SVG), <script>ne peut pas être fermé automatiquement, quelle que soit la façon dont vous l'utilisez.

Mais pourquoi? Ne peuvent-ils pas le considérer comme étranger, faire un cas spécial ou quelque chose?

HTML 5 vise à être rétrocompatible avec les implémentations de HTML 4 et XHTML 1. Il n'est pas basé sur SGML ou XML; sa syntaxe concerne principalement la documentation et l'unification des implémentations. (C'est pourquoi <br/> <hr/>etc. sont des HTML 5 valides bien qu'HTML4 non valides.)

La fermeture automatique <script>est l'une des balises où les implémentations différaient. Il travaillait dans Chrome, Safari , et Opera ; à ma connaissance, cela n'a jamais fonctionné dans Internet Explorer ou Firefox.

Cela a été discuté lors de la rédaction de HTML 5 et a été rejeté car il rompt la compatibilité du navigateur . Les pages Web dont la balise de script à fermeture automatique peut ne pas s'afficher correctement (voire pas du tout) dans les anciens navigateurs. Il y avait d' autres propositions , mais elles ne peuvent pas non plus résoudre le problème de compatibilité.

Après la publication du brouillon, WebKit a mis à jour l'analyseur pour qu'il soit conforme.

La fermeture automatique <script>ne se produit pas dans HTML 5 en raison de la compatibilité descendante avec HTML 4 et XHTML 1.


XHTML 1 / XHTML 5

Lorsqu'il est réellement utilisé en tant que XHTML, il <script/>est vraiment fermé, comme l' ont indiqué d' autres réponses .

Sauf que la spécification dit qu'elle aurait dû fonctionner lorsqu'elle a été servie en HTML:

Les documents XHTML ... peuvent être étiquetés avec le type de média Internet "text / html" [RFC2854], car ils sont compatibles avec la plupart des navigateurs HTML.

Alors, qu'est-ce-qu'il s'est passé?

Les gens ont demandé à Mozilla de laisser Firefox analyser les documents conformes au format XHTML indépendamment de l'en-tête de contenu spécifié (connu sous le nom de reniflage de contenu ). Cela aurait permis des scripts à fermeture automatique, et le reniflage de contenu était de toute façon nécessaire parce que les hébergeurs Web n'étaient pas suffisamment matures pour servir l'en-tête correct; IE était bon dans ce domaine .

Si la première guerre des navigateurs ne s'est pas terminée avec IE 6, il se peut que XHTML soit également sur la liste. Mais cela a fini. Et IE 6 a un problème avec XHTML. En fait , IE ne prend pas en charge le type MIME correct du tout , ce qui oblige tout le monde à utiliser text/htmlpour XHTML parce que IE a tenu majeure part de marché pendant toute une décennie.

Et le reniflage de contenu peut également être très mauvais et les gens disent qu'il devrait être arrêté .

Enfin, il s'avère que le W3C ne signifiait pas que le XHTML était sniffable : le document est à la fois HTML et XHTML, et des Content-Typerègles. On peut dire qu'ils étaient fermes sur "suivez simplement nos spécifications" et ignoraient ce qui était pratique . Une erreur qui s'est poursuivie dans les versions XHTML ultérieures.

Quoi qu'il en soit, cette décision a réglé la question pour Firefox. C'était 7 ans avant la naissance de Chrome ; il n'y avait pas d'autre navigateur significatif. Ainsi fut-il décidé.

La spécification du doctype seul ne déclenche pas l'analyse XML en raison des spécifications suivantes.


1
@AndyE Lorsque vous écrivez <script> à fermeture automatique, les principaux navigateurs à ce moment-là ne pensent pas qu'il est fermé et analysera la sous-séquence html en javascript, provoquant une rupture HTML5 valide sur ces anciens navigateurs. La proposition est donc rejetée. Ceci est expliqué dans la liste de diffusion HTML5 liée.
Sheepy

2
@AndyE: Ce que vous décrivez est la compatibilité ascendante - la capacité de l'ancien code à fonctionner avec un nouveau compilateur / interprète / analyseur. La compatibilité descendante est la capacité du nouveau code à fonctionner avec l'ancien compilateur / interprète / analyseur. Alors oui, la compatibilité descendante était le problème car sinon les pages écrites avec la nouvelle spécification à l'esprit ne fonctionneraient pas dans les anciens navigateurs (et oui, c'est une tradition de programmation Web pour essayer de faire fonctionner le nouveau code dans les anciens navigateurs autant que possible).
slebetman

3
@Dmitry La réalité est, interdire le script auto-fermé est une rue à sens unique. Comme lié , le <script> auto-fermé cassera tous les navigateurs, les utilisateurs verront simplement une page vierge - consoles de jeux, Internet TV, IE 11 sur le nouveau PC Win7 d'entreprise, des millions d' exécutions Java ou des milliards de smartphones. Pouvez-vous mettre à niveau la plupart de WebView de la plupart des langues sur la plupart des appareils? Si HTML5 avait essayé, ils auraient échoué comme XHTML2.
Sheepy

6
réponse très sous-estimée
Kamil Tomšík

2
Un peu de correction: les balises qui semblent fonctionner comme fermées automatiquement en HTML ne sont pas celles avec des balises de fin facultatives , mais celles avec des balises de fin interdites (balises vides ou nulles). Les balises avec des balises de fin facultatives , comme <p>ou <li>, ne peuvent pas être «auto-fermées» car elles peuvent avoir du contenu, donc le code comme <p/>n'est rien de plus qu'une balise de début (malformée) et le contenu après, s'il est autorisé dans cet élément , finirait à l'intérieur.
Ilya Streltsyn

44

Internet Explorer 8 et versions antérieures ne prennent pas en charge l'analyse XHTML. Même si vous utilisez une déclaration XML et / ou un doctype XHTML, l'ancien IE analyse toujours le document en HTML simple. Et en clair HTML, la syntaxe à fermeture automatique n'est pas prise en charge. La barre oblique de fin est simplement ignorée, vous devez utiliser une balise de fermeture explicite.

Même les navigateurs prenant en charge l'analyse XHTML, tels qu'IE 9 et versions ultérieures , analyseront toujours le document au format HTML, sauf si vous le diffusez avec un type de contenu XML. Mais dans ce cas, l'ancien IE n'affichera pas du tout le document!


9
"IE ne prend pas en charge l'analyse XHTML." était vrai pour les versions IE au moment où cela a été écrit, mais n'est plus vrai.
EricLaw

@EricLaw pouvez-vous clarifier quelle version d'IE a résolu ce problème? (et toute condition spécifique - par exemple un doctype valide requis)
scunliffe

2
@scunliffe IE9 était la première version avec prise en charge complète de XHTML. blogs.msdn.com/b/ie/archive/2010/11/01/…
EricLaw

28

Les personnes ci-dessus ont déjà à peu près expliqué le problème, mais une chose qui pourrait clarifier les choses est que, bien que les gens utilisent <br/>et tels tout le temps dans les documents HTML, tout /dans une telle position est fondamentalement ignoré, et uniquement utilisé lorsque vous essayez de faire quelque chose à la fois analysable en XML et HTML. Essayez <p/>foo</p>, par exemple, et vous obtenez un paragraphe régulier.


22

La balise de script à fermeture automatique ne fonctionnera pas, car la balise de script peut contenir du code en ligne, et HTML n'est pas assez intelligent pour activer ou désactiver cette fonctionnalité en fonction de la présence d'un attribut.

D'un autre côté, HTML a une excellente balise pour inclure des références à des ressources externes: la <link>balise, et elle peut se fermer automatiquement. Il est déjà utilisé pour inclure des feuilles de style, des flux RSS et Atom, des URI canoniques et toutes sortes d'autres goodies. Pourquoi pas JavaScript?

Si vous voulez que la balise de script soit incluse, vous ne pouvez pas le faire comme je l'ai dit, mais il existe une alternative, mais pas intelligente. Vous pouvez utiliser la balise de lien à fermeture automatique et le lien vers votre JavaScript en lui donnant un type de texte / javascript et rel comme script, quelque chose comme ci-dessous:

<link type="text/javascript" rel ="script" href="/path/tp/javascript" />

4
J'aime ça, pourquoi n'est-ce pas "intelligent"?
Josh M.

5
Parce qu'il existe une balise de script prédéfinie pour effectuer exactement le travail de chargement d'un script. Pourquoi confondriez-vous les choses en utilisant autre chose? Un marteau martèle dans les ongles. Serait-il judicieux d'utiliser une chaussure?
Dave Lawrence

8
@daveL - Et nous avons des <style>balises, mais utilisons des balises de lien pour les fichiers CSS externes. Définition de la balise de lien: "La balise <link> définit un lien entre un document et une ressource externe." Semble parfaitement logique que la balise de lien soit utilisée pour du CSS ou du JS externe ... c'est à cela qu'elle sert ... pour lier des fichiers externes. note je ne parle pas de spec / cross-Browserness / etc, je commente simplement la nature logique de l'utilisation de balises de lien pour apporter à la fois CSS et JS ... cela aurait en fait beaucoup de sens si c'était le cas. . Je ne sais pas si la chaussure [analogie] convient.
Jimbo Jonny

20

Contrairement à XML et XHTML, HTML n'a aucune connaissance de la syntaxe à fermeture automatique. Les navigateurs qui interprètent XHTML comme HTML ne savent pas que le /caractère indique que la balise doit se fermer automatiquement; au lieu de cela, ils l'interprètent comme un attribut vide et l'analyseur pense toujours que la balise est «ouverte».

Tout comme <script defer>est traité comme <script defer="defer">, <script />est traité comme <script /="/">.


33
Aussi élégante que soit cette explication, elle est en fait fausse. Si c'était vrai, il y aurait un attribut "/" pour l'élément de script dans le DOM. J'ai vérifié IE, Firefox et Opera, et aucun d'entre eux ne contient réellement un tel attribut.
Alohci

11
/ n'est pas un caractère de nom d'attribut valide, il est donc supprimé. Sinon, cette explication est assez claire.
hallvors - restaurer Monica

1
En fait, certains analyseurs HTML (et en particulier les validateurs) peuvent interpréter le /comme faisant partie de la construction NET (Null End Tag).
IllidanS4 veut que Monica revienne

18

Internet Explorer 8 et plus ne supportent pas le type MIME approprié pour XHTML, application/xhtml+xml. Si vous utilisez XHTML as text/html, ce que vous devez faire pour que ces anciennes versions d'Internet Explorer fassent quoi que ce soit, il sera interprété comme HTML 4.01. Vous ne pouvez utiliser la syntaxe courte qu'avec n'importe quel élément permettant d'omettre la balise de fermeture. Voir la spécification HTML 4.01 .

La «forme courte» XML est interprétée comme un attribut nommé /, qui (parce qu'il n'y a pas de signe égal) est interprété comme ayant une valeur implicite de «/». C'est strictement faux en HTML 4.01 - les attributs non déclarés ne sont pas autorisés - mais les navigateurs l'ignoreront.

IE9 et versions ultérieures prennent en charge XHTML 5 avec application/xhtml+xml.


IE 9 prend en charge XHTML et IE n'est plus> 51%. Pourriez-vous mettre à jour votre réponse?
Damian Yerrick

5

C'est parce que SCRIPT TAG n'est pas un élément vide.

Dans un document HTML - LES ÉLÉMENTS NULS ne besoin d'une "balise de fermeture"!

En xhtml , tout est générique, donc ils ont tous besoin d'une terminaison, par exemple une "balise de fermeture"; Y compris br, un simple saut de ligne, comme <br></br>ou sa sténographie <br /> .

Cependant, un élément de script n'est jamais un élément vide ou paramétrique, car la balise de script avant toute chose est une instruction de navigateur et non une déclaration de description de données.

Principalement, une instruction de terminaison sémantique, par exemple, une "balise de fermeture" n'est nécessaire que pour traiter des instructions dont la sémantique ne peut pas être terminée par une balise suivante. Par exemple:

<H1>la sémantique ne peut pas être terminée par un suivant <P>car elle ne contient pas suffisamment de sa propre sémantique pour remplacer et donc terminer le jeu d'instructions H1 précédent. Bien qu'il puisse diviser le flux en une nouvelle ligne de paragraphe, il n'est pas "suffisamment fort" pour remplacer la taille de police et la hauteur de ligne de style actuelles qui se déversent dans le flux. , c'est-à-dire qui fuient de H1 (car P ne l'a pas) ).

C'est ainsi et pourquoi la signalisation "/" (terminaison) a été inventée.

Une balise de terminaison générique sans description comme < />, aurait suffi pour toute chute unique de la cascade rencontrée, par exemple: <H1>Title< />mais ce n'est pas toujours le cas, parce que nous voulons également être capables de «s'emboîter», plusieurs balisage intermédiaire du Stream: split en torrents avant de s'enrouler / tomber sur une autre cascade. En conséquence, un terminateur générique tel que < />ne serait pas en mesure de déterminer la cible d'une propriété à terminer. Par exemple: <b>gras <i>gras-italique < /> italique </> normal. Serait sans doute de ne pas obtenir notre droit d'intention et ne plus interpréter probablement comme gras gras-itallic gras normal.

C'est ainsi qu'est née la notion de wrapper, c'est-à-dire de conteneur. (Ces notions sont tellement similaires qu'il est impossible de les discerner et parfois le même élément peut avoir les deux. <H1>Est à la fois wrapper et container en même temps. Alors que <B>seul un wrapper sémantique). Nous aurons besoin d'un conteneur simple et sans sémantique. Et bien sûr, l'invention d'un élément DIV est arrivée.

L'élément DIV est en fait un conteneur 2BR. Bien sûr, l'arrivée de CSS a rendu la situation plus étrange qu'elle ne l'aurait été autrement et a provoqué une grande confusion avec de nombreuses grandes conséquences - indirectement!

Parce qu'avec CSS, vous pouvez facilement remplacer le comportement natif pré et après BR d'un DIV nouvellement inventé, il est souvent appelé «conteneur de ne rien faire». Ce qui est naturellement faux! Les DIV sont des éléments de bloc et coupent nativement la ligne du flux à la fois avant et après la signalisation de fin. Bientôt, le WEB a commencé à souffrir de la page DIV-itis. La plupart d'entre eux le sont toujours.

L'arrivée de CSS avec sa capacité à remplacer et à redéfinir complètement le comportement natif de toute balise HTML, a en quelque sorte réussi à confondre et à brouiller tout le sens de l'existence HTML ...

Soudain, toutes les balises HTML sont apparues comme obsolètes, elles ont été effacées, dépouillées de toute leur signification, identité et finalité d'origine. D'une certaine manière, vous auriez l'impression qu'ils ne sont plus nécessaires. Dire: une seule balise wrapper de conteneur suffirait pour toute la présentation des données. Ajoutez simplement les attributs requis. Pourquoi ne pas avoir des balises significatives à la place; Inventez les noms de balises au fur et à mesure et laissez le CSS s'occuper du reste.

C'est ainsi que le xhtml est né et bien sûr le grand émoussé, payé si cher par les nouveaux arrivants et une vision déformée de ce qui est quoi, et quel est le fichu but de tout cela. Le W3C est passé du World Wide Web à What Wong Wrong, Camarades? !!

Le but du HTML est de diffuser des données significatives au destinataire humain.

Pour fournir des informations.

La partie formelle n'est là que pour aider à la clarté de la livraison de l'information. xhtml ne donne pas la moindre considération à l'information. - Pour lui, l'information est absolument hors de propos.

La chose la plus importante en la matière est de savoir et de pouvoir comprendre que xhtml n'est pas seulement une version de HTML étendu , xhtml est une bête complètement différente; motifs vers le haut; et donc il est sage de les garder séparés.


3

La différence entre «vrai XHTML», «faux XHTML» et HTML ainsi que l'importance du type MIME envoyé par le serveur avaient déjà été bien décrites ici . Si vous souhaitez l'essayer dès maintenant, voici un simple extrait modifiable avec aperçu en direct, y compris une balise de script auto-fermée pour les navigateurs capables:

div { display: flex; }
div + div {flex-direction: column; }
<div>Mime type: <label><input type="radio" onchange="t.onkeyup()" id="x" checked  name="mime"> application/xhtml+xml</label>
<label><input type="radio" onchange="t.onkeyup()" name="mime"> text/html</label></div>
<div><textarea id="t" rows="4" 
onkeyup="i.src='data:'+(x.checked?'application/xhtml+xml':'text/html')+','+encodeURIComponent(t.value)"
><?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"
[<!ENTITY x "true XHTML">]>
<html xmlns="http://www.w3.org/1999/xhtml">
<body>
  <p>
    <span id="greet" swapto="Hello">Hell, NO :(</span> &x;.
    <script src="data:text/javascript,(g=document.getElementById('greet')).innerText=g.getAttribute('swapto')" />
    Nice to meet you!
    <!-- 
      Previous text node and all further content falls into SCRIPT element content in text/html mode, so is not rendered. Because no end script tag is found, no script runs in text/html
    -->
  </p>
</body>
</html></textarea>

<iframe id="i" height="80"></iframe>

<script>t.onkeyup()</script>
</div>

Vous devriez voir Hello, true XHTML. Nice to meet you!ci - dessous la zone de texte.

Pour les navigateurs incapables, vous pouvez copier le contenu de la zone de texte et l'enregistrer sous forme de fichier avec .xhtml(ou .xht) l'extension ( merci Alek pour cet indice ).


En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.