Compatibilité des explorateurs d'Internet
1. Résumé
Cet article décrit les caractéristiques de Internet Explorer (IE) Gestion des attributs et balises HTML personnalisés (qui peuvent être compris comme des "propriétés spécialement mauvaises"). Si nous prévoyons de rendre l'application compatible avec IE8 et ci-dessous, nous pouvons continuer à lire.
2. Version courte (brève description)
Pour faire fonctionner notre application angulaire sur IE, assurez-vous:
1. Présentez JSON.Stringify au besoin (IE7 ou ci-dessous nécessite cette chose). Nous pouvons utiliser JSON2 (https://github.com/douglascrockford/json-js) ou json3 (http://bestiejs.github.com/json3/).
2. N'utilisez pas de balises personnalisées telles que <ng: View> (Remplacer par des versions d'attribut, telles que <div ng-view>). Si vous souhaitez toujours l'utiliser, veuillez consulter le point 3.
3. Si vous souhaitez vraiment utiliser des balises personnalisées, vous devez effectuer les étapes suivantes pour informer l'ancien IE de vos balises personnalisées.
<html xmlns: ng = "http://angularjs.org"> <éad- head> <! - [if lte ie 8]> <script> document.createelement ('ng-include'); Document.CreateElement («ng-pleuralize»); Document.CreateElement ('ng-View'); // éventuellement ceux-ci pour CSS Document.CreateElement ('ng: inclure'); Document.CreateElement («Ng: Pluralize»); Document.CreateElement ('ng: View'); </script> <! [endif] -> </ head> <body> ... </ body> </html>Ce qui a besoin d'attention est:
XMLS: NG - Espace de noms - Pour chaque balise personnalisée que nous prévoyons d'utiliser, il doit y avoir un espace de noms.
Document.CreateElement ("Nom de la balise personnalisée") - Création du nom de la balise personnalisée - Parce que c'est un problème avec l'ancienne version IE, nous devons le gérer spécialement par le biais de commentaires de jugement IE (<! - [Si LTE IE 8]>… <! [Endif] ->). Pour chaque balise sans espace de noms ou par défaut non-HTML, ce type de prédéfini est requis pour que IE ne soit pas stupide (par exemple, pas de style ...).
3. Version longue (détails)
IE a des problèmes avec la gestion des balises HTML non standard. Cela peut avoir à peu près deux types d'atmosphère (avec et sans espaces de noms), et chaque catégorie a sa propre solution.
Si le nom de balise commence par "My:", il sera considéré comme l'espace de noms, et une définition de l'espace de noms correspondant doit être définie (<html xmlns: my = "ignore">).
Si la balise n'a pas d'espace de noms (à commencer par xx :) mais n'est pas un HTML standard, il doit être déclaré via Document.CreateElement ("Nom de balise").
Si nous prévoyons de définir des styles pour les balises personnalisées, nous devons utiliser Document.CreateElement ("Nom de balise") pour le personnaliser, quel que soit l'espace de noms XML (prouve expérimentalement que la signification de l'espace de noms XML est très probable: pas besoin de se soucier des balises personnalisées avec l'espace de noms).
4. La bonne nouvelle
La bonne nouvelle est que cette restriction est uniquement pour les noms d'élément et n'a aucun effet sur les noms d'attributs. Par conséquent, il n'est pas nécessaire de faire un traitement spécial pour les propriétés personnalisées (<div> my-tag your: tag> </div>).
5. Que se passe-t-il si je ne fais pas cela? (Que se passera-t-il si vous ne faites pas ces traitements ?!)
Supposons que nous ayons une balise HTML non standard (le même résultat est pour mon: tag ou my-tag. Mais après les tests, nous avons constaté que la méthode de l'espace de noms n'aurait pas une telle gêne).
<html> <body> <mytag> du texte </ mytag> </ body> </html>
D'une manière générale, il sera converti à la structure DOM suivante:
#Document + - HTML + - Body + - MyTag + - #Text: un texte
Ce que nous attendons, c'est que l'élément corporel a un élément enfant MyTag, et le mytag a un élément enfant de texte "du texte".
Mais IE ne fait pas cela (si des mesures correctives sont prises, elle ne sera pas incluse)!
#Document + - HTML + - Body + - Mytag + - #Text: un peu de texte + - / mytag
Dans IE, le corps aura 3 éléments enfants:
1. Un "Mytag" autoposé, similaire à <br/>. Le "/" à la fin est facultatif, mais la balise <br> n'autorise aucun élément enfant, donc le navigateur le divise en trois éléments frères, au lieu des éléments individuels <br> contenant des éléments de texte.
2. Un nœud de texte "du texte". Cela aurait dû être un enfant de l'élément MyTag, pas son nœud frères.
3. Une balise d'auto-fermage incorrecte "/ mytag" dit que c'est mal parce que le nom de l'élément ne permet pas le caractère "/" (il devrait être autorisé à la fin <br/>). De plus, l'élément fermé ne doit pas faire partie du DOM (il ne doit pas apparaître sous forme d'élément) car il est utilisé uniquement comme limite pour décrire la structure DOM.
6. Style CSS des noms de balises personnalisés (définition de style CSS pour les balises personnalisées)
Si vous souhaitez que le sélecteur CSS soit valide pour les éléments personnalisés, les éléments personnalisés doivent être prédéfinis via Document.CreateElement ("Nom de l'élément"), quel que soit l'espace de noms XML (prouve expérimentalement qu'il n'est pas nécessaire de s'inquiéter de l'espace de noms XML ici ?!)
Voici un exemple de définition de style de balise personnalisé:
<! Doctype html> <html xmlns: ng = "nécessaire pour ng: namespace"> <éad> <ititle> ie compatibilité </title> <! - [if lte ie 8]> <script> // nécessaire pour faire ng-include parse correctement document.createelement ('ng-include'); // nécessaire pour activer le document de référence CSS. ! </ script> <! [endif] -> <style> ng /: View {display: block; Border: 1px rouge solide; Largeur: 100px; hauteur: 100px; } ng-include {display: block; Border: 1px bleu massif; Largeur: 100px; hauteur: 100px; } </ style> </ head> <body> <ng: View> </ng: View> <ng-include> </ng-include> </ody> </html>