Bug de .offsetHeight

Bonjour à tous,

d'après la documentation officielle, objet.offsetHeight n'inclut pas les marges. Aucune exception n'est mentionnée.

Or j'utilise .offsetHeight deux fois dans ma page, et il est absolument certain que dans un cas il compte les marges de l'objet, alors que dans le deuxième cas il ne les compte pas. Aussi bien sous IE que sous Firefox.

Quelqu'un saurait-il le pourquoi de ce bug, ou alors est-ce qu'il va encore falloir inventer une fonction qui calcule le VRAI offsetHeight dans tous les cas de figure ? Ha là là, décidément j'adore le javascript...

Bonjour,


>>objet.offsetHeight n'inclut pas les marges
    je veux bien te croire

>>il est absolument certain que dans un cas il compte les marges de l'objet,
>>alors que dans le deuxième cas il ne les compte pas
    mais là, j'ai un très gros doute.
    si l'objet n'a pas été modifié entre les 2,
        dans les 2 cas, ça doit donner le même résultat,
        si .offsetHeight est utilisé de la même manière.

    les bugs ( javascript ou pas ) sont très très rares. parfois, ça ne fonctionne
        pas comme on voudrait, ou on n'a pas compris comment ça marchait,
        certes, mais des erreurs dans des langages normaux ???

---

---

Bonjour Bultez !

Pour m'assurer du bug, j'ai fait qqch de très simple : dans ma page j'ai deux div.
Chacune a 20px de margin-bottom.
Quand je fais offsetHeight, j'obtiens les tailles : 43px et 216px.
J'enlève les deux margin-bottom de ma feuille css et je rafraichis ma page.
Et là j'obtiens les tailles 43px et 196px.
43 pixels et 196px sont effectivement les tailles sans margin-bottom, j'ai vérifié sous Photoshop

A propos des bugs très très rare, tu y vas fort, parce que des bugs liés aux css manipulés par javascript, j'en trouve tous les jours et ils me pourrissent la vie ! J'en dresse une liste au fur et à mesure de mon site, si tu veux je peux t'envoyer ça.
Mais des bugs "intrinsèques" à javascript comme celui-là je te l'accorde, c'est plus rare.

à propos de ton test, je ne vois pas le rapport avec ta 1ère affirmation,
    qui disait "résultats différents à 2 endroits dans la même page" ?
    1° les résultats sont les mêmes...
            sauf si tu changes quelque chose ( margin-bottom )
            ce qui me semble normal.

>>des bugs liés aux css manipulés par javascript
    tu confonds avec des résultats, des traitements... différents entre
       plusieurs navigateurs.
    pas des bugs.
    et entre nous, pas si catrastrophiques qu'on veut bien le dire, de plus
       généralement pour des pinaillages de présentations...
      

---

---

Ha oui d'accord, je me suis mal exprimé sur mon problème, excuse-moi Bultez.

Pour les différences de résultats et de traitement, quand un navigateur ne fait pas ce qu'il devrait faire en toute logique, ne peut-on pas appeler ça un bug ?

Sur le site que je fais en ce moment, j'ajoute/supprime beaucoup de noeuds, je fais des innerHTML, je modifie les height et les width à tour de bras, tout ça pour donner un site très dynamique et personnalisable, un peu comme ce que permet Netvibes dans un autre genre.

Et c'est quand je pousse le javascript dans ses retranchements comme ça que je découvre des bugs (enfin, surtout le javascript IE, car FF marche très bien. Je dirais que 4 bugs sur 5 que je rencontre sont sous IE). En particulier l'interprétation des css sur des blocks insérés dynamiquement laisse plus qu'à désirer. Un margin-top qui est ignoré alors que sur le même objet le margin-bottom fonctionne, c'est une aberration que j'appelle bug.

Et sur mon site par exemple, ce n'est plus du pinaillage quand mes divs repositionnées viennent se coller les unes aux autres ou qu'on voit les ficelles de mes joyeuses mécaniques

Enfin, en tout cas merci, je pense que j'arriverai à résoudre mon problème d'aujourd'hui, il n'est pas très grave, c'est juste un peu agaçant, comme souvent !

>>quand un navigateur ne fait pas ce qu'il devrait faire en toute logique
    selon TA logique...
    qui n'est ni celle des équipes de développements du produit,
    ni celle ( sqi on peut dire ! ) des fonctionnalités existantes
       ou pas dans le produit.

>>je dirais que 4 bugs sur 5 que je rencontre sont sous IE
    j'en vois tout autant chez FF ( ou d'autres navigateurs )
    en général, ce n'est du ni  à IE, ni  à FF ( ou autres ) !

>>Un margin-top qui est ignoré alors que sur le même objet le margin-bottom fonctionne
    curieux... mais si tu le dis.

>>je fais des innerHTML
    ah. c'est bien quand on fait des choses "légères".
    sinon, il vaut mieux createElement + appendChild.

>>l'interprétation des css sur des blocks insérés dynamiquement laisse plus qu'à désirer.
    peut-être.
    pas réeellement rencontrés de bugs.

---

---

Héhé, je vois que tu défends bien tes positions, que je respecte tout à fait

>> selon TA logique...
Oui tu as raison, il n'y a pas toujours UN bon choix, donc pas UNE logique. Mais je pense que j'ai la même logique que les développeurs de Firefox, puisque dans ma façon de programmer je ne découvre pas leurs bugs, mais principalement ceux de IE. Ma logique est celle des standards, puisque j'ai appris à programmer avec ces standards, avec des livres qui décrivaient ces standards.

>>Un margin-top qui est ignoré alors que sur le même objet le margin-bottom fonctionne
    curieux... mais si tu le dis.

Oui ça paraît bizarre mais je peux te faire une démonstration si tu veux, le problème n'apparaît que sous IE.

>>je fais des innerHTML
    ah. c'est bien quand on fait des choses "légères".
    sinon, il vaut mieux createElement + appendChild.

Oui et non... à ma connaissance, on ne peut pas insérer un bloc de html qui contiendrait des balises avec insertTextNode. Or j'ai pas mal de fonctions qui me renvoient ce genre de blocs tout prêts à être insérés. Et le problème c'est que quand on insère un noeud avec InsertBefore ou AppendChild, le navigateur n'interprète pas les css appliqués à ce noeuds.
Je m'explique : chez moi,
var newNode = document.createElement("div");
newNode.setAttribute("style", "width: 150px;");
bbb.insertBefore(blabla);
ne fonctionne pas pour le width, même si le noeud est inséré. J'ai peut-etre raté quelque chose là-dessus ?
Bref, InnerHTML étant effectivement trop lent sur les gros blocs de texte existants, je crée un nouveau noeud avec DOM (ça c'est rapide) et ensuite dans ce noeud vide je balance mon morceau de code html.

>>l'interprétation des css sur des blocks insérés dynamiquement laisse plus qu'à désirer.
    peut-être.
    pas réeellement rencontrés de bugs.

Ce qui arrive souvent par exemple c'est qu'avec un innerHTML +=  qui vient rajouter un bloc de html à la suite d'un autre, il y a des problèmes de positionnement et autres. J'imagine que c'est parce que le navigateur interprète les css sur la nouvelle partie du bloc insérée, et ne réinterprète pas le bloc globalement (ce n'est qu'une hypothèse).
Alors que si je reconstruis tout le bloc en une seule fois, même si la source est exactement la même, les css sont interprétés différemment et tout rentre dans l'ordre. C'est pourquoi j'ai banni de ma programmation tout innerHTML qui ne se ferait pas sur un bloc vide.

>> Ma logique est celle des standards
    perso, rien à cirer. ( bien sûr c'est de la provoc ! )     c'est un leurre.
    ce fut ( depuis toujours et sur d'autres systèmes aussi ) des excuses bidons
        pour tenter de contrecarrer un leader,  parce que la concurrence ne
        faisait pas aussi bien ( je ne parle pas de toi, mais des concurrents à IE )
       ( j'ai connu CII-HB qui invoquait les mêmes choses, respects des standards,
         contre IBM,  sauf que IBM, ça marchait, pas CII-HB, qui est mort depuis !)
    de plus, ce ne sont  ni des règles, ni des obligations, simplement des
       recommandations... "qui arrivent 20 ans après la guerre"...

    il faudrait homogénèïser, certes. demandons donc à FF de respecter les
       standards, ce qu'il ne fait que sur ce quoi ça l'arrange ( c'est le moins
       qu'on puisse dire !)
   
>> je peux te faire une démonstration
    ben ( tiré de SelfHtml ) :

<html><head><title>margin-bottom</title></head>
<body bgcolor="#FFFFFF" text="#000000"
        style="font-family:tahoma;font-size:12px;font-weight:bold">
<p id="toto" name="toto"
    style="margin-top:1cm;margin-bottom:2cm">Ce paragraphe de texte a un espace de 2cm qui le s&eacute;pare du suivant.</p>
<p style="margin-bottom:18pt">Ce paragraphe de texte a un espace de 18pt qui le s&eacute;pare du suivant.</p>
<p style="margin-bottom:1in">Ce paragraphe de texte a un espace de 1in qui le s&eacute;pare du suivant.</p>
<p>Ce paragraphe de texte n'est l&agrave; que pour comparer et aucun espace vers le bas ne lui a &eacute;t&eacute; affect&eacute;.</p>
<script type="text/javascript">
    alert(document.getElementById('toto').offsetHeight);
</script>
</body></html>


ça donne la même chose ( et correct ) avec IE ou FF
( si même font ! car IE et FF, n'ont pas la même par défaut !)

>>on ne peut pas insérer un bloc de html qui contiendrait des balises avec insertTextNode
    je ne connais pas insertTextNode...
    mais ça me semble normal ( Text ) !

    par contre :

function ajoutHTM(ou, htm)
{  var tmp = document.createElement("htmlSection");
   tmp.innerHTML = htm;
   ou.appendChild(tmp);
}

   ajoutHTM(document.body,"<a href='http://ww.Google.fr'>lien</a>");  
   
    ajouter du html, ça baigne.

>>J'imagine que c'est parce que le navigateur interprète les css sur la nouvelle partie
>>du bloc inséré, et ne réinterprète pas le bloc globalement
    peut-être.

---

---

>> Ma logique est celle des standards
>> c'est un leurre.   ce fut ( depuis toujours et sur d'autres systèmes aussi ) des excuses bidons pour tenter de contrecarrer un leader,  parce que la concurrence ne faisait pas aussi bien

Au secours, ne me dis pas que tu veux jeter le W3C à la poubelle... il y a quelques trucs qu'ils préconisent qui ne sont pas faisables (la séparation des couches javascript/css/html ils peuvent toujours rêver, dès que ça devient complexe on est obligé de moduler) mais dans l'ensemble c'est tout à fait raisonnable il me semble. Et même IE affiche sa volonté de s'y conformer de plus en plus. Le W3C n'est pas un concurrent de IE, j'ose espérer qu'il travaille pour l'intérêt de tous. Enfin, je pense qu'en termes d'ergonomie/adaptabilité/rapidité/etc. IE n'est plus le leader, et copie FF à plusieurs égards.

Mais pour en revenir aux bugs, pour résumer mon opinion là-dessus en une ligne : quand je fais un programme et que je l'essaie, la plupart du temps il marche d'emblée sous Firefox, et sous IE je dois presque toujours bidouiller pour régler des problèmes. Après FF a sans doutes ses torts, mais je ne les vois pas ! mais ça viendra peut-être.

>> je peux te faire une démonstration
    ben ( tiré de SelfHtml ) :
ça donne la même chose ( et correct ) avec IE ou FF
( si même font ! car IE et FF, n'ont pas la même par défaut !)

Oui oui sur des exemples simples, tout marche toujours très bien ! Mais là j'ai passé une semaine à me créer un système de drag and drop pour réordonner des éléments d'une liste et c'est là que tout ne marche plus aussi bien.

Si tu as du courage, lis cette explication :
- En gros, chaque élément de la liste est une div, et toutes ces div sont des noeuds frères.
- Les divs sont en position relative, les unes en-dessous des autres.
- Elles sont séparées de 10 px chacune grâce à un margin-top.
- Quand je déplace une div, elle devient en position absolue pour suivre la souris. Mais son noeud lui est toujours présent dans le code, rien n'a changé.
- Donc les autres div d'en-dessous remontent, puisque la div déplacée est passé en absolute, OK ? Parce que la div qui suit la souris n'est plus dans le flux normal.
- Appelons A la div qui précède la div qui suit la souris, B la div déplacée, et C la div qui vient après la div qui est déplacée.
- Si tu imagines bien la situation, tu dois penser que les div A et C se suivent gentiment avec 10px d'écart ?
- Et bien sous IE non, parce que le margin-top de C refuse de s'appliquer, et C est collée à A. Sous FF ça marche très bien.
- Si on met du margin-bottom à la place du margin-top sur les div, à ce moment là le margin-bottom de A s'applique et tout va bien, C est séparée de A par 10px.

Voilà toute l'histoire ! Ouf.

Tiens, un autre truc très simple qui m'a saoûlé et qui me traverse l'esprit : sous IE, le onmouseout d'une div est déclenché quand on passe la souris sur une balise (ex: <span>) qui est à l'intérieur de la div. Et pourtant, on est encore dans la div ! enfin bon.


>>on ne peut pas insérer un bloc de html qui contiendrait des balises avec insertTextNode
    je ne connais pas insertTextNode... mais ça me semble normal ( Text ) !
   par contre :

function ajoutHTM(ou, htm)
{  var tmp = document.createElement("htmlSection");
   tmp.innerHTML = htm;
   ou.appendChild(tmp);
}

insertTextNode insère du texte seulement oui et c'est normal, mais pourquoi la fonction insertNode() n'existe-t-elle pas ? elle existe dans d'autres langages qui manipulent le XML et nous dispenserait du innerHTML qui a ses inconvénients. Ta solution, oui c'est à peu près ce que j'utilise en ce moment. Enfin, les arbres DOM ne sont pas interprétés de la même façon dans tous les navigateurs, donc je les utilise toujours avec précaution, et j'évite quand je peux. D'ailleurs au passage, j'ai dû utiliser le DOM car IE était trop lent à faire tourner mes boucles et insérer mes innerHTML, tandis que FF était parfaitement fluide (méchant IE, pas bien !)

Je précise quand même que pour le bug du margin-top, j'ai simplifié, parce qu'entre-temp, il y a un noeud ajouté puis supprimé entre A et C. Le bug n'intervient pas si l'on n'ajoute et supprime pas ce noeud.