Numéro de ligne et de colonne dans u tableau

Bonjour,

Pour calculer la distance entre la position de la souris et les bords d'une cellule de tableau, j'ai besoin de calculer la position de cette cellule dans la page. Je remonte donc l'arborescence des objets jusqu'à la balide Body, en additionnant les positions relatives de chaque objet par rapport à son parent.

Ca marche très bien dans FireFox, mais IE ne tient pas compte des valeurs de padding des cellules #@!!. J'ai donc un décalage égal au nombre de rangées/colonnes pour aller jusqu'à ma cible. Et comme il y a des tableaux imbriqués, avec des paddings différents, c'est pas simple ! Si je code les corrections en dur, bonjour la maintenance des pages !

Il me faut donc connaitre, pour la cellule donnée (fournie par l'objet this.offsetParent de l'évènement onclick d'un objet de la cellule), le numéro de ligne et le numéro de colonne pour multiplier le padding par cette valeur et corriger la position obtenue.

Je suppose qu'on peut faire une fonction itérative qui remonte jusqu'au premier objet node du niveau courant, mais cela me paraît très lourd pour une utilisation fréquente et rapide. Utilisant d'autres languages objet que javascript, j'ai l'habitude d'utiliser la propriété "index" des collections. Y-a-il l'équivalent en javascript ? Sinon, quelqu'un peut-il fournir une micro-routine bien optimisée pour déterminer le numéro de ligne et de colonne d'une cellule (que l'on pourrait par exemple implémenter dans le prototype de l'objet td) ?

Merci d'avance.

bonjour,

>>connaitre, pour la cellule donnée le numéro de ligne et le numéro de colonne

cellIndex et rowIndex ( "bien sûr" sur le parent, le tr )

exemple ici

ah... ces différences entre navigateurs !

Cordialement     Bul    [mon Site] [M'écrire]

peut-être pas été clair ?
cellIndex sur la cellule et rowIndex sur le parent de cette cellule , le tr

Cordialement         Bul        [mon Site]      [M'écrire]

Merci, ça marche au poil !

Mais aucune trace de cellIndex ni de rowIndex dans la masse de doc dont je dispose, ni dans SelfHTML (http://fr.selfhtml.org/javascript/) ! Il est extrêmement difficle de trouver un bouquin de référence exhaustif (et à jour !).
Javascript me gonfle énormément : non content de n'être ni déclaratif ni typé,  la plupart des erreurs se contentent de planter le code sans avertissement, et comme on ne peut pas faire de pas à pas, il est long et difficile de mettre le code au point tant qu'on n'est pas expert. Le gestionnaire d'erreur de l'objet window ne sait même pas détecter une faute de syntaxe. C'est de loin le langage que j'ai le plus de mal à assimiler et à déboguer.

En plus, le fonctionnement du code est différent selon le navigateur utilisé !!!

Vive le C++  et le VB (et à la rigueur le PHP) !

>>Il est extrêmement difficle de trouver un bouquin de référence exhaustif (et à jour !).
oh oui ! c'est le plus gros souci

>>non content de n'être ni déclaratif ni typé, 
pas typé d'accord, j'avoue que ça me plairait plutôt ( pas toujours ),
perso c'est le c++ qui me gonflerait à ce niveau !

>>la plupart des erreurs se contentent de planter le code sans avertissement, ( si si ** )
>>et comme on ne peut pas faire de pas à pas,  ( si si ** )
>>Le gestionnaire d'erreur de l'objet window ne sait même pas détecter une faute de syntaxe.  ( si si ** )
>>C'est de loin le langage que j'ai le plus de mal à assimiler et à déboguer.
pas simple effectivement de debugger, mais avec le paramétrage adhéquat et
les outils adaptés, ça va beaucoup mieux :

FireFox	regarder la "console d'erreurs" Outils / Console d'erreurs et mieux : télécharger FireBug
Internet Explorer	activer le deboggage : Outils/options Internet/Avancés dans la liste, sous "Navigation" : décocher o Afficher une notification de chaque erreur de script o Désactiver le débogage de Scripts (Internet Explorer) et mieux : télécharger le Debogger IE voir aussi : DebugBar et Companion JS
K-Meleon	regarder la "console d'erreurs" Outils / Console d'erreurs
Opera	regarder la "console d'erreurs" Outils / Avancé / Console d'erreurs
Safari	regarder Debug / Show JavaScript Console ° modifier Fichier Preferences.plist situé dans le répertoire : Support:\Documents and Settings\utilisateur \Application Data\Apple Computer\Safari\ y ajouter <key>IncludeDebugMenu</key> <true/>

** l'impératrice.

Cordialement     Bul   [mon Site] [M'écrire]

Merci beaucoup beaucoup. Ca c'est du conseil de pro !
Ca change des yakafautquon que l'on trouve habituellement sur les forums (et qui viennent souvent de vrais).

Je viens d'installer firebug et c'est LA révélation. Du pas à pas avec visualisation des variables ! Je vais peut-être changer d'avis sur javascript... Je verrai après avoir installé le débogger IE.
K-Meleon connait pas, mais par contre j'utilise parfois Konkeror (Linux).
Et comme j'ai pu voir, sur Mac c'est toujours aussi simple...

Il n'en reste pas moins qu'il faut souvent faire du code différent pour chacun des des navigateurs du marché. Ca me rappelle l'époque où chaque marque d'ordinateur avait son propre langage (c'était l'époque pré-Bill Gates). Quand le W3C tapera-t-il sur la table ?

le debugger cité de IE est, je trouve, moins bon que FireBug
( celui associé au VBScript/JavaScript, Microsoft Visual Studio\Common\IDE\IDE98\MSE.EXE
  un peu meilleur, IDE HTML/JS et VBScript ),
 ce n'est que mon avis. chacun ces goûts, et la caravanne passe.

>>K-Meleon connait pas
ce fût longtemps mon navigateur de base, car le plus véloce
tout en étant compatible avec les sites que je fréquente ( pas le cas de safari par exemple !)
mais, je trouve qu'aujourd'hui, FF(3) fait mieux
mon souci ( modem 56k au mieux de sa forme ) c'est la rapidité
je devrais pouvoir passer à l'ADSL ( j'espère ), et là mes
critères de choix changeront.

>>Il n'en reste pas moins qu'il faut souvent faire du code
>>différent pour chacun des des navigateurs du marché
quand on reste dans des choses "standards", enfin "classiques" pour mieux dire,
les différences ne sont pas si fondamentales que cela,
mais c'est vrai : hélas, 3 fois hélas...

c'est le cas, finalement, avec tous les langages,
si on change de machine, de constructeur, d'OS, de version...    ;o)

le W3C ne fait que des recommandations, il n'a aucun pouvoir,
ce ne sont ni des "standard" ni des "normes", avec 20 ans de
retard sur l'existant pour ne critiquer que cet aspect !

chacun n'en respecte que ce qui l'arrange,

pour le coup IE  est le moins respectueux, parait-il.
généralement avec le bon doctype presque "tout" se règle

Cordialement     Bul   [mon Site]  [M'écrire]