Probleme point insertion sur input avec IE6

[fredmac75]

Bonjour à toutes et à tous,

j'ai un petit soucis, j'ai une page sur laquelle j'ai trois formulaires :
- un formulaire de log
- un formulaire de recherche
- un formulaire d'inscription

Mon problème sous IE6 est qu'il m'est impossible d'avoir la barre de pointeur (avec la souris) pour la saisie dans le second formulaire. Les deux autres fonctionnent très bien (y compris sous IE6). Sous FF , Safari et opéra tous passe nickel.
Voir la pièce jointe 18842


Par ailleurs, l'utilisation du TAB me permet d'accéder au champ problématique et de le remplir ???

Quelqu'un a-t-il déjà rencontré ce problème, et comment l'a-t-il résolu ?

Pour ceux qui veulent, je peux leur envoyer un zip du site pour qu'ils puissent jeter un œil au code (Par MP SVP)

Merci

 

[fredmac75]

Yep,

J'ai réussi à isoler le problème...
mon formulaire <form> dispose d'un background en png 24 (le cartouche avec le gradient vers foncé-> vert clair). Pour IE6 je passe donc par un Filter. Or il semblerait que la suppression de ce style spécifique (j'utilise une css dédié pour ie avec un appel conditionnel) remette les pendules à l'heure. Je peux à nouveaux utiliser le champs (pointer OK)

Il semblerai que je doive arbitrer entre le png 24 avec filter et l'utilisation même du champs input pour IE6.
Avez-vous déjà rencontré ce type de problème ?

Merci pour vos suggestions

 

[p4bl0]

Est ce que tu ne pourrais pas utiliser un png non 24-bit pour IE plutôt qu'un filtre sur un png 24 ?
Vue que c'est des backgroudn donc dans le css, je sais que sur c'est faisable, mais ma question c'est plus présisément :
Est ce que Busineo accepterait d'avoir une apparence l'égèrement différente (sans le dégradé ? avec un autre dégradé "moins parfait") dans IE6 ?

Sinon c'est un peu crade mais je suppose que si on y a plus accès via le clique, c'est que le filtre pour doit faire passer un élément "par dessus" le champ texte. Une solution (crade je le redis) serait de mettre en JS uniquement si c'est IE un focus sur le champ texte si on clique sur la zone ou il se situe ?
(puisque le focus est possible quand tu y vas avec tab, ça doit se faire aussi via JS avec un .focus()).

Sinon, je vois pas... Ah si! On pourrait éradiquer IE6 et les utilisateurs récalcitrants (ou les admin qui oblige sn utilisation)

 

[fredmac75]

malheureusement la "gracefull degradation" est un concept assez mal compris par le client...

Visiblement des pistes se trouvent ici et là...

il semblerait que le problème soit particulièrement retord à résoudre, mais faut-il s'en étonner.

Moi j'avais imaginé un système de paiement pour toute consultation à partir d'IE6...
"Vous utilisez actuellement IE6 pour consulter notre site, nous sommes au regret de vous demander de vous acquitter de la somme de XX &#8364;"

 

[Anonyme]

Hop

 

[fredmac75]

Visiblement nous avons les mêmes sources... finalement la toile n'est pas aussi grande que l'on veut bien le dire. Merci

 

[fredmac75]

Problème réglé.

Dans mon cas il a suffit d'appliquer à l'élément posant problème (input) contenu dans le form

input {position:relative;}

Balise form à laquelle était appliquée le background utilisant le png 24 et donc le filtre.

Ce faisant le champ retrouve sa pleine fonctionnalité sous IE6 ; point d'insertion avec la souris

Pfuiiiiii....

 

[momo-fr]

Good job Fred, si jamais j'ai le même souci j'ai la solution... mais j'utilise très peu le png, j'attends encore une bonne année que IE6 tombe dans la poubelle des navigateurs...

 

[obi wan]

Problème réglé.

Dans mon cas il a suffit d'appliquer à l'élément posant problème (input) contenu dans le form

input {position:relative;}

Hahaha il nous fera toujours autant rire IE. Merci à Microsoft pour tous ces grands moments de distraction qu'ils apportent aux dév web, c'est gentil, vraiment.

Et tu étais absolument obligé de mettre du PNG ?

 

[fredmac75]

Salut à tous,

En fait j'utilise png-24 lorsque j'ai un élément avec un background en gradient et un élément enfant qui contient lui-même un background gradient ; ce qui est le cas sur l'image ci-dessus.

L'intérêt pour moi et de pouvoir laisser une mise en page propre si l'utilisateur venait à diminuer ou augmenter la taille sa typo. Ce qui ne serait pas le cas avec un gif ou un png-8.

"GraceFull degradation"...

 

[p4bl0]

Mmm d'habitude je le trouve bidon le blog css4design... souvent des tips vieux comme le monde ou des truc inintéressant ou du moins pas du niveau qu'on attends de son auteur vu comment il se présente...

Mais j'avoue que cet article là est intéressant.

En tout cas au moins on sait comment gérer ce problème là maintenant

 

[obi wan]

Au passage, ça c'est pas mal du tout --voir la v2 aussi, c'est à propos d'IE et de png, mais pas que, et c'est bien utile

arf css4design, du commerce tout ça, du pur et beau commerce bien commercial... mais bon ça a l'air de marcher

 

[p4bl0]

Au passage, ça c'est pas mal du tout --voir la v2 aussi, c'est à propos d'IE et de png, mais pas que, et c'est bien utile

arf css4design, du commerce tout ça, du pur et beau commerce bien commercial... mais bon ça a l'air de marcher

Ouaipe j'ai utilisé ça pas mal de fois, ça marche plutôt bien !

Par contre faut bien utiliser des commenraires conditionnel pour l'utiliser avec IE6 ou moins seulement, sinon ça fait des trucs étrange

 

[Anonyme]

IE7.js c'est bien joli mais le mieux c'est quand même les commentaires conditionnels et les hacks pour IE dans une css séparée parce que si vos visiteurs utilisent IE6 et en plus désactivent javascript*, il va être beau votre design.




*très improbable mais bon…

 

[obi wan]

J'ai pas dit que c'était du tout cuit Je postais surtout le lien à propos du png dans IE.
Personnellement je n'utilise pas le png c'est trop lourd, mais parfois ça peut etre indispensable (ou plutôt un gain de temps énorme notamment quand on fait des sites administrables où les photos doivent être 'habillées', on évite de passer par la case 'manip côté serveur' autre que redimensionnement ou crop).
Il y a de bons bouts de code dans ce IE7.js (et y'a des trucs super stylés codistiquement parlant, vraiment élégant ). Évidemment si on utilise deja des trucs genre prototype.js ça fait ptetre un peu double emploi, mais bon, le lien est bon à prendre tout de même

@gloupgloup >> les gens qui désactivent javascript sont censés savoir qu'ils l'ont fait
Et puis, quand un client veut (absolument) du bling bling (pas cher évidemment), il a le blingbling mais pas la couche en dessous, et son site marche pas sans JS, et tant pis pour lui on l'aura prévenu c'est sa faute il avait qu'à pas soûler avec ses ptits pioupiou qui doivent absolument bouger, na mais non, mais non, j'ai passé une super semaine je vous jure ^^

 

[fredmac75]

C'est vrai que png-24 rend souvent des images plus lourde, et oblige à une gestion spécifique pour ie6 (dans tous les cas, je suis obligé de faire une css spécifique).

Avec png-8, je serais moins affirmatif quand à la différence de poids avec gif.

Mais je préfère malgré tout une "petite" surcharge pondérale si celle-ci permet à l'utilisateur de pouvoir afficher le site avec ses réglages sans que cela ne vienne mettre la zizanie dans le design...

Enfin, je suis très attentif au poids des pages. Les pages du site sur lequel je travail actuellement (l'image du premier post) font dans les 120k (+/- 20k), ce qui me semble être tout à fait convenable. Surtout si l'on tient compte de l'implémentation d'un Jquery et autres plug-in.

Pour le script de Dean, je le connaissais mais j'ai eu peur de l'utiliser en prod et de me retrouver avec un cas de figure dans lequel cela ne fonctionnerai pas ; et donc devoir refaire à la mano la css dédiée.

Néanmoins, si vous avez des retours sur des mises en prod, je suis preneur.

 

[Benjamin D.C.]

Néanmoins, si vous avez des retours sur des mises en prod, je suis preneur.

Si c'est en théorie une solution miracle, les résultats auxquels j'ai pu me confronter ne me laissent guère de bons souvenirs…

Pour des tests simples, ça fonctionne plutôt bien, mais une fois confronté à des mises en pages complexes, les résultats sont souvent peu prévisibles et difficilement débuggables. J'aurais tendance, pour ma part, à déconseiller son utilisation en prod…