11548 sujets
JE pense que les deux notations document.getElementById et document.forms[...].elements[...] sont équivalentes lorsqu'il sa'git des éléments de formulaire. Par contre pour les autres tableaux de l'objet document genre document.images ou document.embeds, je pense que la compatibilité est moins grande.
Document.getElementById étant en général plus court, j'opte personnellement pour ce dernier mais les deux fonctionnent.
Par contre, il faut éviter la notation document.formulaire.element qui est obsolète bien que fonctionnelle encore sur IE.
Document.getElementById étant en général plus court, j'opte personnellement pour ce dernier mais les deux fonctionnent.
Par contre, il faut éviter la notation document.formulaire.element qui est obsolète bien que fonctionnelle encore sur IE.
Bonsoir,
Ce qui suit ne correspond à aucune règle, bonne pratique, norme quelconque.
Cela ne correspond qu'à une expérience personnelle.
Un autre fil de discussion sur ce forum parlait de portabilité.
Dans cette optique,
1/ document.forms[n].elements[n]
est une écriture plus facilement portable que
2/ getElementById()
Si on considère le portage d'un code source d'un langage vers un autre on préfère que les données ou structures de données soient exprimées par des syntaxes de définition de données ou structures de données plutôt que par des fonctions.
Si je prends l'exemple d'un portage Javascript vers C, il faut de toutes façons que je décrive ma structure document, ma structure forms, ma structure elements.
Ceci fait, si j'ai recours à l'écriture n°1, le transcodage sera immédiat.
Si j'ai recours à l'écriture n°2, il faudra en plus que je code la fonction getElementById().
Je reconnais que l'argument est spécieux car qui voudrait porter un code JS en C ?
Je ne mentionnais de différence qu'en termes de portabilité.
Dans les faits, pour avoir en revanche porté du code C en JS, c'est évidemment la première écriture qui s'impose immédiatement.
Modifié par aCOSwt (23 Feb 2007 - 20:43)
Ce qui suit ne correspond à aucune règle, bonne pratique, norme quelconque.
Cela ne correspond qu'à une expérience personnelle.
Un autre fil de discussion sur ce forum parlait de portabilité.
Dans cette optique,
1/ document.forms[n].elements[n]
est une écriture plus facilement portable que
2/ getElementById()
Si on considère le portage d'un code source d'un langage vers un autre on préfère que les données ou structures de données soient exprimées par des syntaxes de définition de données ou structures de données plutôt que par des fonctions.
Si je prends l'exemple d'un portage Javascript vers C, il faut de toutes façons que je décrive ma structure document, ma structure forms, ma structure elements.
Ceci fait, si j'ai recours à l'écriture n°1, le transcodage sera immédiat.
Si j'ai recours à l'écriture n°2, il faudra en plus que je code la fonction getElementById().
Je reconnais que l'argument est spécieux car qui voudrait porter un code JS en C ?
Je ne mentionnais de différence qu'en termes de portabilité.
Dans les faits, pour avoir en revanche porté du code C en JS, c'est évidemment la première écriture qui s'impose immédiatement.
Modifié par aCOSwt (23 Feb 2007 - 20:43)
aCOSwt a écrit :
Et ça c'est gratuit.

Non, c'est aussi mon avis que ton message est hors-sujet et donc dans le contexte de ce sujet "farfelu" càd d'après mon Petit Larousse "bizarre" (extravagant, fantasque).
Je doute que quelqu'un utilise dans les 5 ans à venir du C côté client pour accéder au DOM, et encore moins sans une bibliothèque permettant l'accès direct à un id ou même un support complet de XPath tant qu'à faire. </fin du HS que je viens de nourrir

Laurent Denis a écrit :
Merci de ne pas poursuivre cette (obscure) croisade ici. Là, on va finir par se fâcher, je le crains![]()
Une sanction est plus que jamais d'actualité, au prochain post qui aura le malheur de me déplaire ... Du moins si Laurent Denis ne le fait pas au saut du lit pour ce propos-là.
a écrit :
Du moins si Laurent Denis ne le fait pas au saut du lit pour ce propos-là.
...et visiblement il n'est pas du matin Laurent Denis... Ca sanctionne dur ces derniers temps...

Merci de pardonner mon incrustation outrecuidante et désinvolte dans cette discussion.

Modifié par Ralfman68 (24 Feb 2007 - 08:44)
ggmt95 a écrit :Ne crois-tu pas que si tu faisais preuve d'un peu de politesse, les membres du forum auraient plus envie de te répondre ?
Existe-t-ils des documents définissant ce qui est obsolète ou non.
Bonjour, bonsoir et bonne après-midi
Désolé d'avoir été discourtois mais le style des pseudo-réponses apportées à ma question préalable et le ton règlement de compte des "répondeurs" ont réellement éloignés de moi les règles de politesses exigées sur ce forum.
D'ailleurs, 8 sur 10 des interventions dont celle qui demande plus de ... ne salue pas les lecteurs.
C'était la première fois que j'intervenais. Soyez rassurés je ne recommencerais plus.
Je vous laisse à vos salades et
A tchao bon week end
Désolé d'avoir été discourtois mais le style des pseudo-réponses apportées à ma question préalable et le ton règlement de compte des "répondeurs" ont réellement éloignés de moi les règles de politesses exigées sur ce forum.
D'ailleurs, 8 sur 10 des interventions dont celle qui demande plus de ... ne salue pas les lecteurs.
C'était la première fois que j'intervenais. Soyez rassurés je ne recommencerais plus.
Je vous laisse à vos salades et
A tchao bon week end
Salut,
Modifié par Thomas D. (24 Feb 2007 - 17:16)
ggmt95 a écrit :Le tutoiement est généralement utilisé sur le forum, cela contribue à maintenir une atmosphère détendue et rend les échanges un peu moi formels. Moi j'aime bien. Est-ce que ça pose sérieusement un problème ?
nb
Peut-être que le summum de la politesse est de tutoyer les gens que l'on ne connait pas.
a écrit :Les interventions des modérateurs sont un mal nécessaire pour que le forum puisse continuer à fonctionner correctement. Merci de faire preuve d'un peu de patience. Après tout, les membres fournissent une aide précieuse bénévolement. Il est un peu malvenu de se plaindre parce qu'un sujet n'a pas trouvé de réponse ou a dévié de son but initial, je trouve.
Désolé d'avoir été discourtois mais le style des pseudo-réponses apportées à ma question préalable et le ton règlement de compte des "répondeurs" ont réellement éloignés de moi les règles de politesses exigées sur ce forum.
Modifié par Thomas D. (24 Feb 2007 - 17:16)
ggmt95 a écrit :
A l'heure actuelle, vaut-il mieux utiliser dans un script JS getElementById() ou la notation du genre document.forms[n].elements[n]....
Existe-t-il des documents recommandant l'un ou l'autre?
Les deux sont parfaitement valables. Le premier fait partie du DOM normal, donc valable pour tous les documents HTML et XML, correspondant à un élément dont un attribut, non pas nommé id, mais étant de type ID ( renseigné dans la DTD (ou un schéma XSD)) de valeur spécifiée.
Le deuxième fait partie du DOM-HTML. Il définit une HTMLCollection sur l'objet document. On peut y mettre le numéro de form, ou alors un id. Donc les deux écritures suivantes sont équivalentes :
document.getElementById('monForm');
document.forms['monForm']
Après un objet HTMLForm a aussi une collection nommée elements avec tous les éléments de formulaire. Apparemment, faudrait les accéder par id, maintenant je sais pas ce que ça donne niveau implémentation
a écrit :
Après un objet HTMLForm a aussi une collection nommée elements avec tous les éléments de formulaire. Apparemment, faudrait les accéder par id, maintenant
L'id a en effet la priorité sur name pour ce qui est de l'indice du tableau elements.
Mais il est toujours possible d'utiliser le numéro d'ordre...
Et si tu tiens à garder le name, document.getElementsByName existe toujours.
FlorentG a écrit :C'est standard. Par contre, le support est un peu chaotique.
Je crois que celui-là n'est pas du tout standard, et ne fonctionne pas partout, nan ?
Modifié par Julien Royer (26 Feb 2007 - 15:21)
bonsoir
pourquoi pas l'utilisation de l'attribut 'name' aussi bien pour l'élémént formulaire que pour les éléments contenus dans ce formulaire :
Il est facile d'accéder aux éléments par leur propriétés :
ce qui pemet une certaine indépendance par rapport au tableaux forms[ ] et elements[ ] qui suivent la structure du document ...Si l'on rajoute ou modifie la structure on risque de modifier l'indexation dans les tableaux ..
Modifié par kzone (26 Feb 2007 - 22:39)
pourquoi pas l'utilisation de l'attribut 'name' aussi bien pour l'élémént formulaire que pour les éléments contenus dans ce formulaire :
<form name="formulaire" .....>
<input name="nom" ..... />
<input type="radio" name="choix" .../>
....ect
</form>
Il est facile d'accéder aux éléments par leur propriétés :
document.formulaire.nom;
document.formulaire.choix[0];
....
ce qui pemet une certaine indépendance par rapport au tableaux forms[ ] et elements[ ] qui suivent la structure du document ...Si l'on rajoute ou modifie la structure on risque de modifier l'indexation dans les tableaux ..
Modifié par kzone (26 Feb 2007 - 22:39)
Bonsoir à vous et merci pour les pistes
Il semblerait que dans le cadre xhtml, l'id est privilégié par rapport au name dans les formulaires.
De plus, l'utilisation du name dans la notation pointée serait déconseillée au profit de forms['name'] ou mieux forms['id'].
Bien compliqué sans norme.
Bonne soirée
Il semblerait que dans le cadre xhtml, l'id est privilégié par rapport au name dans les formulaires.
De plus, l'utilisation du name dans la notation pointée serait déconseillée au profit de forms['name'] ou mieux forms['id'].
Bien compliqué sans norme.
Bonne soirée
