Quels problèmes de navigateur croisés avez-vous rencontrés?
Lors du développement pour plusieurs ensembles de navigateurs, quels problèmes avez-vous rencontrés lors du développement en raison de différences dans la mise en œuvre du navigateur?
Pour commencer, j'énumère certains de ceux auxquels j'ai été confronté:
- Un nœud de texte dans Firefox autorise uniquement les données 4K. Ainsi, une réponse XML Ajax est divisée en plusieurs nœuds enfants texte au lieu d'un seul nœud. C'est bien dans Internet Explorer. Pour Firefox, pour obtenir les données complètes, vous devez soit utiliser node.normalize avant d'appeler node.firstChild ou utiliser node.textContent, deux méthodes spécifiques à Mozilla
- Internet Explorer ne remplace pas
ou code de caractère HTML 160, vous devez remplacer son équivalent Unicode\u00a0 - Dans Firefox, un champ de saisie créé dynamiquement dans un formulaire (créé à l'aide de document.createElement) ne transmet pas sa valeur lors de la soumission du formulaire.
- document.getElementById dans Internet Explorer retournera un élément même si le nom de l'élément correspond. Mozilla ne renvoie l'élément que si id correspond.
- Dans Internet Explorer, si une zone de sélection a une valeur qui n'est représentée par aucune des options, elle s'affiche vide, Firefox affiche la première option.
La plupart des problèmes que j'ai sont avec IE, spécifiquement IE6. Les problèmes que je traite personnellement ont laissé une impression mémorable (sans ordre particulier):
Devoir utiliser des frameworks pour faire des choses basiques car chaque navigateur implémente le DOM un peu différemment. Ceci est particulièrement odieux avec IE et AJAX, ce qui nécessite plusieurs blocs if juste pour démarrer l'appel. Dans un monde idéal, je serais capable de travailler en JavaScript sans le framework pour faire des choses basiques.
onChange sur les sélections dans IE sont implémentées incorrectement et se déclenchent avant que la sélection ne perde le focus (ce qui est incorrect). Cela signifie que vous ne pouvez jamais utiliser onChange avec des sélections en raison d'IE, car les utilisateurs utilisant uniquement le clavier seront paralysés par ce problème d'implémentation.
Vous l'avez mentionné dans votre message, mais c'est une énorme douleur lorsque IE saisit un élément par son nom lors de l'utilisation de getElementBy Id ().
Dans un environnement RTL (arabe, hébreu, etc.), Firefox implémente "text-align: right;" incorrectement. Si le conteneur déborde pour une raison quelconque, le texte s'aligne sur le côté droit du conteneur visible, plutôt que sur le côté droit du conteneur lui-même (même s'il en rend une partie invisible).
Différents navigateurs ont différents niveaux de préparation en ce qui concerne la façon dont vous mettez fin aux tableaux et aux objets. Par exemple, Firefox est plus que correct avec un tableau ressemblant à ceci: [item0, item1,] ". Cependant, ce même code fera Opera barf parce qu'il déteste la virgule de fin. IE fera du tableau un tableau à trois éléments, le troisième élément étant indéfini! C'est certainement du mauvais code, mais il y a eu du javascript généré dynamiquement sur lequel j'ai travaillé qui a été très difficile à réécrire - cela aurait été bien si cela a juste fonctionné.
Tout ce qui concerne les IE hasLayout . Tant de douleurs terribles ont tourné autour de cet attribut, surtout quand je ne savais pas qu'il existait. Tant de problèmes résolus en utilisant des hacks pour ajouter hasLayout. Beaucoup plus de problèmes créés à la suite des hacks.
Les flotteurs dans IE fonctionnent rarement comme vous l'espérez. Ils ont également tendance à être ennuyeux dans d'autres navigateurs, mais ils se conforment au moins à un comportement particulier. ;)
IE ajouter espace blanc supplémentaire entre les éléments de la liste ne m'a pas causé de douleur, car YUI utilise des listes pour créer leurs menus. (Pour bien comprendre le problème, vous devez afficher ce lien dans IE et un autre navigateur côte à côte.)
J'ai beaucoup de problèmes pour que le texte ne soit pas enveloppé dans des conteneurs dans IE. D'autres navigateurs écoutent beaucoup mieux "white-space: nowrap". Cela a été un problème avec une interface utilisateur sur laquelle j'ai travaillé qui a une barre latérale redimensionnable; dans IE, les éléments de la barre latérale commenceront à se terminer si vous le redimensionnez trop.
L'absence de nombreux types de sélecteurs CSS dans IE6 signifie que vous devez classer votre DOM plus que nécessaire. Par exemple, le manque de +,: hover,: first-child.
Différents navigateurs traitent différemment les nœuds de texte vides. Plus précisément, lors de la traversée du DOM avec Opera, je dois m'inquiéter des nœuds de texte vides lors de la navigation sur les enfants d'un nœud. Ce n'est pas un problème si vous recherchez un élément particulier, mais c'est si vous écrivez du code qui attend une entrée particulière et la façon dont le navigateur voit cette entrée diffère.
Dans IE6, lorsque vous générez dynamiquement un iframe via javascript, l'iframe ne remplit parfois pas automatiquement son conteneur (même avec une largeur et une hauteur définies sur max). Je ne sais toujours pas comment résoudre ce problème et j'ai pensé à poster une question à ce sujet.
Dans IE, vous ne pouvez pas définir de CSS de débordement sur l'élément <tbody>. Cela signifie que les tableaux déroulants (avec un <thead> et un <tfoot> concrets) sont impossibles à créer de manière simple.
J'ajouterai probablement plus à cette liste plus tard, car (pour moi) la pire partie du développement Web sont des problèmes de navigateur. De plus, je doute que j'éditerai un jour le "J'ajouterai probablement plus à cette liste plus tard", car ces problèmes sont infinis. :)
Le seul qui vraiment me parvienne:
- IE6 est toujours utilisé par environ 18% du Web - c'est près de 1 sur 5 - et résoudre ses problèmes prend du temps, est piraté et frustrant. ;) Les issues sont vraiment trop nombreux pour être listés ici.
Si vous êtes intéressé par les problèmes eux-mêmes, QuirksMode.org est une ressource incroyable que j'utilisais tous les jours avant de passer aux bibliothèques côté client. Consultez également la présentation de John Resig Le DOM est un gâchis à Yahoo, qui donne beaucoup de théorie sur la façon de traiter efficacement les sujets multi-navigateurs.
Cependant, si vous souhaitez simplement les résoudre, votre question est un excellent exemple de la raison pour laquelle beaucoup envisagent d'utiliser des bibliothèques côté client comme jQuery , YahooUI , MooTools , Dojo , etc. Avec une communauté florissante, des personnes talentueuses et des projets de soutien d'entreprise comme ceux-ci vous permettent de vous concentrer sur votre application plutôt que sur ces problèmes.
Voici quelques exemples jQuery qui évitent une grande partie de la frustration entre les navigateurs et peuvent vraiment rendre tout cela amusant.
Liaison par clic de souris entre navigateurs
$('#select anything + you[want=using] ~ css:selectors').click(
function(){
alert('hi');
}
);
Injection HTML inter-navigateurs
$('#anElementWithThisId').html('<span>anything you want</span>');
Ajax inter-navigateurs (tous les objets de requête sont toujours disponibles pour vous)
$('p.message').load('/folder/file.html');
Et ce qui me bluffe vraiment, chargez un sous-ensemble de données avec des sélecteurs (voir manuel pour plus de détails)
$('p.message').load('/folder/file.html body p:first-child');
Maintenant, comment tout cela commence vraiment à s'amuser: enchaîner les méthodes ensemble
$('ul.menu a').click( // bind click event to all matched objects
function(evt){ // stnd event object is the first parameter
evt.preventDefault(); // method is cross-browser thx to jquery
$(this) // this = the clicked 'a' tag, like raw js
.addClass('selected') // add a 'selected' css class to it
.closest('ul.menu') // climb the dom tree back up to the ul
.find('a.selected') // find any existing selected dom children
.not(this) // filter out this element from matches
.removeClass('selected'); // remove 'selected' css class
}
)
Me rappelle de Joel Can Your Programming Language Do This? article.
Prenant tout cela à un niveau théorique, le véritable avancement ne vient pas de ce que vous pouvez faire avec la pensée et l'effort conscients, mais plutôt de ce que vous pouvez faire automatiquement (sans pensée ni effort). Joel a un segment à ce sujet dans Smart And Gets Things Done concernant les questions d'entrevue et les développeurs intelligents, a complètement changé mon approche de la programmation.
Semblable à un pianiste qui peut simplement "jouer" de la musique parce qu'elle connaît toutes les clés, votre avancement ne vient pas de faire plus de choses qui nécessitent de la réflexion mais plutôt plus de choses qui ne nécessitent aucune pensée. Le but devient alors de rendre toutes les bases faciles .. naturelles .. subconscient .. afin que nous puissions tous découvrir nos objectifs de niveau supérieur.
Les bibliothèques côté client, d'une certaine manière, nous aident à faire exactement cela. ;)
IE6? Meh. Vous les avez faciles ! Vous n'avez jamais eu à faire fonctionner la mise en page CSS dans Netscape 4 (sans planter tout le navigateur)? Vous n'avez jamais eu à écrire pour les navigateurs d'appliance qui ne prennent pas en charge les tableaux? Vous n'avez jamais eu à écrire pour IE Mobile?
il n'y a pas de prise en charge des gestionnaires d'événements attribués par JavaScript; vous ne pouvez écrire un gestionnaire d'événements qu'en définissant "onclick =" somestring "" dans innerHTML;
les propriétés DOM de niveau 1 les plus élémentaires (par exemple, nodeName, nodeType, nodeValue, firstChild, lastChild, nextSibling, previousSibling, data, value, HTMLElement.getElementsByTagName, tous les membres HTMLTableElement, la plupart des membres CSSStyleDeclaration) n'existent tout simplement pas;
la plupart des propriétés de mise en page CSS ne fonctionnent pas; de nombreuses propriétés CSS comme la largeur ne fonctionnent pas sur certains éléments tels que les champs de formulaire;
la définition de nombreuses autres propriétés CSS sur des éléments tels que les tables et les champs de formulaire provoque un blocage instantané du navigateur, ce qui, puisque Windows Mobile n'a pas de gestionnaire de tâches intégré, signifie que vous devez réinitialiser le périphérique en douceur;
oh, et mettre autre chose que du texte à l'intérieur d'un <bouton> est aussi un crash instantané;
d'énormes morceaux de méthodes JavaScript de base et de méthodes "DOM niveau 0" remontant jusqu'à Netscape 2 (!) sont manquants.
Et il s'agit de la version la plus récente du navigateur Windows Mobile phare de Microsoft en 2009.
Bien sûr, il prend en charge XMLHttpRequest, mais écrire AJAX code sur un navigateur dont le support CSS et script est inférieur à IE3 (!) Est bizarrement schizophrène, comme si vous travaillez avec un amalgame étrange du 21ème- technologies du siècle et du XIXe siècle.
Je ne le recommanderais pas.
Le plus gros problème de navigateur croisé? - Internet Explorer!
<start_grumpy>
IE est uniquement responsable de "retenir le Web" - les développeurs américains ne peuvent pas créer de sites incroyables en utilisant HTML5 ou SVG , ou XFORMS, ou CANVAS ... non pas à cause de Firefox, Safari ou Chrome, mais parce que les 2/3 d'Internet sont toujours bloqués sur IE. Sans oublier que ~ 20% du Web est toujours bloqué sur IE6! IE8 est la première version de IE au moins essayez pour être compatible avec les normes ( Les normes de 2001, c'est-à-dire), ce qui signifie qu'il faudra au moins 2018 avant que nous puissions enfin commencer à abandonner tout le support pour IE7.
</start_grumpy>
Sinon, nommez une méthode DOM qui IE supporte pleinement ... le fait qu'il s'agit d'une question difficile à répondre est mon plus gros problème CrossBrowser.
getElementById() - badly broken
getElementsByName() - buggy
getElementsByTagName() - buggy
getAttribute() - buggy
setAttribute() - majorly broken
createElement() - buggy
appendChild() - buggy
même les choses IE inventées sont foirées ...
innerHTML (getting) - returns the worst markup possible
innerHTML (setting) - doesn't work on the elements you'd want to dump a bunch of data into (e.g. Tables and Selects)
Cela fait trop longtemps pour avoir de nombreux problèmes, mais cela me rend encore plus fou de devoir contourner la non-prise en charge d'IE pour des choses comme display: table,: last-child et: hover en dehors des ancres.
Tous les IE trucs sont toujours fous, mais c'est juste folie d'arrière-plan maintenant :)
Dans Internet Explorer (remarque: les anciennes versions d'IE, pas nécessairement les versions 9/10 +), si vous créez des éléments de formulaire en utilisant document.createElement, le champ ne sera pas soumis avec le formulaire. La seule solution consiste à utiliser
element.innerHTML = "<input type='text' value="+val+" name="+name+">";
Lors du développement d'un cadre de tests système pour une application Web, nous avons dû simuler divers événements tels que les clics. Je me souviens que nous ne pouvions pas trouver de moyen normal de le faire dans IE et FF et avons dû l'implémenter de deux manières différentes avec beaucoup de vaudou autour.
Je ne me souviens pas des détails, mais je me souviens que c'était vraiment ennuyeux.
This , en gros.
Les frameworks javascript modernes (jQuery, prototype, etc.) ont fait des merveilles pour faire fonctionner le code dans de nombreux navigateurs à la fois.
Le plus gros problème que j'ai maintenant est le fait que toute sorte de comportement riche de l'interface utilisateur fonctionne incroyablement lentement. IE7 est mauvais. IE6 est pire. IE8 est bogué, à moitié terminé et vraiment pas mieux que IE7.
Le pire, c'est que je ne pense pas que nous serons jamais exempts d'IE6. C'était tellement omniprésent et si sacrément décalé. De nombreuses applications d'entreprise (et j'entends par là de grandes applications Web créées par une grande entreprise pour une autre grande entreprise) ont utilisé un javascript IE6 très spécifique qui ne fonctionne même pas dans IE7, sans parler de quoi que ce soit d'autre.
Les entreprises ne peuvent pas se permettre de remplacer complètement ces applications - nous essayons de leur en vendre de nouvelles et cela signifie que le support IE6 est obligatoire. Dans l'état actuel des choses, avec des entreprises de crédit qui réduisent leurs coûts, je pense que nous continuerons à soutenir IE6 en 2015 :-(
Dans IE, vous ne pouvez pas masquer les éléments d'option de sélection, uniquement l'élément de sélection lui-même. Cela rend difficile la modification dynamique du contenu des options sélectionnées à l'aide de Javascript.
Ce problème existe également dans Safari et Chrome.
Il existe de nombreux autres problèmes avec IE, mais celui-ci m'a causé le plus de frustration récemment.
Incohérences dans le modèle de boîte CSS lors du traitement des formulaires. En particulier, il est irritant de voir comment chaque navigateur gère la boîte <select>
mon seul cauchemar est IE6, vous devriez toujours chercher des hacks, mais chaque fois que vous rencontrez un problème, il y a quelqu'un qui l'a rencontré avant vous et a blogué à ce sujet (et nous ne nous en éloignerons jamais)
Je travaillais sur la mise en page CSS écrite par quelqu'un qui pensait que la taille donnée à un élément était taille + rembourrage + bordure comme dans IE5 et pas seulement la zone de contenu comme expliqué dans les spécifications officielles. Il a été écrit il y a seulement quelques mois, il a donc fait des hacks pour le rendre bien dans IE7. Il m'a fallu plusieurs heures avec FireBug pour rechercher la source du problème et au moment où je l'ai réalisé, j'étais vraiment ennuyé.
Si vous ouvrez un site avec du CSS "flottant" écrit pour IE5 dans Firefox, les cases n'ont tout simplement pas assez d'espace pour tenir et tomber sur la page. Si vous l'ouvrez dans IE7, il a l'air bien, car IE7 laisse les bordures se chevaucher, ce qui semble presque correct. Pour quelqu'un aussi inexpérimenté que moi, c'était difficile à noter.
Un moyen simple d'aider avec les problèmes d'affichage embêtants IE est d'utiliser Firebug, Yep enen dans IE 6/7/8 Il suffit d'utiliser Firebug Lite
Si vous ajoutez ce qui suit en tant que signet et le collez sur votre barre d'outils, cela activera Firebug Lite sur n'importe quelle page Web en un seul clic. (vérifiez cela uniquement dans IE et cela fonctionne très bien.)
javascript:var%20firebug=document.createElement('script');firebug.setAttribute('src','http://getfirebug.com/releases/lite/1.2/firebug-lite-compressed.js');document.body.appendChild(firebug);(function(){if(window.firebug.version){firebug.init();}else{setTimeout(arguments.callee);}})();void(firebug);
Mon plus gros problème, ce sont les fabricants de navigateurs. Petit arrogant * ^ &% s. Je veux dire, vous ne pouvez vendre un navigateur à personne, mais tout le monde est dans son petit coin à essayer de se faire les uns les autres, créant seulement une division. Oh et Chrome. Chrome ne sait toujours pas ce qu'il veut être, Safari ou Firefox. Mis à part son astuce, c'est pratiquement inutile. Je blâme tous les gars qui ont continué à googler juste parce que vous détestez les monopoles. Devinez quoi, ils sont le monopole maintenant. Maintenant, nous pouvons tous profiter de logiciels de deuxième ordre, lancés prématurément.
Cela provient principalement d'un bug * que j'avais dans Chrome aujourd'hui, il ne m'est jamais venu à l'esprit d'interroger le navigateur. Safari et Chrome échouaient donc j'ai pensé Hé, une fois que j'ai résolu le problème de Safari Chrome serait corrigé automatiquement, mais oh non non. M. "Je lance des onglets dans des processus séparés" AKA "Sr. No full screen" devait juste tenir moi dans la serrure de lézard avec sa mise en œuvre ahurissante.
Je déteste également Firefox. Je ne peux pas dire si j'ai une infestation de virus ou Firebug en cours d'exécution. Maintenant, jusqu'à ce qu'Adobe décide de publier un navigateur qui rend Flash pratique pour d'autres choses que les clips, je vais avoir quelque chose à chier pendant longtemps. Et nous savons tous que c'est ça la vie.
De plus, je n'apprécie la programmation que lorsque je rencontre des bugs ridicules qui font fonctionner mon cerveau.
Pour Firefox, pour obtenir les données complètes, vous devez soit utiliser node.normalize avant d'appeler node.firstChild ou utiliser node.textContent, deux méthodes spécifiques à Mozilla
En fait, toutes ces méthodes sont des méthodes DOM W3C prises en charge par la grande majorité des navigateurs. Je pense que vous trouverez qu'ils fonctionnent également dans IE.
Mon plus gros problème de navigateur croisé est qu'il y a des gens qui utilisent encore IE.
Le deuxième plus important est que même dans les navigateurs conformes aux normes, il est toujours impossible de faire certaines choses en CSS; par exemple tbody {overflow:auto} ne fait rien d'utile à part Gecko, et même là, il a des bugs.
Les restrictions d'IE sur l'utilisation des manipulations DOM sur les tables m'ont forcé à adopter une approche complètement différente de quelque chose. Très frustrant au début, mais le résultat positif était que la deuxième approche était finalement meilleure, donc je suppose que je devrais être reconnaissant envers IE. ;)
Pour supprimer les bordures iframe dans Internet Explorer, vous devez spécifier l'attribut frameborder au format camelCase, qui n'est pas compatible xhtml.
<iframe frameBorder="0"/>
Firefox et IE ont des configurations de table différentes dans le DOM, dans l'un, tous les frères et sœurs d'une cellule sont les autres cellules, tandis que l'autre a des éléments entre les cellules. Je ne me souviens plus dans quel sens. c'est le cas, mais cela m'a donné un vrai mal de tête dans une seule application.