Bonjour les gens,

IE devient fous, il duplique du texte tout seul, sans qu'on ne lui demande. Ou encore : l'art et l'art manière de dupliquer du texte sans même JavaScript (c'est le fantôme de la silicon valley).

Bon, s'érieusement : le phénomène, que j'ai constaté plusieurs fois, et qui me sort par les deux trous de nez, se produit avec des float. J'ai un élément en float, avec un contenu, et le un petit bout de la fin du contenu se trouve dupliquer et collé aprés l'élément float.

Par exemple, <p style="float:right;">1234</p>, s'affichera comme <p style="float:right;">1234</p>34 ... il en remet un petit de la fin à coté.

Parfois je m'en sort en ajoutant un <span>&nbsp;</span> aprés l'élément en float. Mais parfois c'est un nbsp qu'il faut ajouter avant, mais cette fois ci surtout e dehors de toute balise, ou plus exactement, le nbsp doit être placé dans l'élément parent du float.

Je n'y comprend rien, et ça fait quand-même un peu tache dans le décor.

Pour voir un exemple à l'oeuvre : http://www.xxxxxxxxxxxx (ne jugez pas trop, c'est en conception). Allez en bas à droite, cliquez sur « Attributs », puis cliquez sur l'icône d'aide. Vous verrez le texte de l'aide s'afficher, et ... ho, merveille d'horreur... un petit bout de la fin qui est dupliqué.

Voici en image un exemple :
http://img444.imageshack.us/img444/7318/bugiedd2.png

Dans ce cas là, j'ai constaté que le problème peut être résolu, si je fais par exemple nbsp;<p style="float:right;">1234</p>. Tandis que dans d'autre cas, il faut faire <p style="float:right;">1234</p><span>&nbsp;</span>

Est-ce que quelqu'un(e) en sait plus sur ce phénomène ennuyeux ? Ca pourrait ressembler à un bug dans la gestion des buffers texte qui ne se produirait qu'en présence de float... il s'emmêlerait alors les pinceaux avec les différents flux, retransmettant la fin d'un flux vers le début du flux suivant... une sorte de court-circuit entre ses buffers texte ? C'est possibla ça ? Mais si c'est ça, alors on a pas vraiment d'autres choix que de subire.

EDIT: J'ai supprimé l'URL, vu que celle que je donnais n'est plus concernée par le cas que j'indiquais dans ce message.
Modifié par hibou57 (05 Nov 2007 - 03:59)
problème classique de haslayout. Doter le conteneur de l'élément concerné, ou l'élémet lui-même, de layout via un zoom:1, par exemple.

(Un jour, un jour, cela fera enfin partie des techniques de base correctement documentées. Il n'y a jamais que 2 ans qu'on en parle Smiley ravi

Allllô ? La FAQ ? Smiley cligne )
Modifié par Laurent Denis (25 Jun 2007 - 13:48)
Laurent Denis a écrit :
problème classique de haslayout. Doter le conteneur de l'élément concerné, ou l'élémet lui-même, de layout via un zoom:1, par exemple.

(Un jour, un jour, cela fera enfin partie des techniques de base correctement documentées. Il n'y a jamais que 2 ans qu'on en parle Smiley ravi

Allllô ? La FAQ ? Smiley cligne )

Ah, ben merci... je connais les problème de layout (un peu), mais je croyais qu'il ne s'appliquait qu'à des problèmes de dimmensionnement. Il abuse un peu layout, même le texte qu'il nous massacre... pffff...
Oui ? bonjour madame la FAQ, je vous écoute Smiley cligne ... mmmh... oui, ah, il faut que j'aille vous lire ? .. oui, Laurent Denis m'a dis, oui... ok, à tout à l'heure

Quand même : ne devrait-on pas parler de sac à bug plutôt que de has-layout ?
Modifié par hibou57 (25 Jun 2007 - 14:26)
Tiens, si je ne m'abuse, le fait d'ajouter un commentaire même vide juste après la ligne html qui se duplique peut résoudre le problème.
Laurent, je viens de parcourir la FAQ, et je n'y ai rien trouvé au sujet de has-layout. Mais ça ira, je vais tester le zoom:1, et je repasserai pour éventuellement marquer le sujet comme résolu.
heu... C'est mon intervention qui prêtait à confusion: je réclamais un ajout à ce propos dans la FAQ.

Pour la peine, si tu ne trouves pas, je n'aurais plus qu'à m'y coller pour donner la solution dans ce cas précis Smiley cligne

<edit>
Mouarf .

C'est la variante amusante du bug décrit ci-dessus, dont la solution n'est pas zoom, mais le reflow forcé avec:

#helpMessage p {
position: relative
}

Modifié par Laurent Denis (25 Jun 2007 - 15:45)
Merci pour ton intervention grand sachem (y a un film avec fernandel sur france3... marrant ce film).

zoom:1, comme tu le dis, ne fonctionne pas. Mais position:relative non-plus.

La solution de Benjamin D-C ne fonctionne que partiellement : elle ne fait que racourcire d'un caractère le bout de texte dupliqué, sans le supprimer entièrement.

Mais j'ai quand-même une bonne nouvelle : il suffit d'ajouter un <div></div> (un div vide, sans aucun style, rien du tout). Cette solution est plus commode que l'usage d'un nbsp, car elle ne cré pas d'espacement parasite.

Il faut placer le div vide, soit avant, soit aprés l'élément juste aprés lequel IE copie le fragment de texte parasite. Je n'ai pas compris encore selon quel logique il faut parfois l'ajouter avant ou aprés, mais seul l'un ou l'autre fonctionne selon les cas.

Exemple :
soit

<A>
   <B>
      <C>
      </C>
   </B>
</A>

Si C contient un texte dont un fragment dupliqué s'affiche aprés B, alors il faut ajouter le div vide justant avant B, et non pas juste avant C. Ou alors, parfois, il faut ajouter le div vide juste aprés B.

Si on ne comprend pas bien, on pourra determiner le point d'insertion du div par tatonement Smiley ravi ( lol ) Au besoin, on pourra s'aider des bordure d'élément pour savoir aprés quel élément le contenu dupliqué est écrit (dans le cas ou plusieurs éléments sans bordures sont imbriqué, ça peut ne pas être évident, et il faut alors ce repèrer avec les bordure).

Il faudra aussi penser à remplacer le div par un span, quand le conteneur l'exigera (dans le respect des règles d'inclusion d'élément du HTML).

Voilà tout ce que je peux en dire pour le moment. C'est un début de formalisation d'une solution.
Modifié par hibou57 (25 Jun 2007 - 16:32)
Curieux, position:relative semblait résister chez moi au rechargement, redimensionnement etc. de page. Mais sinon, oui, un contenu supplémentaire est une bonne solution de dernier recours.
Laurent Denis a écrit :
heu... C'est mon intervention qui prêtait à confusion: je réclamais un ajout à ce propos dans la FAQ.

Pas de problème pour un ajout dans la FAQ. Par contre, si on me le rédige, ça m'arrange. Smiley lol

Au pire, quelques pistes de ce qu'il faudrait mettre dedans (présentation succincte et liens qui vont bien ?).
Modifié par Florent V. (25 Jun 2007 - 17:28)
Bonjour Florent,

Si je te rédige ça, j'aurais droit à un p'tit lien ? Smiley lol Ze peux même mettre un article sur mon site, zé puis tu pourra mettre un lien vers... heuu.... je me tais avant de prendre une baffe Smiley murf Oilà.

Effectivement, ça demande à être encore creuser.

J'ai encore rencontré le problème, dans d'autres circonstances (j'utilise beaucoup de float sur ces pages là), et j'ai quelques autres nouvelles, pas trés bonnes celles-ci.

1) Il y a des cas ou même la solution du div vide ne donne rien, car IE duplique toujours au moins un caractère (vous verrez en 2 pourquoi c'est ennuyeux). Quand cela se produit, il faut mettre utiliser un nbsp, il n'y a pas d'autre choix. Le nbsp est ce qui fonctionne le mieux dans tous les cas, mais avec l'inconvénient de l'espacement qu'il peut produire. Il faut donc reprendre la procédure indiqué précédement, et y ajouter ceci : tenter d'abord avec un div, et si vraiment ça ne marche pas, en dernier recours, employer un nbsp (que l'on pourra mettre dans un div pour les conteneur ne pouvant pas être parent d'un inline).

2) Accrochez vous bien là : IE ne duplique pas que le texte, mais les propriétés CSS avec, et même, et même... et même les événement JavaScript attachés!!! Si par exemple le texte qui subit une duplication de son petit bout à la fin, réagis à un événement onclick par exemple, alors le petit bout de texte dupliqué qui est copié plus loin, réagira lui aussi au clique de souris (respirez), et si le texte à l'attribut souligner, alors le petit bout de texte dupliqué sera lui aussi souligné (par exemple).

En fait, IE semble reprendre entièrement un fragment de la page avec tout ce qui va avec, pour le recopier un peu plus loin. Ceci indique donc que le bug est plus grave qu'un simple bug de la gestion des flux et des buffers texte associés aux flux. À ce point là je ne m'explique plus comment c'est possible, et je suis vraiment à cours d'imagination pour imaginer quel cafouillage dans les rouages d'IE peut avoir de tels effets secondaire.

Quoiqu'il en soit, et même si c'est encore à travailler, l'ajout d'un élément judicieusement placé peut résoudre le problème, duce t-il être fait pour provoquer la duplication d'un blanc dans le pire des cas (ce qui est mieux, faute de mieux, que le duplication d'un fragment)

Je précise : tout ceci se passe sur IE6 (je n'ai plus IE5, alors je ne peux pas tester pour IE5, et mon PC n'a pas assez de RAM pour supporter IE7... alors je ne peux pas tester non-plus IE7)
Modifié par hibou57 (25 Jun 2007 - 19:28)
(... suite)

Petit remarque toute bête : le codage HTML non conforme aggrave nettement le phénomène, et à l'inverse, un bon codage conforme peut nettement l'améliorer.

Je parle des règles du genre « tel élément contenant tel ou tel élément », et non pas des règles sur les attributs ou autre.

Il y avait des erreurs dans le codage de la page, et donc je pense que c'est moins un vrai bug qu'une mauvaise gestion des pages pas trés bien codés.

Je referai d'autres tests dans d'autres circontances, mais pour l'instant, en modifiant le code des pages pour qu'il soit W3C conforme (à l'exception de certains attributs), le problème a totalement disparu Smiley smile

C'est à se demander si je ne devrais pas m'excuser bassement auprés d'IE Smiley ravi
Smiley lol Voilà que ça remet ça, et rebelote, le même bug.

Cette fois si c'est sur une page qui est pourtant HTML valide. La solution du div que je donnais ne fonctionne pas dans ce cas précis. La solution du commentaire fonctionne, mais à condition... d'en mettre 4 à la suite.

Et encore, je m'aperçois qu'il y a des influances sur des IFRAME dont maintenant le contenu s'affiche complètement décalé vers la droite, la barre de défilement ne s'affiche plus alors que le contenu dépasse la hauteur de l'IFRAME. Tout ceci est apparu aprés des modification qui impliquaient des ajouts de commentaires.

Tout s'affiche bien sous Opera, Safari et FireFox.... il n'y a que sous IE que le problème s'exprime.

J'en ai marre, c'est un truc de fous, et ça rend les pages totalement inutilisables ... pffff....

N.B. Le bug est présent autant sur IE7 que sur IE6 (j'ai exactement le même rendu sur les deux)

EDIT: Je viens de re-tester le cas de l'IFRAME, et c'est le simple ajout d'un commentaire avant la déclaration DOCTYPE qui suffit à détruire tout l'affichage (!). Pour le premier cas, je n'ai pas réussi à déterminer ce qui a produit ce changement.
Modifié par hibou57 (04 Nov 2007 - 00:08)
Par dessus le marché, l'ajustement effectué avec les commentaires ne doit pas être le même selon les espaces et les sauts de ligne qui précèdent les commentaires ajoutés pour corriger le bug. Si vous supprimez des espaces avant les commentaires, il faudra parfois ajouter autant de commentaires supplémentaires.

..... comment c'est possible ça ? Smiley langue
Modifié par hibou57 (04 Nov 2007 - 05:14)