En travaillant sur une idée pour un wrapper HTMLElement simple, je suis tombé sur les éléments suivants pour Internet Explorer et Chrome :
Pour un HTMLElement donné avec ID dans l'arborescence DOM, il est possible de récupérer le div en utilisant son ID comme nom de variable. Donc pour un div comme
<div id="example">some text</div>
dans Internet Explorer 8 et Chrome, vous pouvez faire:
alert(example.innerHTML); //=> 'some text'
ou
alert(window['example'].innerHTML); //=> 'some text'
Donc, cela signifie-t-il que chaque élément de l'arborescence DOM est converti en une variable dans l'espace de noms global? Et cela signifie-t-il également que l'on peut l'utiliser comme remplacement de la getElementById
méthode dans ces navigateurs?
Réponses:
Ce qui est censé se produire, c'est que des «éléments nommés» sont ajoutés en tant que propriétés apparentes de l'
document
objet. C'est une très mauvaise idée, car elle permet aux noms d'éléments d'entrer en conflit avec les propriétés réelles dedocument
.IE a aggravé la situation en ajoutant également des éléments nommés en tant que propriétés de l'
window
objet. Ceci est doublement mauvais dans la mesure où vous devez maintenant éviter de nommer vos éléments après qu'un membre dedocument
l'window
objet ou de l' objet que vous (ou tout autre code de bibliothèque de votre projet) voudriez utiliser.Cela signifie également que ces éléments sont visibles en tant que variables de type global. Heureusement dans ce cas, toutes les déclarations
var
oufunction
déclarations globales réelles dans votre code les masquent, vous n'avez donc pas à vous soucier autant de la dénomination ici, mais si vous essayez de faire une affectation à une variable globale avec un nom conflictuel et que vous oubliez de déclarer ilvar
, vous obtiendrez une erreur dans IE car il tente d'affecter la valeur à l'élément lui - même.Il est généralement considéré comme une mauvaise pratique d'omettre
var
, ainsi que de s'appuyer sur des éléments nommés visibles surwindow
ou en tant que globaux. Tenez-vous-en àdocument.getElementById
, qui est plus largement pris en charge et moins ambigu. Vous pouvez écrire une fonction wrapper triviale avec un nom plus court si vous n'aimez pas la saisie. Quoi qu'il en soit, il est inutile d'utiliser un cache de recherche id-to-element, car les navigateurs optimisent généralement l'getElementById
appel pour utiliser une recherche rapide de toute façon; tout ce que vous obtenez est des problèmes lorsque des éléments changentid
ou sont ajoutés / supprimés du document.Opera copié IE, puis WebKit a rejoint dans, et maintenant à la fois le précédemment non normalisée pratique de mettre des éléments figurant sur les
document
propriétés et la pratique précédemment IE seulement de les mettre surwindow
sont en cours normalisés par HTML5, dont l' approche est de documenter et d' uniformiser tous les terrible pratique que nous ont infligée les auteurs de navigateurs, ce qui en fait une partie du Web pour toujours. Donc Firefox 4 le supportera également.Que sont les «éléments nommés»? Tout ce qui a un
id
, et tout ce quiname
est utilisé à des fins `` d'identification '': c'est-à-dire les formulaires, les images, les ancres et quelques autres, mais pas d'autres instances indépendantes d'unname
attribut, comme les noms de contrôle dans les champs de saisie du formulaire, les noms des paramètres dans<param>
ou tapez les métadonnées<meta>
. Les «identifiants»name
sont ceux qui devraient être évités en faveur deid
.la source
name
devrait être évitée" est avec<input>
, où l'name
attribut joue un rôle essentiel dans la formation de la clé des paires clé-valeur pour les soumissions de formulaire.name
noms de contrôle similaires dans les champs de saisie de formulaire ...»Comme mentionné dans la réponse précédente, ce comportement est appelé accès nommé sur l'objet fenêtre . La valeur de l'
name
attribut pour certains éléments et la valeur de l'id
attribut pour tous les éléments sont mises à disposition en tant que propriétés de l'window
objet global . Ce sont des éléments nommés. Puisquewindow
c'est l'objet global dans le navigateur, chaque élément nommé sera accessible en tant que variable globale.Cela a été ajouté à l'origine par Internet Explorer et a finalement été implémenté par tous les autres navigateurs simplement pour la compatibilité avec les sites qui dépendent de ce comportement. Fait intéressant, Gecko (le moteur de rendu de Firefox) a choisi de l'implémenter en mode excentrique uniquement, tandis que d'autres moteurs de rendu l'ont laissé en mode standard.
Cependant, à partir de Firefox 14, Firefox prend désormais en charge l'accès nommé sur l'
window
objet en mode standard également. Pourquoi ont-ils changé cela? Il s'avère qu'il y a encore beaucoup de sites qui s'appuient sur cette fonctionnalité en mode standard. Microsoft a même publié une démo marketing qui l'a empêché de fonctionner dans Firefox.Webkit a récemment considéré le contraire , reléguant l'accès nommé sur l'
window
objet au mode excentrique uniquement. Ils ont décidé contre cela par le même raisonnement que Gecko.Donc… fou comme il semble que ce comportement est désormais techniquement sûr à utiliser dans la dernière version de tous les principaux navigateurs en mode standard . Mais si l'accès nommé peut sembler quelque peu pratique, il ne doit pas être utilisé .
Pourquoi? Une grande partie du raisonnement peut être résumée dans cet article sur les raisons pour lesquelles les variables globales sont mauvaises . Autrement dit, avoir un tas de variables globales supplémentaires conduit à plus de bugs. Disons que vous tapez accidentellement le nom d'un
var
et qu'il vous arrive de taper unid
d'un nœud DOM, SURPRISE!De plus, bien qu'il soit standardisé, il existe encore quelques différences dans les implémentations d'accès nommé du navigateur.
name
attribut accessible pour les éléments de formulaire (entrée, sélection, etc.).<a>
balises accessibles via leurname
attribut de manière incorrecte .Et je suis sûr qu'il y a plus si vous essayez d'utiliser l'accès nommé sur les cas marginaux.
Comme mentionné dans d'autres réponses, utilisez
document.getElementById
pour obtenir une référence à un nœud DOM par sonid
. Si vous devez obtenir une référence à un nœud par sonname
attribut, utilisezdocument.querySelectorAll
.Veuillez ne pas propager ce problème en utilisant l'accès nommé dans votre site. Tant de développeurs Web ont perdu du temps à essayer de retrouver ce comportement magique . Nous devons vraiment agir et obtenir des moteurs de rendu pour désactiver l'accès nommé en mode standard. À court terme, certains sites feront de mauvaises choses, mais à long terme, cela aidera à faire avancer le Web.
Si vous êtes intéressé, j'en parle plus en détail sur mon blog - https://www.tjvantoll.com/2012/07/19/dom-element-references-as-global-variables/ .
la source
document.querySelectorAll
etdocument.querySelector
accéder au DOM. +1 pour la bonne suggestion d'utiliser cela. L'accès aux éléments par sélecteur est définitivement un processus plus efficace.Vous devez vous en tenir à
getElementById()
ces cas, par exemple:IE aime mélanger les éléments avec
name
et lesID
attributs dans l'espace de noms global, il vaut donc mieux être explicite sur ce que vous essayez d'obtenir.la source
Oui, ils le font.
Testé dans Chrome 55, Firefox 50, IE 11, IE Edge 14 et Safari 10
avec l'exemple suivant:
http://jsbin.com/mahobinopa/edit?html,output
la source
La question devrait sonner: "Les balises HTML avec les ID fournis deviennent-elles des éléments DOM accessibles à l'échelle mondiale?"
La réponse est oui!
C'est ainsi que cela devait fonctionner, et c'est pourquoi les ID ont été introduits par le W3C pour commencer: l'ID d'une balise HTML dans un environnement de script analysé devient son descripteur d'élément DOM correspondant.
Cependant, Netscape Mozilla a refusé de se conformer (à leur intrusion) au W3C et a obstinément continué à utiliser l'attribut Nom obsolète pour créer des ravages et donc casser la fonctionnalité de script et la commodité de codage apportées par l'introduction par le W3C des ID uniques.
Après le fiasco de Netscape Navigator 4.7, leurs développeurs se sont tous infiltrés dans le W3C, tandis que leurs associés ont remplacé le Web par de mauvaises pratiques et des exemples d'utilisation abusive. Forcer l'utilisation et la réutilisation de l'attribut Name déjà obsolète [! Qui n'était pas censé être unique] au même titre que les attributs ID afin que les scripts qui utilisaient des descripteurs ID pour accéder à des éléments DOM particuliers se cassent tout simplement!
Et ils ont fait comme s'ils écrivaient et publiaient également des leçons et des exemples de codage étendus [leur navigateur ne les reconnaîtrait pas de toute façon], comme
document.all.ElementID.property
au lieu de leElementID.property
rendre au moins inefficace et de donner au navigateur plus de frais généraux au cas où il ne le casserait pas simplement à Domaine HTML en utilisant le même jeton pour le nom (désormais [1996-97], obsolète) et l'attribut ID standard lui fournissant la même valeur de jeton.Ils ont facilement réussi à convaincre l'armée écrasante d'amateurs ignorants de l'écriture de code que les noms et les ID sont pratiquement les mêmes, sauf que l'attribut ID est plus court et donc moins d'octets et plus pratique pour le codeur que l'ancienne propriété Name. Ce qui était bien sûr un mensonge. Ou - dans leurs articles HTML remplaçants publiés, des articles convaincants que vous devrez fournir à la fois le nom et l'ID à vos balises pour qu'elles soient accessibles par le moteur de script.
Mosaic Killers [nom de code "Mozilla"] était tellement énervé qu'ils pensaient "si nous descendons, Internet devrait en faire autant".
D'autre part, Microsoft en pleine ascension était si naïf qu'il pensait qu'il fallait conserver la propriété Name obsolète et marquée pour suppression et la traiter comme s'il s'agissait d'un ID qui est un identifiant unique afin de ne pas casser la fonctionnalité de script de anciennes pages codées par les stagiaires de Netscape. Ils se sont trompés mortellement ...
Et le retour d'une collection de tableaux d'éléments en conflit avec l'ID n'était pas non plus une solution à ce problème délibéré créé par l'homme. En fait, cela a déjoué tout le but.
Et c'est la seule raison pour laquelle le W3C est devenu laid et nous a donné des idioties comme
document.getElementById
et la putain de syntaxe ennuyeuse rococo qui l'accompagne ... (...)la source