puisque IE ne rendra pas XHTML comme XHTML, mais le traiter comme HTML à la place, quand est-ce que cela peut réellement causer des problèmes pour IE?quand XHTML peut provoquer de manière inattendue des problèmes sur IE?
Je connais un cas où
<div style="clear:both" />
dans les navigateurs qui prennent en charge XHTML, la div est fermée. Mais IE traitera la div comme étant toujours ouverte, de sorte que la mise en page peut avoir des résultats inattendus plus tard.
Internet Explorer aura du mal à distinguer les documents XHTML des documents XML si le type MIME n'est pas spécifié en tant que text/html. Cependant, étant donné qu'il prend entièrement en charge HTML 4.01, la majorité des problèmes proviennent d'implémentations incohérentes et non standard de positionnement, de mise en page et de propriétés CSS. Pour éviter tout problème, il est préférable d'écrire un XHTML valide et de spécifier un DOCTYPE.
L'écriture HTML évite plus de problèmes, puisque vous ne vous en faites pas
Ces toutes appliquent à tout navigateur traitement XHTML comme text/html plutôt que spécifiquement IE, mais vous devriez lire l'annexe C de la spécification XHTML 1.0 ici: http://www.w3.org/TR/xhtml1/#guidelines
fermeture automatique la syntaxe ne fonctionnera pas (elle semblera fonctionner uniquement sur les éléments qui sont toujours vides en HTML). Les sérialiseurs XML peuvent générer <textarea/>, <script/> et similaires, ce qui casse les pages de diverses manières (en déclenchant une récupération d'erreur compliquée, impliquant parfois une ré-analyse du reste de la page).
Les éléments HTML "vides" explicitement fermés peuvent se comporter bizarrement (</br> insère une rupture dans IE).
<![CDATA[ Les éléments CDATA codés en dur en dehors du code HTML seront reconnus en tant que balise. Cela n'affectera pas l'échappement et pourrait faire disparaître du contenu.
Dans les éléments CDATA du code HTML (à savoir <script>), les entités ne seront pas reconnues. XHTML nécessite <script> if (1 < 2) … qui va être une erreur de syntaxe dans IE.
L'arrière-plan de <body> sera appliqué différemment dans IE.
Il n'y aura pas de syntaxe multi-navigateur pour les sélecteurs de l'espace de noms en CSS. Vous obtiendrez tous les éléments HTML implicites (eg <tbody> dans toutes les tables) et les éléments implicitement fermés (ce n'est généralement pas un problème quand le document est valide, mais les autres navigateurs ne vous avertiront pas tant que le balisage est bien formé).
Les éléments et les attributs avec préfixes ne seront pas espacés et auront des différences tagName dans IE (ce qui est également illégal en XML). Ils n'obtiendront pas le style et le comportement par défaut appropriés (<xhtml:a> ne peut pas être un lien).
Vous ne serez pas en mesure d'utiliser des méthodes sensibles au espace de noms comme createElementNS (ils n'existent pas dans IE), .tagName sera en majuscule dans IE, mais pas dans tous les cas.
Les éléments et attributs avec des préfixes ne seront pas espacés et auront un nom local différent dans IE (ce qui est également illégal dans XML).
Ce ne sont que des problèmes concernant le passage du document XML de travail au HTML. Il y a autant de surprises lorsque vous passez du HTML (c'est-à-dire ce que tout le monde attend et prend comme un comportement normal) à du XML réel, par ex. document.write ne fonctionne pas, rendant la plupart des scripts de Google inutiles.
Tous les navigateurs devraient le faire lors du rendu de XHTML en mode HTML - les balises à fermeture automatique sont une caractéristique de XML, pas XHTML. C'est pourquoi les directives de compatibilité HTML recommandent de ne pas utiliser ce formulaire pour les éléments qui ne se ferment normalement pas en HTML (comme![]()
et
): http://www.w3.org/TR/xhtml1/#C_3 – Miles
@ Miles True. IIRC, dans les balises xHTML à fermeture automatique devrait être fermé correctement comme ceci "![]()
" - l'espace est facultatif, mais une sécurité intégrée pour les navigateurs qui ne supportent pas la barre oblique –
hannson