wozu noch getElementById ?
0 1 
Rolf b
2
0 
Felix Riesterer
0 1 
Der Martin
0 
Gunnar Bittersmann
1 0 Der Martin
wozu noch getElementById ?
Matthias Apsel
Orlok
JürgenBich hatte in einem "<script src = ...></script>" einen falschen Dateinamen angegeben,
trotzdem
schien eine darin enthaltene Zuweisung const x = document.getElementById('x')
erfolgreich interpretiert worden zu sein;
also versuchte ich
<span id="test"><span>A: </span><span>B: </span></span>
<script>
test.firstChild.innerHTML += "2 "; test.childNodes[1].innerHTML += "1";
</script>
und es funktioniert - das sichtbare Ergebnis ist "A: 2 B: 1".
Es scheint daß,
jede "id=.." eine Referenz auf das Element das sie enthält erzeugt.
oder nur bei meinem Firefox?
-
Dann jage mal das hier durch den Debugger:
<doctype html> <html> <body> <span id="test"><span>A: </span><span>B: </span></span> <script> var test; var t=document.getElementById('test'); t.firstChild.innerHTML += "2 "; t.childNodes[1].innerHTML += "1"; test.firstChild.innerHTML += "C "; test.childNodes[1].innerHTML += "D"; </script> </body> </html>Der meldet:
TypeError: test is undefinedFazit:
Wenn Du oder ein Skript eines anderen, Variablen verwendest, die zufällig so heißen wie die Elemente "benamt" sind, dann ist die Herrlichkeit vorbei.
-
Das ist Schwachsinn, der zum Standard wurde.
Man beachte, dass whatwg dieses Feature definiert und gleich wieder davon abrät. Es verschmutzt das window-Objekt und damit auch den globalen Namensraum. Aber leider ist es da. Also bleib nach Möglichkeit aus diesem Dreckhaufen heraus.
Variablen, die Du mit var definiert hast, überschatten die an Hand einer id angelegten window-Eigeschaften.
Also
- nie var vergessen und nach Möglichkeit alles, was Du nicht vermeiden kannst global zu machen, in einem eigenen Globals-Container unterbringen.
- sich nicht auf window[id] verlassen, sondern immer getElementById verwenden.
Gruß Rolf
-
Danke Rolf!
Von "whatwg" erfahre ich hier zu ersten Mal.
Speziell geht es bei mir um die Verfassung eines "Artikels" auf dem Matheplaneten da scheint jeder praktisch auf einer "Insel" zu leben.
Werde das Feature aber nicht ausnutzen. Gegen "const" spricht aber doch nichts?Gruß Fritz
-
Danke; das ist natürlich klar, "var test;" setzt ja auch test explizit "undefined" .
-
-
Lieber mathefritz,
test.firstChild.innerHTML += "2 ";
dass Du mit
window.testauf ein Element mit der ID "test" zugreifen kannst, kannte ich nur vom Internet Explorer. Keine Ahnung seit wann Mozilla dieses Feature anbietet. Darauf verlassen würde ich mich aus Prinzip nicht.Liebe Grüße,
Felix Riesterer.
-
Danke Felix Riesterer!
Naja, von "Offline-Programmiersprachen" ist man es eigentlich nicht gewöhnt daß man Objekte zweimal Taufen muß.
Werd' es aber hinnnehmen, auch wenn das wirklich lästige Tipparbeit ist. Eigentlich sollte eine intelligente Entwicklungsumgebung einen darauf hinweisen wenn für irgendeine "id" nicht auch ein getElementById auftauchtGruß Fritz.
-
Hallo,
Naja, von "Offline-Programmiersprachen" ist man es eigentlich nicht gewöhnt daß man Objekte zweimal Taufen muß.
wieso zweimal? Du gibst dem Element im Markup einmal eine ID, und selektierst es dann anhand dieser ID, wobei du dich vielleicht nicht unbedingt auf die Erreichbarkeit im globalen Namensraum verlassen möchtest, sondern das Element lieber mit getElementById() explizit raussuchst.
Werd' es aber hinnnehmen, auch wenn das wirklich lästige Tipparbeit ist.
Wirklich? Nun übertreib's nicht ...
Eigentlich sollte eine intelligente Entwicklungsumgebung einen darauf hinweisen wenn für irgendeine "id" nicht auch ein getElementById auftaucht
Warum? Eine ID hat viele Verwendungsmöglichkeiten; mit Javascript gezielt auf das Element zuzugreifen ist nur eine davon. Man kann das Element anhand der ID mit CSS selektieren, man kann sie als Anker (Sprungziel) für Links verwenden, man kann Formularelemente und ihre Label anhand der ID verknüpfen ...
So long,
Martin--
Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
- Douglas Adams, The Hitchhiker's Guide To The Galaxy-
@@Der Martin
sondern das Element lieber mit getElementById() explizit raussuchst.
Oder lieber mit querySelector(). Was die Frage „wozu noch getElementById?“ in einem anderen Licht erscheinen lässt.
LLAP 🖖
--
“There’s no such thing as an ‘average’ user, but there is such a thing as an average developer.” —Vitaly Friedman in Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns”
Selfcode:sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|-
hoppla, DAS läßt die Frage wirklich in einem anderem
Licht erscheinen; so geläufig ist mein html noch nicht, und bisher meinte ich die id müsse eindeutig sein .-
Hi,
hoppla, DAS läßt die Frage wirklich in einem anderem Licht erscheinen; so geläufig ist mein html noch nicht, und bisher meinte ich die id müsse eindeutig sein.
ja, muss sie auch - jedenfalls innerhalb eines Dokuments. Die Tatsache, dass querySelector() auch nach ganz anderen Kriterien selektieren kann, ändert daran nichts. Und das Beispiel im Wiki zeigt fehlerhaftes HTML!
EDIT: Ich hab das Beispiel mal entschärft und korrekten Code draus gemacht.
So long,
Martin--
Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
- Douglas Adams, The Hitchhiker's Guide To The Galaxy-
Hallo Der Martin,
ja, muss sie auch - jedenfalls innerhalb eines Dokuments. Die Tatsache, dass querySelector() auch nach ganz anderen Kriterien selektieren kann, ändert daran nichts. Und das Beispiel im Wiki zeigt fehlerhaftes HTML!
EDIT: Ich hab das Beispiel mal entschärft und korrekten Code draus gemacht.
Danke. :-)
Bis demnächst
Matthias
-
-
-
Hallo,
sondern das Element lieber mit getElementById() explizit raussuchst.
Oder lieber mit querySelector().
oder das. Aber warum lieber? Was hat querySelector() für Vorteile? Es ist vielseitiger und kann mehr als einfach nur nach ID suchen, okay.
Aber es ist auch eine alte Faustregel unter Programmierern, dass die Performance einer Funktion mit zunehmender Vielseitigkeit abnimmt. Daher würde ich doch in Fällen, wo ich diese Vielseitigkeit nicht brauche, lieber bei getElementById() bleiben wollen.
Was die Frage „wozu noch getElementById?“ in einem anderen Licht erscheinen lässt.
Ja. Aber nur rein akademisch, wenn du nicht noch ein Argument pro querySelector() hast.
So long,
Martin--
Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
- Douglas Adams, The Hitchhiker's Guide To The Galaxy-
@@Der Martin
Was hat querySelector() für Vorteile?
Dieselbe Syntax wie im CSS, nicht mal mit
#, mal ohne.Performance … abnimmt. Daher würde ich doch in Fällen, wo ich diese Vielseitigkeit nicht brauche, lieber bei getElementById() bleiben wollen.
Das wäre in dem Fall wohl Mikro-Optimierung, die sich kaum messbar bemerkbar machen dürfte. Da wäre einfacherem Code (einheitliche Selektor-Syntax) der Vorzug zu geben.
LLAP 🖖
--
“There’s no such thing as an ‘average’ user, but there is such a thing as an average developer.” —Vitaly Friedman in Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns”
Selfcode:sh:) fo:} ch:? rl:) br:> n4:& va:| de:> zu:} fl:{ ss:| ls:# js:|-
Hi,
Was hat querySelector() für Vorteile?
Dieselbe Syntax wie im CSS, nicht mal mit
#, mal ohne.Performance … abnimmt. Daher würde ich doch in Fällen, wo ich diese Vielseitigkeit nicht brauche, lieber bei getElementById() bleiben wollen.
Das wäre in dem Fall wohl Mikro-Optimierung, die sich kaum messbar bemerkbar machen dürfte. Da wäre einfacherem Code (einheitliche Selektor-Syntax) der Vorzug zu geben.
okay, das kann ich als Begründung für die Allgemeinheit gelten lassen; für mich selbst ist es nicht schwerwiegend genug. Da werde ich wohl auch weiterhin im (häufig vorkommenden) Spezialfall die spezialisierte Funktion/Methode nehmen.
So long,
Martin--
Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
- Douglas Adams, The Hitchhiker's Guide To The Galaxy -
Hallo Gunnar
Performance … abnimmt. Daher würde ich doch in Fällen, wo ich diese Vielseitigkeit nicht brauche, lieber bei getElementById() bleiben wollen.
Das wäre in dem Fall wohl Mikro-Optimierung, die sich kaum messbar bemerkbar machen dürfte. Da wäre einfacherem Code (einheitliche Selektor-Syntax) der Vorzug zu geben.
Ob sich das bemerkbar macht, hängt wohl wesentlich davon ab, in welchem Umfang ein Programm die genannten Methoden nutzt. Wenn es nur darum geht, eine Handvoll Elemente zu selektieren, dann ist es mit Blick auf die Performance sicherlich völlig egal, welcher Variante man den Vorzug gibt.
Allerdings meine ich mich erinnern zu können, vor einiger Zeit mal Testergebnisse gesehen zu haben, die zeigten, dass die Methoden
getElementById,getElementsByClassNameundgetElementsByTagNamein so ziemlich jedem Browser deutlich, teilweise um ein Vielfaches schneller sind, als wenn die Elemente überquerySelectoroderquerySelectorAllreferenziert werden. Bei einer größeren Anwendung könnte das also durchaus ein Faktor sein, der nicht völlig unerheblich ist.Was das Argument mit der einheitlichen Selektor-Syntax angeht, finde ich nicht, dass dies wirklich in jedem Fall ein Vorteil gegenüber den althergebrachten Methoden sein muss. So wie ich das sehe, ist die Syntax der spezifischeren Methoden insgesamt aussagekräftiger, da man schon beim Lesen des Bezeichners der Methode sieht worum es geht. Das scheint mir wohl eher eine Frage der persönlichen Präferenz zu sein und nichts, was man verallgemeinern kann.
Jedenfalls setze ich die Methoden
querySelectorundquerySelectorAllnur in solchen Situationen ein, in denen sie ihre Stärken auch wirklich ausspielen können.Viele Grüße,
Orlok
-
Tach!
Allerdings meine ich mich erinnern zu können, vor einiger Zeit mal Testergebnisse gesehen zu haben, die zeigten, dass die Methoden
getElementById,getElementsByClassNameundgetElementsByTagNamein so ziemlich jedem Browser deutlich, teilweise um ein Vielfaches schneller sind, als wenn die Elemente überquerySelectoroderquerySelectorAllreferenziert werden.Muss ja so sein. Die querySelector-Methoden müssen erstmal das Argument parsen, um zu wissen, wonach sie suchen müssen. Die getElement-Methoden hingegen können sofort loslegen.
dedlfix.
-
Hallo,
Allerdings meine ich mich erinnern zu können, vor einiger Zeit mal Testergebnisse gesehen zu haben, die zeigten, dass die Methoden
getElementById,getElementsByClassNameundgetElementsByTagNamein so ziemlich jedem Browser deutlich, teilweise um ein Vielfaches schneller sind, als wenn die Elemente überquerySelectoroderquerySelectorAllreferenziert werden. Bei einer größeren Anwendung könnte das also durchaus ein Faktor sein, der nicht völlig unerheblich ist.da ich eine Anwendung habe, die auch schon mal auf sehr viele Elemente zugreift, habe ich das mal getestet: Testseite
Wenn es nur um das Suchen von Elementen geht, sind
getElementsByTagNameundquerySelectorAllvergleichbar schnell. Wenn es aber etwas komplizierter wird (Ps in DIVs), hatquerySelectorAllleichte Vorteile. Nicht in dieser Testseite: bei der Suche nach Kindern (div > p) verliertgetElementsByTagNamedeutlich, da ja noch bei den Treffern geprüft werden muss, ob Kind oder (Ur-)Enkel gefunden wurde.Gruß
Jürgen
-
-
-
-
-
-
-