2010-01-21 2 views
1

IE6 me surprend toujours mais celui-ci est VRAIMENT impair.jQuery trop rapide pour IE6? (Problème impair résolu par l'ajout d'alertes?)

Je crée un menu horizontal où j'ai besoin que le texte de chaque 'bouton' soit centré verticalement. Facile dans n'importe quel navigateur sauf IE. Donc, pour les navigateurs IE, j'utilise un peu de javascript pour ajouter le remplissage nécessaire à chaque bouton pour s'assurer que le texte apparaît centré. J'ai obtenu ce travail très bien dans IE8 et IE7. IE6 ne faisait tout simplement pas bien pour une raison quelconque.

Alors, j'ai ajouté un droit d'alerte avant la ligne qui ajoute le rembourrage:

$menuTriggerUL.children('li').each(function(i){ 
     var heightDifference = tallestTab-tabTextHeight[i]; 
     if (heightDifference < 0){heightDifference=0}; 
     alert(heightDifference); 
     $(this).children('a:first').css("padding-top", Math.floor(heightDifference/2)); 
    }); 

Avec cette alerte là, IE6 un par un rembourrage appliquer le bon à chaque élément correctement.

Si je sors de l'alerte, il tâtonne et obtient le premier droit, mais trébuche sur les suivants.

Il semble que jQuery essaie d'aller plus vite qu'EIE6 peut le faire. Évidemment, ce n'est probablement pas ce qui se passe, mais je ne sais pas comment le décrire autrement.

Quelques éléments pouvant être impliqués dans le problème: J'utilise une fonction jQuery each() et, à l'intérieur, saisissant des valeurs d'un tableau précédemment rempli.

Les théories sur ce qui pourrait se passer?

MISE À JOUR: La réponse de jhurshman ci-dessous était la solution. J'aimerais en savoir plus sur cette question et si les gens ont des idées sur les scénarios qui pourraient déclencher ce problème pour IE6. Je ne l'ai jamais rencontré, mais je suis heureux d'avoir une solution dans le sac à outils pour une utilisation future.

+3

Est-ce que tout cela est dans un gestionnaire $ (document) .ready? – eliah

+0

@eliah: oui c'est –

Répondre

2

En travaillant avec IE (6 surtout, mais avec 7 aussi parfois), il y a assez fréquemment des situations où le DOM ne semble pas être prêt immédiatement après qu'il a été manipulé d'une certaine manière. Très souvent, ces problèmes peuvent être résolus en reportant le code problématique en faisant quelque chose comme:

setTimeout(troublesomeCode, 0); 

(où troublesomeCode est une référence à une fonction qui effectuera les opérations problématiques)

Je voudrais aussi essayer bouclez les nœuds dans l'ordre inverse et voir si cela fait une différence.

+0

Whoa ... c'est ... WEIRD! Votre solution l'a totalement corrigé. Donc, toutes les références/liens qui expliquent ce problème particulier dans plus de détails? Il semble que cela devrait être quelque chose que jQuery gère en interne. Y a-t-il des scénarios où cela pose plus de problèmes que d'autres? –

+0

Je ne peux pas dire que j'ai jamais vu une explication de ce qu'est exactement le problème et pourquoi cette approche aide. Presque tous les problèmes qui disparaissent lorsqu'une alerte est ajoutée peuvent être "résolus" avec ceci. C'est bien connu chez les développeurs JS de ma compagnie, donc c'est presque une blague: "Avez-vous essayé setTimeout-zéro?" Ma meilleure estimation de ce qui cause ces problèmes est que IE maintient certaines structures de données relatives à l'arborescence DOM d'une manière non thread-safe.Set un setTimeout-zéro permet au thread JS en cours de terminer avant d'essayer quelque chose qui provoque IE pour avoir besoin d'accéder à ces structures de données – jhurshman

+0

merci pour toute l'aide/info.Il est étonnant qu'en 2010, je suis * encore * découvrir de nouvelles façons pour IE me p * ss off!; o) –

0

Il n'y a pas d'accolade fermante dans l'instruction if.

+0

if (heightDifference <0) {heightDifference = 0}; –

+0

Était-ce leur il ya une minute? Ou mes yeux me trompaient-ils? – corymathews

+0

@jhurshman Je n'ai pas édité mon post original, mais peut-être une autre âme gentille l'a fait? Je suis définitivement connu pour faire des fautes de frappe. –