La méthode getElementById() est devenue inutile ?

Version imprimable

exemple
Code:

1 2 3 4 5 6 7 8 9 <!DOCTYPE html> <html lang="fr"> <head><meta charset="UTF-8" /></head> <body> <span id="truc">texte initial...</span> <script> truc.innerText = 'bla bla bla'; </script> </body></html>
et ça marche!
J'ai "rapidement et mal" cherché , je n'ai trouvé aucune new ou info sur le sujet.
l'impression d'avoir raté un train..

Est-ce LA bonne pratique et on doit abandonner la méthode getElementById ??

18/11/2018, 21h35
Beginner.

Salut,

Ce point a déjà été discuté dans ce forum mais je ne sais plus où...
Cette pratique peut poser problème*, NoSmoking en avait parlé mais je ne sais plus où...

*Que se passe-t-il si l'ID correspond au nom d'une variable ? Ou si L'ID vaut "document" ou "windows" ou... ?

PS : Ailleurs on a ceci : Directly reference HTML elements... Dans lequel il y a les liens de deux autres fils...
19/11/2018, 11h19
Invité

Bonjour,

1- il ne faut pas confondre "ce qui est possible" et "ce qui est recommandé".
Ce n'est pas parce qu'on PEUT traverser en dehors des clous qu'on DOIT le faire...

2- J'ajoute qu'à partir du moment où on laisse le programme "décider" ce qu'il doit faire, on en perd la maitrise.
D'où l'importance d'utiliser "use strict", et de toujours déclarer les variables.

N.B. En ne lisant que le titre ("La méthode getElementById() est devenue inutile ?"), j'avais plutôt pensé :
Oui, dans le sens où on peut désormais utiliser à la place querySelelector().
19/11/2018, 13h48
psychadelic
Perso, je trouve que tout ce qui peut alléger le code est bienvenu, et permet d'éviter des erreurs de codage.

Donner des noms explicites au variables est vital pour la survie d'un code; voit trop souvent des choses du genre
Code:

1 2 3 Prix_1 = document.getElementById("Prix_1"); Prix_2 = document.getElementById("Prix_2"); Prix_3 = document.getElementById("Prix_3");
alors qu'il s'agit tout simplement de Prix_Hors_Taxe, montant_TVA et Prix_net...

et franchement quel est l'intérêt d'écrire en 2 lignes ce qui peut se faire en une seule, et qui divise par 2 le risque de faute de frappe au clavier ;)
Code:

1 2 Prix_Net = document.getElementById("Prix_Net"); Prix_Net.innerText =...
en revanche, pour la minification optimisée de code, c'est pas forcément un cadeau, sauf à minifier aussi le code HTML et le code CSS...
:? d'ailleurs je me demande si ça existe (un tripe minifieur [html,css,js] qui puisse y réaffecter les noms de variables longues) ??
19/11/2018, 14h33
Invité

1- Personne t'empêche d'écrire :

Code:

document.getElementById("Prix_Net").innerText .....

Après... tu fais comme tu veux.

2- Je ne vois pas bien le rapport entre "Donner des noms explicites" et TA question initiale...
Si tu trolles tes propres discussions... :roll:

3- Reprenons ton 1er exemple.
Si, en amont de ton code, il existe un script, un autre bout de code, perdu dans la masse de lignes de code de multiples scripts importés ou rédigés par toi, où il est écrit :

Code:

var truc = 'machin';

Alors ton bout de code se prend le mur...
ET t'as l'air malin, avec ton code "allégé" !
19/11/2018, 16h26
psychadelic

:)
Justement c'est pour cela que j'ai parlé de noms explicites.
(et bien sur appeler ses variables truc machin ou bidule est aussi peu explicite que Prix_1, _2.. ou pire id="window" or id="document" comme le suggère Beginner dans son premier post et auquel ma réponse des "noms explicites" faisait référence.

quand à utiliser document.getElementById("Prix_Net").innerText ok, mais quand on doit se retrouver à écrire un peu partout dans son code ces 35caratères, surtout pour utiliser au final le même nom de variable (explicite) que celui de l'Id qui lui est attribué, alors si, on allège le code de 27caracteres à chaque fois.
19/11/2018, 16h36
Invité
LOL,
Trop fort...
Tu arrives à être hors sujet dans ta propre discussion ! :ccool:

Dans ce cas, tu fais :
Code:

1 2 var pn = document.getElementById("Prix_Net"); pn.innerText =...
Et tu gagnes encore 6 caractères... :bravo:
19/11/2018, 17h01
psychadelic
ben non,
Code:

1 2 var pn = document.getElementById("Prix_Net"); pn.innerText =...
ça fait dans les 60c
alors que Prix_Net ça fait juste 8c

donc il faut utiliser ton système au moins 8 fois pour pour économiser des caractères, sans oublier que pn est tout sauf un nom de variable explicite, qui ne permet pas du premier coup d’œil de savoir qu'il renvoi à l'élément dont l'id="prix_net".

Parfois je ne comprends pas du tout le cheminement de ton raisonnement: je ne vois en rien en quoi ce que j'ai écris puisse être en dehors développement proposé par [B]Beginner[/B dans mon sujet; et auquel tu toi même répondu.
19/11/2018, 17h08
CosmoKnacki

Citation:

Envoyé par jreaux62

N.B. En ne lisant que le titre ("La méthode getElementById() est devenue inutile ?"), j'avais plutôt pensé :
Oui, dans le sens où on peut désormais utiliser à la place querySelelector().

D'un point de vue purement fonctionnel oui, mais ce n'est pas le cas du point de vue du style d'écriture, qui consiste à afficher une intention claire en utilisant la méthode la mieux adaptée au besoin (ici je veux un élément à partir de son id => j'utilise getElementById, y'a pas d'erreur de casting), ni du point de vue du travail nécessaire: getElementById renvoie un élément en passant son paramètre à un hash alors que querySelector en est encore à parser son expression pour savoir ce qu'on lui demande.
Plus généralement, si les sélecteurs css peuvent exprimer des chemins simples d'une manière qui est familière au développeurs css, on reste très loin de l'efficacité et du pouvoir expressif de libxml.

Maintenant pour en revenir à truc.innerText = 'bla bla bla', je ne l'écrirai pas pour deux raisons, la première étant celle que les autres ont déjà évoquée (le risque de télescopage avec une variable), l'autre étant qu'une propriété comme innerText ne devrait être autorisée qu'en lecture et pas en écriture. Là encore, il ne faut pas forcément succomber à toutes les facilités qu'offre un langage.
19/11/2018, 17h10
SpaceFrog

J'imagine ...

Code:

<div id="body">

:salut:

Cette technique me semble hasardeuse pour des raisons déjà dites dans cette discussion.

On peut mettre un peut de discipline en commençant systématiquement un ID par "id", exemple : "idCamelCase".

Dans ce cas, le risque de collision est réduit, mais non nul avec d'autres variables et la réponse "un ID doit être unique dans la page web" est une vedette du forum.

C'est la raison pour laquelle j'utilise toujours la fonction kIDUnique();, elle est incluse dans mon fichier "https://danielhagnoul.developpez.com/lib/dvjh/dvjhUtilities-1.8.4.js", voir mon blog

J'ai fait quelques tests, la technique fonctionne en mode strict et dans un script externe, même dans un module externe.

Code:

<span id="idBody">texte initial...</span>

module:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 window.addEventListener('load', ev => { // le DOM est construit et la page web est visible console.log(`Window load : ${new kDvjhDate()}`); // début code du test console.log(typeof idBody); // object idBody.innerText = 'bla bla bla'; // fin code du test kIDUnique(); }, { capture: false, passive: true, once: false });

22/11/2018, 17h24
NoSmoking

Bonjour,
outre le fait que bien que faisable cela reste une mauvaise façon de faire, initiée par IE dans ses exemples au siècle dernier, pour diverses raisons dont celles déjà mentionnées, je ne comprends pas plus que cela tes angoisses concernant :

Citation:

Envoyé par psychadelic

donc il faut utiliser ton système au moins 8 fois pour pour économiser des caractères, sans oublier que pn est tout sauf un nom de variable explicite, qui ne permet pas du premier coup d’œil de savoir qu'il renvoi à l'élément dont l'id="prix_net".

Citation:

Envoyé par psychadelic

quand à utiliser document.getElementById("Prix_Net").innerText ok, mais quand on doit se retrouver à écrire un peu partout dans son code ces 35caratères, ...

tu n'as jamais entendu parler de la « mise en cache des variables », le mieux étant de les mettre dans un « namespace » c'est plus verbeux mais tellement plus lisible.

Citation:

Envoyé par psychadelic

...on allège le code de 27caracteres à chaque fois.

Cette discussion devrait t’intéresser : [Ludique] Défis code en un tweet, bonne lecture.
22/11/2018, 17h53
Invité

Citation:

Envoyé par NoSmoking

Cette discussion devrait t’intéresser : [Ludique] Défis code en un tweet, bonne lecture.

Tu as oublié de préciser qu'à l'époque, les tweets ne faisaient que 140 caractères ! ;)
22/11/2018, 20h07
danielhagnoul

Citation:

Envoyé par NoSmoking

Bonjour,
[...] cela reste une mauvaise façon de faire, initiée par IE dans ses exemples au siècle dernier, [...]

C'est donc un bon exemple pour mon billet de blog : JavaScript est-il malade de la compatibilité ascendante ?
23/11/2018, 00h09
psychadelic

Citation:

Envoyé par NoSmoking

tu n'as jamais entendu parler de la « mise en cache des variables », le mieux étant de les mettre dans un « namespace » c'est plus verbeux mais tellement plus lisible.

Qu'en sais tu ?
et pourquoi ce reproche gratuit ?

Citation:

Cette discussion devrait t’intéresser : [Ludique] Défis code en un tweet, bonne lecture.

non, ça ne m'intéresse pas, c'est même aux antipodes de ce que je recherche dans du code, comme je l'ai écrit plus haut.

Citation:

Donner des noms explicites aux variables est vital pour la survie d'un code;

Et donner juste 2 lettres pour nommer une variable globale, c'est tout sauf une pratique acceptable.
23/11/2018, 12h04
NoSmoking

Citation:

Qu'en sais tu ?

c'était plutôt à prendre comme une question.

Citation:

et pourquoi ce reproche gratuit ?

ce n'est pas un reproche mais un conseil et qui plus est gratuit comme tout ce que j'écris sur le forum.

Concernant ton questionnement de départ « La méthode getElementById() est devenue inutile » la réponse t'a était fournie et c'est toi même qui a dérivé sur un autre sujet « bonne/mauvaise manière de coder » dont je t'ai fourni matière à réflexion dans le lien.

Si tu ne veux pas d'avis contradictoires alors ne pose pas de question.
23/11/2018, 15h32
psychadelic
Bon, on va reprendre depuis le début en évitant de faire des sous-entendus négatifs.

1 – je découvre qu’il est possible, en JS, d’utiliser directement le nom de l’id d’un élément HTML, au lieu d’en passer par un getElementById.

Et je m’interroge (dès mon premier Post) :

Citation:

Est-ce LA bonne pratique et on doit abandonner la méthode getElementById ??

2 - Le premier à répondre est Beginner avec dans sa réponse :

Citation:

Que se passe-t-il si l'ID correspond au nom d'une variable ? Ou si L'ID vaut "document" ou "windows" ou... ?

3- Ce à quoi jreaux62 lui répond :

Citation:

1- il ne faut pas confondre "ce qui est possible" et "ce qui est recommandé".
Ce n'est pas parce qu'on PEUT traverser en dehors des clous qu'on DOIT le faire…

Ce qui est complètement ambigu car il ne définit pas "ce qui est recommandé"
a) il n’est pas recommandé d’utiliser directement le nom de l’ID ?
b) il n’est pas recommandé de donner des noms d’ID qui soient identiques à ceux des éléments du DOM.

Comme je ne vois pas jreaux62 comme une sorte d’ayatollah du code j’ai directement opté pour la réponse (b),
et j’ai renchéri en répondant notamment :

Citation:

Donner des noms explicites aux variables est vital pour la survie d'un code

Puis est venu un épisode étrange pour un nom de variable « Prix_Net » et pour lequel j’aimerai toujours que l’on m’explique en quoi dans la partie HTML

Code:

<span id="Prix_Net"> </span>

et d’utiliser dans la partie javascript

Code:

Prix_Net.innerText = …

serait quelque chose de : mal, ou ambigu, ou une pratique qui peut poser problème ou je ne sais quoi d’autre. ???

Pour la partie JS vous préféreriez plutôt:
Code:

1 2 3 4 5 Prix_Net = document.getElementById("Prix_Net"); //... plus loin dans lecode... Prix_Net.innerText = …
Ce qui me semble franchement ridicule. (l’une et l’autre passent en mode strict, comme l’a indiqué danielhagnoul. )

Donc le sujet tourne dès le début sur la notion de code propre,
Même si « le namespace c’est formidable » cela n’empêche pas qu’on se retrouvera toujours à vouloir lier un élément HTML avec une variable JS, et que le plus important c’est que ces noms soit suffisamment explicites pour éviter tout ambiguïté dans le code.

Ce que je ne cesse de répéter depuis mon 3eme post et pour lequel je n'ai lu nulle part le moindre « avis contradictoire » qui y réponde.

pour les:

Citation:

Cette technique me semble hasardeuse

Citation:

outre le fait que bien que faisable cela reste une mauvaise façon de faire

Jai déjà répondu en écrivant :

Citation:

le plus important c’est que ces noms soit suffisamment explicites pour éviter tout ambiguïté dans le code

je peux aussi ajouter qu’il est toujours possible d’écrire du mauvais code en utilisant uniquement le getElementById,
et que le plus important encore une fois, c’est d’utiliser des noms de variables explicites et non ambigus.

Il existe une infinité de mauvaises manières de coder, et je ne vois pas en quoi utliser directement le nom de l'ID d'un élément (en prenant garde qu'il n'y ait pas d’ambiguïté et que ce nom soit explicite) puisse être "la chose de trop et frappée de la honte d'avoir été - initiée par IE dans ses exemples au siècle dernier "
23/11/2018, 15h39
Invité
Citation:

Envoyé par psychadelic

...Comme je ne vois pas jreaux62 comme une sorte d’ayatollah du code...

Certainement pas !
Je suis plutôt un "j'aboie-trop-là" ! :mrgreen:

Code:

...Ce qui est complètement ambigu car il ne définit pas "ce qui est recommandé" ...

Alors je vais préciser.

Il est "recommandé", spécialement en JavaScript, de bien déclarer les variables : var... ou let... ou const...
Ne pas le faire (en utilisant directement l'intitulé de l'attribut id *, par exemple), est susceptible d'entraîner des erreurs et/ou confusion (comme ça a été dit plusieurs fois : variable de même nom déclarée ailleurs,...).

* De plus, supposons que le script soit lu par un AUTRE développeur :
Il va voir ce qu'il va prendre pour une "variable non déclarée".
Il va se dire :"Mais où est donc déclarée cette fichue variable ???"

Citation:

... et que le plus important encore une fois, c’est d’utiliser des noms de variables explicites et non ambigus....

Il ne s'agit pas que de "nom explicite".
Il s'agit ici de "VARIABLE EXPLICITEMENT déclarée".

Code:

var pn = document.getElementById("Prix_Net");

Certes, le "nom de la variable" n'est pas explicite.
Par contre, LA VARIABLE est EXPLICITEMENT DÉCLARÉE. Il n'y a aucune ambiguïté possible.

EN CONCLUSION :
- tu PEUX le faire (puisque c'est "possible", sans générer d'erreur JS)
- mais à tes risques et périls
Entre :
- un code comportant moins de caractères
  et
- un code comportant moins de risques potentiels d'erreurs
J'ai fait mon choix.

Et toi ?

Certains jours j'ai quand même l'impression que l'on nous prend pour de Crétins Outrageusement Naïfs

Au passage dans ta récapitulation tu as oublié ta « fixette » sur le nombre de caractères utilisés dans le code.

Citation:

3- Ce à quoi jreaux62 lui répond :

Non pour moi il te répond.

Citation:

Ce qui est complètement ambigu car il ne définit pas "ce qui est recommandé"
a) il n’est pas recommandé d’utiliser directement le nom de l’ID ?
b) il n’est pas recommandé de donner des noms d’ID qui soient identiques à ceux des éléments du DOM.

Comme je ne vois pas jreaux62 comme une sorte d’ayatollah du code j’ai directement opté pour la réponse (b)...

je ne comprend pas pourquoi tu as volontairement zappé la réponse (a).

Citation:

Puis est venu un épisode étrange pour un nom de variable « Prix_Net »et pour lequel j’aimerai toujours que l’on m’explique en quoi dans la partie HTML(...)

c'est quand même toi qui as amené cela sur le tapis et l'explication t'a été fournie, risque de collision et tu auras beau être rigoureux et plus la loi de Murphy ne manquera pas de s'appliquer, à ce sujet plusieurs questions ont été posées sur ce forum et résolues en modifiant les identifiants ou l'approche.
Citation:
Pour la partie JS vous préféreriez plutôt:
Code:

1 2 3 4 5 Prix_Net = document.getElementById("Prix_Net"); //... plus loin dans lecode... Prix_Net.innerText = …
Ce qui me semble franchement ridicule. (l’une et l’autre passent en mode strict, comme l’a indiqué danielhagnoul. )
Commençons pas le mode "use strict", oui cela passe car la variable, non déclarée comme telle, et une propriété de l'objet window une fois le document HTML « parsé », construction de l'arbre DOM et initialisation des objets JavaScript, donc il n'y a aucune raison que cela plante et aucun rapport avec ce qui nous « intéresse » ou pas.

Ce que je pense du bout de code ci-dessus c'est que comme utilisation de « utiliser des noms de variables explicites et non ambigus » on n'est pas au mieux de ce qui peut ce faire sémantiquement parlant.
Pour moi un prix net c'est une valeur et pas un DOMElement.
Code:

1 2 var domElemPrixNet = document.getElementById("Prix_net"); var prixNet = domElemPrixNet.value;
La définition de « nom explicite et non ambigüe » n'est donc pas acquise et chacun y verra ce qu'il voudra.

Citation:

Donc le sujet tourne dès le début sur la notion de code propre,

:koi: ben pas pour moi le sujet de départ n'est pas celui là, revoit le titre que tu as mis.

Citation:

...cela n’empêche pas qu’on se retrouvera toujours à vouloir lier un élément HTML avec une variable JS, et que le plus important c’est que ces noms soit suffisamment explicites pour éviter tout ambiguïté dans le code.

il me semble que c'est une évidence pour tout le monde que de donner des noms qui représentent ce que l'on manipule
Code:

1 2 3 4 5 6 7 function calculTVA(choucroute, age_du_capitaine) { var vélo_tout_terrain; vélo_tout_terrain = choucroute * age_du_capitaine; return vélo_tout_terrain; } var legume_en_boîte = calculTVA(101, .21297); console.log(legume_en_boîte)
bon d'accord c'est un peu extrême.

Citation:

pour les:

Citation:

Cette technique me semble hasardeuse

Citation:

outre le fait que bien que faisable cela reste une mauvaise façon de faire

Jai déjà répondu en écrivant :

tu es hors contexte et tu réponds donc à côté de la plaque mais c'est bien on en prend acte et donc inutile d'aller plus loin.

Citation:

je peux aussi ajouter qu’il est toujours possible d’écrire du mauvais code en utilisant uniquement le getElementById,

et inversement.

Citation:

Il existe une infinité de mauvaises manières de coder,

je confirme

Citation:

et je ne vois pas en quoi utliser directement le nom de l'ID d'un élément (en prenant garde qu'il n'y ait pas d’ambiguïté et que ce nom soit explicite) puisse être "la chose de trop et frappée de la honte d'avoir été - initiée par IE dans ses exemples au siècle dernier "

Faudrait savoir si tu découvres cette mauvaise façon de faire ou si d’après ce que tu écris il semblerait que tu ais appris avec les exemples IE, là pour le coup c'est ambiguë..

Bon nombre de personne ont abandonné cette écriture, qui pour info ne fonctionnait pas sous NetScape, pour se conformer au standard qui même si plus verbeuse à le mérite d'être standard car n'oublions pas qu'aucune obligation n'est faite aux navigateurs de mettre à ta disposition les DOMElement via l'objet window en direct.

Pour conclure, car je trouve que j'ai déjà passé trop de temps à répondre et il suffit de lire ta signature pour se convaincre que l'on n'y changera rien, tu fais bien ce que tu veux et comme tu veux et comme on ne peut rien contre la mauvaise fois.

:dehors:

24/11/2018, 16h04
psychadelic

Citation:

Envoyé par NoSmoking

Pour conclure, car je trouve que j'ai déjà passé trop de temps à répondre et il suffit de lire ta signature pour se convaincre que l'on n'y changera rien, tu fais bien ce que tu veux et comme tu veux et comme on ne peut rien contre la mauvaise fois.
:dehors:

J'ai pris l'habitude avec toi, déjà que tu réponds pas à mes MP... :roll:

Perso, j'ignorais completement l'histoire de cette possibilité introduite sous IE et non reconnue par Netscape.

Ce que je retiens aujourd'hui, c'est que toute ID placée sur une page web donne automatiquement une création d'une variable JS lui correspondant.
et qu'on le veuille ou non cette variable existe bel et bien quel que soit le navigateur (à jours en 2018) qu'on puisse utiliser.

Conclusion on à intérêt à faire gaffe aux nom des ID que l'on attribue (dans la partie HTML) sinon on risque d'éventuelles collusions dans son code JS, ou de réaffecter par erreur ces variables déjà existantes
24/11/2018, 16h50
Beginner.

Citation:

Envoyé par psychadelic

et qu'on le veuille ou non cette variable existe bel et bien quel que soit le navigateur (à jours en 2018) qu'on puisse utiliser.

Conclusion on à intérêt à faire gaffe aux nom des ID que l'on attribue (dans la partie HTML) sinon on risque d'éventuelles collusions dans son code JS, ou de réaffecter par erreur ces variables déjà existantes

Une collision dans ce sens c'est à vérifier mais j'en doute car je pense que dans ce cas la variable déclarée dans le code JS l'emporterait... En fait si ça se trouve il n'y aura même pas de création de variable correspondant au ID si il existe déjà une variable du même nom dans le code JS...

PS : Sinon pour ce qui est des noms de variable, fonction... Si ils sont longs ce n'est pas grave, non ? Puisqu'ils sont raccourcis à la minification ?

Citation:

Envoyé par Beginner.

je pense que dans ce cas la variable déclarée dans le code JS l'emporterait...

la réponse en testant ;)
cas 1:

Code:

1
2
3
4
5
6
7
  "use strict";
  var Nv_P = document.createElement("p")
  Nv_P.id  = 'toto';
  id_Block_DIV.appendChild(Nv_P);
 
  toto.innerText = 'paragraphe toto';  // sera écrit dans le paragraphe
  console.log(typeof toto);           // --> object

cas 2:

Code:

1
2
3
4
5
6
7
8
9
 
  var toto = 15;
 
  var Nv_P = document.createElement("p")
  Nv_P.id  = 'toto';
  id_Block_DIV.appendChild(Nv_P);
 
  toto.innerText = 'paragraphe toto';  // ne sera pas écrit dans le paragraphe
  console.log(typeof toto);           // --> number

cas 3:

Code:

1
2
3
4
5
6
7
8
 "use strict";
  var toto = 15;
 
  var Nv_P = document.createElement("p")
  Nv_P.id  = 'toto';
  id_Block_DIV.appendChild(Nv_P);
 
  toto.innerText = 'paragraphe toto';  // TypeError: can't assign to property "innerText" on 15: not an object

24/11/2018, 21h55
Beginner.

Merci pour les tests...
Alors ils confirment que la variable déclarée dans le code JS l'emporte...
A priori donc il n'y a pas de collision dans l'autre sens...

Même si je m'en doutais (comme déjà dit) c'est toujours bien d'avoir confirmation...
25/11/2018, 01h42
psychadelic

Citation:

Envoyé par NoSmoking

:koi: ben pas pour moi le sujet de départ n'est pas celui là, revoit le titre que tu as mis.

Méfie toi, les titres sont souvent trompeurs.

Je ne pense pas être le seul à abuser mes lecteurs sur la réalité d'un questionnement plus profond, et qui ne peut que s'éloigner de la formulation obligatoirement simpliste de son titre.

Par exemple:
- Les Trois Mousquetaires, d’Alexandre Dumas… ==> ils sont 4 en réalité.

- À la recherche du temps perdu, de Marcel Proust ==> il ne donne aucune recette magique qui permetrait, a minima, de retouver le temps passé à lire ses 7 volumes...

- Au-dessous du volcan, par Malcolm Lowry ==> je l'ai lu, et le héros ne touche jamais la moindre pelle pour creuser le moindre trou, ne serait-ce qu'une esquisse.

- Alcools, de Guillaume Apollinaire ==> très décevant, il n'y a aucune recette de cocktails

- Traité du zen et de l'entretien des motocyclettes, de... inutile d'en parler, le titre parle de lui même : faudra s'accrocher pour y trouver du sens, et dèjà trouver le guidon.

et bien ce n'est pas particulièrement pour en remettre une couche,
mais j'ai trouvé une troisième méthode pour accéder directement en JS aux éléments d'une page html :D
Code:

1 2 3 4 5 6 7 8 9 10 <!DOCTYPE html> <html lang="fr"> <head><meta charset="UTF-8" /></head> <body> <span id="truc-bidule'">texte initial...</span> <script> "use strict" window['truc-bidule'].textContent = 'bla bla bla'; </script> </body></html>
et cela permet de différentier directement les éléments HTML des variables JavaScript, sans risque de collusion. :yaisse1:
(ou de se contraindre à utiliser des règles d'écriture comme le préconise danielhagnoul )

Ce langage m'étonnera toujours !

(et du coup la méthode getElementById() en est presque devenue inutile :aie: )

03/12/2018, 23h18
Watilin

Citation:

Envoyé par Beginner.

Merci pour les tests...
Alors ils confirment que la variable déclarée dans le code JS l'emporte...
A priori donc il n'y a pas de collision dans l'autre sens...

On peut aussi en conclure qu’un script qui s’appuie sur cette fonctionnalité n’est pas future-proof. Si je déclare une <div id="Cabbage"> et que demain les navigateurs se mettent à ajouter un objet Cabbage dans le contexte global, mon script ne marchera plus.
… Et je mettrai un certain temps à comprendre pourquoi.
… Et ça va demander pas mal de refactoring, et donc introduction potentielle de nouvelles erreurs.
Bref, c’est pas une bonne idée d’un point de vue maintenance.

Edit :

Citation:

Envoyé par psychadelic

Code:

window['truc-bidule'].textContent = 'bla bla bla';

C’est deux faits simples :

:arrow: 1. Sur tout objet, l’accès à une propriété peut se faire soit avec la syntaxe obj.prop, soit obj['prop']. L’exception est quand le nom de la propriété contient des caractères qui ont un sens en JS, en l’occurence le -. Là on ne peut utiliser que la seconde syntaxe.

:arrow: 2. Toute variable globale (implicitement ou déclarée avec var) est également une propriété de window. Par exemple, si je déclare var machin dans le contexte global, je peux également y accéder via window.machin, et donc aussi window['machin']. (Note : ça ne marche pas avec let.)