nicht angemeldet
onload tut nichts
0 0 0 0 0 0 0 0 0 
Struppi
1
0
onload tut nichts
Hallo,
Habe mal gelesen, dass das onload-Ereignis nicht nur für window- und body-Elemente funktioniert, sondern für andere auch.
Jetzt könnte ich das einmal brauchen, und prompt klappt es natürlich nicht.
<html>
<head>
<title>
onload-Test
</title>
</head>
<body>
<div id = "test" onload = "alert('Hi there!');">
<input id = "textfeld" type="textbox" onload = "alert(this.id);"></input>
</div>
</body>
</html>
Es gibt keine alerts, weder in IE, noch in FF, noch in Opera. Wieso nicht?
Stehe ich jetzt völlig auf dem Schlauch oder geht es wirklich nicht, solange das DOM noch am Laden ist?
Gruß, Don P
-
Hi,
Habe mal gelesen, dass das onload-Ereignis nicht nur für window- und body-Elemente funktioniert, sondern für andere auch.
Wo hast du dich denn wieder rumgetrieben, du Streuner?
(Wenigstens ein Link zu deiner Gerüchteseite wäre doch mal fein gewesen.)Jetzt könnte ich das einmal brauchen, und prompt klappt es natürlich nicht.
<input id = "textfeld" type="textbox" onload = "alert(this.id);"></input>Ich wüsste nicht, in welcher Form da was „klappen“ sollte.
Soll das irgendeine Neuerung im Rahmen von HTML5 sein ...?Stehe ich jetzt völlig auf dem Schlauch oder geht es wirklich nicht, solange das DOM noch am Laden ist?
Warum sollte ein einzelnes (Eingabe-)Element sich darum kümmern (dürfen), ob das Dokument (nebst externer Ressourcen) fertig geladen ist?
Es gibt keine alerts, weder in IE, noch in FF, noch in Opera. Wieso nicht?
Die MSDN beschreibt zwar zum onload-Event, dass der für eine ganze Menge an Elementen gelte (so gut wie „alles“) - aber dass das irgendeinem Standard gerecht würde, wäre mir neu.
MfG ChrisB
--
“Whoever best describes the problem is the person most likely to solve the problem.” [Dan Roam]-
Hallo,
Wo hast du dich denn wieder rumgetrieben, du Streuner?
(Wenigstens ein Link zu deiner Gerüchteseite wäre doch mal fein gewesen.)Na hier, direkt unter dem zweiten Beispiel steht's ganz klar. Die lügen ja wie gedruckt ;)
<input id = "textfeld" type="textbox" onload = "alert(this.id);"></input>Ich wüsste nicht, in welcher Form da was „klappen“ sollte.
Soll das irgendeine Neuerung im Rahmen von HTML5 sein ...?Wieso Neuerung? onload ist doch bestimmt so alt wie JavaScript selber.
Warum sollte ein einzelnes (Eingabe-)Element sich darum kümmern (dürfen), ob das Dokument (nebst externer Ressourcen) fertig geladen ist?
Wieso das Dokument? Wenn es selber geladen ist, könnte es mich doch begrüßen mit "Hallo da bin ich, dein Input-Feld. Füll' mich bitte nachher aus, aber gründlich..." ;)
Die MSDN beschreibt zwar zum onload-Event, dass der für eine ganze Menge an Elementen gelte (so gut wie „alles“) - aber dass das irgendeinem Standard gerecht würde, wäre mir neu.
Mir ist dagegen neu, dass nur window und body merken dürfen, dass sie geladen sind...
Wenn der body endlich da ist, muss man die einzelenen Elemente mühsam mit getElementById oder so rausklauben, was besonders schwierig wird, wenn man die IDs gar nicht kennt, da sie z.B. irgendwie dynamisch aus den Tiefen von asp.net kommen. Ein onload für die einzelnen Elemente würde da Wunder wirken.
Gruß, Don P
-
Hi,
Na hier, direkt unter dem zweiten Beispiel steht's ganz klar. Die lügen ja wie gedruckt ;)
nein, Du verstehst sie nur falsch. Dort wird gesagt: "Diese Art Funktionen aufzurufen ist nicht nur auf das window Objekt beschränkt, [...]", was absolut korrekt ist. Nirgendwo wird dort jedoch gesagt, dass jedes Element-Objekt über ein load-Event verfügt. Versuche das mit onmouseover, hierzu gibt es in weitaus mehr Elementen Events.
Soll das irgendeine Neuerung im Rahmen von HTML5 sein ...?
Wieso Neuerung? onload ist doch bestimmt so alt wie JavaScript selber.Ja, aber Du versuchst ja nicht zu prüfen, ob das Dokument fertig geladen ist, sondern ob dies auf ein <div>- oder <input>-Element zutrifft. Das *könnte* eine Neuerung von HTML5 sein - ist es aber nicht.
onload gibt es nur für sehr wenig.
Wieso das Dokument? Wenn es selber geladen ist, könnte es mich doch begrüßen mit "Hallo da bin ich, dein Input-Feld. Füll' mich bitte nachher aus, aber gründlich..." ;)
Das geht mit einem <script>-Element direkt hinter dem Eingabefeld.
Mir ist dagegen neu, dass nur window und body merken dürfen, dass sie geladen sind...
Willkommen. Dies ist so alt wie JavaScript selber.
Wenn der body endlich da ist,
Das ist nicht die Antwort, die Dir window.onload (welches durch <body onload="..."> gesetzt bzw. überschrieben werden kann) gibt. Es sagt Dir, wann das Dokument mit seinen Inhalten vollständig verfügbar ist - also einschließlich beispielsweise eingebundener Grafiken.
muss man die einzelenen Elemente mühsam mit getElementById oder so rausklauben, was besonders schwierig wird, wenn man die IDs gar nicht kennt, da sie z.B. irgendwie dynamisch aus den Tiefen von asp.net kommen.
Bitte die manische Fokussierung auf IDs aus Deinem Gedankengut entfernen. Elemente können durch *Massen* von DOM-Operationen gefunden werden, nicht ausschließlich durch einen ID-bezüglichen Zugriff. Letzterer ist auf Fälle beschränkt, in denen das Element auch eine ID hat, was vergleichsweise selten sinnvoll ist.
Ein onload für die einzelnen Elemente würde da Wunder wirken.
Ja. Schlag's doch bitte dem W3C vor, dort wird man diese Veränderung der Standards sicher in Erwägung ziehen.
Cheatah
--
X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes-
Hallo,
nein, Du verstehst sie nur falsch. Dort wird gesagt: "Diese Art Funktionen aufzurufen ist nicht nur auf das window Objekt beschränkt, [...]", was absolut korrekt ist. Nirgendwo wird dort jedoch gesagt, dass jedes Element-Objekt über ein load-Event verfügt.
Ok, aber es wird zumindest suggeriert, dass das genau für onload gilt. Dass es nicht so ist, hätte man an der Stelle unbedingt dazusagen müssen. So wie's dasteht, *muss* man es ja falsch verstehen.
Wieso Neuerung? onload ist doch bestimmt so alt wie JavaScript selber.
Ja, aber Du versuchst ja nicht zu prüfen, ob das Dokument fertig geladen ist, sondern ob dies auf ein <div>- oder <input>-Element zutrifft. Das *könnte* eine Neuerung von HTML5 sein - ist es aber nicht.
Leider. Es ist mir unverständlich, warum nicht, wäre doch extrem nützlich.
Das geht mit einem <script>-Element direkt hinter dem Eingabefeld.
Nicht wirklich. Dann ist das Element, für das ich mich wirklich interessiere, bereits "um's Eck".
Mir ist dagegen neu, dass nur window und body merken dürfen, dass sie geladen sind...
Willkommen. Dies ist so alt wie JavaScript selber.
Shit happens.
Bitte die manische Fokussierung auf IDs aus Deinem Gedankengut entfernen. Elemente können durch *Massen* von DOM-Operationen gefunden werden
Das schon, aber wenn ich ein ganz bestimmtes will, ist doch eine id am eindeutigsten, da sie nur einmal im ganzen Dokument vorkommt. Alle anderen Arten, ein bestimmtes Element zu finden, sind dagegen einfach nur umständlich, oder etwa nicht? Natürlich kann ich auch z.B. über parentNode ein Element erwischen, wenn ich weiß, dass es das Elternelement ist, aber das Elternelement wovon? Dazu muss ich wieder erst mal enes bestimmten Kindelements habhaft gweworden sein...
, nicht ausschließlich durch einen ID-bezüglichen Zugriff. Letzterer ist auf Fälle beschränkt, in denen das Element auch eine ID hat, was vergleichsweise selten sinnvoll ist.
Es ist immer dann sinnvoll, wenn man ganz bestimmte Elemente haben will, die eindeutig ansprechbar sein sollen. Nicht wirklich selten, wie ich meine.
Ja. Schlag's doch bitte dem W3C vor, dort wird man diese Veränderung der Standards sicher in Erwägung ziehen.
Sicher wartet man dort nicht gerade auf mich, sowas vorzuschlagen. Vermutlich ist es nur ganz schwer umzusetzen, sonst gäb's das doch schon längst. Kann mir nicht vorstellen, dass ich der Einzige bin, der bis jetzt auf diese Idee gekommen ist und so ein feature nützlich findet...
Gruß, Don P
-
Hi,
Ok, aber es wird zumindest suggeriert, dass das genau für onload gilt. Dass es nicht so ist, hätte man an der Stelle unbedingt dazusagen müssen. So wie's dasteht, *muss* man es ja falsch verstehen.
ja, der Autor verdient diesbezüglich tatsächlich Feedback.
Ja, aber Du versuchst ja nicht zu prüfen, ob das Dokument fertig geladen ist, sondern ob dies auf ein <div>- oder <input>-Element zutrifft. Das *könnte* eine Neuerung von HTML5 sein - ist es aber nicht.
Leider. Es ist mir unverständlich, warum nicht, wäre doch extrem nützlich.Vieles wäre nützlich. Bei vielem kommen aber auch andere Erwägungen ins Spiel. Beispielsweise kennt CSS keinen Vorfahrenselektor, obwohl er schon häufiger vorgeschlagen wurde - es würde Implementierungen von CSS-Engines zu unperformant machen.
Bitte die manische Fokussierung auf IDs aus Deinem Gedankengut entfernen. Elemente können durch *Massen* von DOM-Operationen gefunden werden
Das schon, aber wenn ich ein ganz bestimmtes will, ist doch eine id am eindeutigsten, da sie nur einmal im ganzen Dokument vorkommt.
IDs sind für Elemente, die *bemerkenswert* eindeutig sind. Die Eindeutigkeit an sich reicht nicht aus - auf <body> trifft dies ebenfalls zu, jedoch ist dieser Umstand selten bemerkenswert.
Alle anderen Arten, ein bestimmtes Element zu finden, sind dagegen einfach nur umständlich, oder etwa nicht?
Völlig richtig: Sie sind einfach nur umständlich, oder etwa nicht.
Es ist immer dann sinnvoll, wenn man ganz bestimmte Elemente haben will, die eindeutig ansprechbar sein sollen.
Nur, wenn dies auch bemerkenswert ist. Pauschal Elemente mit IDs zuzuballern, nur weil man sie unter Einzelbedingungen mal braucht, ist kontraproduktiv.
Ja. Schlag's doch bitte dem W3C vor, dort wird man diese Veränderung der Standards sicher in Erwägung ziehen.
Sicher wartet man dort nicht gerade auf mich, sowas vorzuschlagen.Vermutlich nicht auf Dich persönlich, aber im aktuellen Entwicklungszustand von HTML5 rechne ich Dir adäquate Chancen an, dass Dein Hinweis nicht per se gelöscht wird.
Vermutlich ist es nur ganz schwer umzusetzen, sonst gäb's das doch schon längst. Kann mir nicht vorstellen, dass ich der Einzige bin, der bis jetzt auf diese Idee gekommen ist und so ein feature nützlich findet...
Wie definierst (spezifizierst) Du HTMLElement.onload?
Cheatah
--
X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes-
Hallo,
IDs sind für Elemente, die *bemerkenswert* eindeutig sind. Die Eindeutigkeit an sich reicht nicht aus - auf <body> trifft dies ebenfalls zu, jedoch ist dieser Umstand selten bemerkenswert.
Pauschal Elemente mit IDs zuzuballern, nur weil man sie unter Einzelbedingungen mal braucht, ist kontraproduktiv.
Dafür habe ich ja auch nicht plädiert. Ids vergeben ich natürlich nicht prinzipiell, nur damit sie da sind, sondern gerade weil gewisse Elemente bedeutend sind und eindeutig und einfach ansprechbar sein sollen.
Im Fall von asp.net kommen sehr viele Elemente mit IDs daher, weil sie mit runat="server" gekennzeichnet sind, und jetzt würde ich eben gern auf das eine oder andere per JS zugreifen. Aber die Ids werden von der Anwendung vergeben und können sich ändern. Daher wollte ich mir manche Elemente einfach onload greifen, geht aber nicht. Wirklich schade.
Wie definierst (spezifizierst) Du HTMLElement.onload?
Na, sobald der Browser beim Rendern die Existenz des Elements mitsamt Attributen und Inhalt zur Kenntnis genommen hat. Der onload-Handler würde dann analog onclick oder body.onload laufen. Die Ressourcen (z.B. enthaltene Bilder) müssen aber nicht unbedingt fertig geladen sein, auch die Abmessungen müssen noch nicht definitv sein (z.B. innerhalb von Tabellen mit relativen Größenangaben, die ja erst berechnet werden können, wenn die Tabelle fertig geladen ist).
Gruß, Don P
-
Hi,
Pauschal Elemente mit IDs zuzuballern, nur weil man sie unter Einzelbedingungen mal braucht, ist kontraproduktiv.
Dafür habe ich ja auch nicht plädiert. Ids vergeben ich natürlich nicht prinzipiell, nur damit sie da sind, sondern gerade weil gewisse Elemente bedeutend sind und eindeutig und einfach ansprechbar sein sollen.hättest Du die IDs auch dann vergeben, wenn kein konkreter Anwendungsfall bestünde?
Im Fall von asp.net kommen sehr viele Elemente mit IDs daher, weil sie mit runat="server" gekennzeichnet sind,
Ein weiterer Grund, ASP.net nicht einzusetzen. Wurde schon angekündigt, wann dieser Bug gefixt sein wird?
Wie definierst (spezifizierst) Du HTMLElement.onload?
Na, sobald der Browser beim Rendern die Existenz des Elements mitsamt Attributen und Inhalt zur Kenntnis genommen hat.Welchen Zweck hat dieser massive Unterschied zu window.onload? Oder anders gesagt: Wenn Du kein Konzept erstellst, das einer Betrachtung Stand hält, wird Deine Nachricht an das W3C vermutlich doch ignoriert werden.
[...] auch die Abmessungen müssen noch nicht definitv sein (z.B. innerhalb von Tabellen mit relativen Größenangaben, die ja erst berechnet werden können, wenn die Tabelle fertig geladen ist).
Also wenn das Element mitsamt Attributen und Inhalt zur Kenntnis genommen werden konnte. Du widersprichst Dir selbst etwas zu schnell.
Cheatah
--
X-Self-Code: sh:( fo:} ch:~ rl:| br:> n4:& ie:% mo:) va:) de:] zu:) fl:{ ss:) ls:~ js:|
X-Self-Code-Url: http://emmanuel.dammerer.at/selfcode.html
X-Will-Answer-Email: No
X-Please-Search-Archive-First: Absolutely Yes-
Hallo,
hättest Du die IDs auch dann vergeben, wenn kein konkreter Anwendungsfall bestünde?
Nein, weil unnötig.
Im Fall von asp.net kommen sehr viele Elemente mit IDs daher, weil sie mit runat="server" gekennzeichnet sind,
Ein weiterer Grund, ASP.net nicht einzusetzen. Wurde schon angekündigt, wann dieser Bug gefixt sein wird?
Man kann sich das nicht immer aussuchen. Jetzt arbeite ich an einem vorhandenen Projekt mit, das nunmal mit asp.net gemacht ist. Ändern kann man das jetzt nicht mehr, es würde ein komplettes Redesign einer umfangrichen Anwendung bedeuten. Auch ist das kein Bug, sondern gehört zum Grunkonzept von asp.net. So arbeitet es nunmal.
Was ist eigentlich so problematisch mit IDs? Man muss sie nicht unnötig vergeben, soviel ist klar, aber sind sie denn irgendwie schädlich? Du scheinst ja eine richtige Aversion gegen IDs zu haben, oder ist es nur eine Allergie? ;)
Wie definierst (spezifizierst) Du HTMLElement.onload?
Na, sobald der Browser beim Rendern die Existenz des Elements mitsamt Attributen und Inhalt zur Kenntnis genommen hat.Welchen Zweck hat dieser massive Unterschied zu window.onload? Oder anders gesagt: Wenn Du kein Konzept erstellst, das einer Betrachtung Stand hält, wird Deine Nachricht an das W3C vermutlich doch ignoriert werden.
window.onload bezieht sich doch auf das ganze Dokument bzw. Fenster mit allen Ressourcen. Was ich meine, ist nur ein einzelnes Element. So eine Art DOMready oder ElementReady meinetwegen. Wenn man davon ausgeht, dass die HTML-Tags sukzessive eingelesen werden, dann ist ein Element genau dann "ready" oder geladen, sobald der Parser das End-Tag sieht. Er kennt dann auch die Attribute und den sonstigen Inhalt (eingebettte Elemente) und könnte ein onload- oder eben elementReady-Ereignis feuern.
[...] auch die Abmessungen müssen noch nicht definitv sein (z.B. innerhalb von Tabellen mit relativen Größenangaben, die ja erst berechnet werden können, wenn die Tabelle fertig geladen ist).
Also wenn das Element mitsamt Attributen und Inhalt zur Kenntnis genommen werden konnte. Du widersprichst Dir selbst etwas zu schnell.
Ich sehe da keinen Widerspruch. Die bloße Existenz des Elements und der Attribte zur Kenntis nehmen heißt noch nicht, sie komplett ausgewertet bzw. angewendet zu haben.
Gruß, Don P
-
window.onload bezieht sich doch auf das ganze Dokument bzw. Fenster mit allen Ressourcen. Was ich meine, ist nur ein einzelnes Element. So eine Art DOMready oder ElementReady meinetwegen.
Das wird z.T. auch schon unterstützt: http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-mutationevents
Struppi.
-
window.onload bezieht sich doch auf das ganze Dokument bzw. Fenster mit allen Ressourcen. Was ich meine, ist nur ein einzelnes Element. So eine Art DOMready oder ElementReady meinetwegen.
Das wird z.T. auch schon unterstützt: http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-mutationevents
Beim Parsen werden aber nicht ständig Mutation-Events gefeuert. Das passiert erst nachdem das Dokument initial eingelesen ist und man programmatisch über das DOM Änderungen vornimmt. Sonst wäre es kompletter Overkill, für jeden vom Parser verarbeiteten Token ein entsprechenden JS-Event zu feuern.
Was du meinst, wäre eine Art SAX-API für HTML.Mathias
-
Hallo,
Was du meinst, wäre eine Art SAX-API für HTML.
Ja genau! Das ist es. Es würde (mir) aber reichen, wenn jeweils nur ein endElement-Ereignis gemeldet wird, mit einer Referenz auf das neue Node-Objekt, so dass man es per JS sozusagen schon mal am Wickel hat, sobald es vom Parser erkannt wurde.
Damit nicht gerade für jedes Element so ein Event stattfinden muss (overkill), könnte man eben ein "onload" oder "onParsed" oder wie auch immer benanntes Attribut einführen, so dass das Ereignis nur ausgelöst wird, wenn das Attribut auch vorhanden ist.
Es sollte nicht allzu schwierig sein, sowas zu implementieren, und ich bin wie gesagt zuerst davon ausgegangen, dass es längst üblich ist.
Gruß, Don P
-
Damit nicht gerade für jedes Element so ein Event stattfinden muss (overkill), könnte man eben ein "onload" oder "onParsed" oder wie auch immer benanntes Attribut einführen, so dass das Ereignis nur ausgelöst wird, wenn das Attribut auch vorhanden ist.
Man könnte natürlich parallel zum Parsen direkt solche Events feuern, die schon einige Operationen vornehmen. Das kann aber ggf. das Parsing beeinflussen. Wenn man es unbedingt Inline haben will und zeitlich so nah wie möglich am Parsen des Elements, dann kann man ein script-Element nach dem fraglichen Element einfügen - wurde glaube ich schon gesagt im Thread. Das ist nichts anderes als »onParsed« bezüglich des vorherigen Elements.
Es sollte nicht allzu schwierig sein, sowas zu implementieren
Daran haben Browserhersteller derzeit wenig Interesse. Der Trend geht (glücklicherweise) weg von Inline-JavaScript hin zu Unobtrusive JavaScript und DOM-ready-Lösungen. In diesem Bereich tut sich sehr viel momentan. HTML5 legt auf die Standardisierung dieser bewährten Techniken Wert und hat, wie ich glaube bewusst, auf eine SAX-API verzichtet. Siehe etwa <molily.de/weblog/javascript-asynchron>.
Mathias
-
Hallo,
Wenn man es unbedingt Inline haben will und zeitlich so nah wie möglich am Parsen des Elements, dann kann man ein script-Element nach dem fraglichen Element einfügen - wurde glaube ich schon gesagt im Thread. Das ist nichts anderes als »onParsed« bezüglich des vorherigen Elements.
Das schon, aber wie greift man dann auf das vorherige Element zu? Man müsste irgendwie den unfertigen DOM-Baum durchlaufen um es zu ermitteln, was auch wieder die Performance drückt. Besser, d.h. schneller und einfacher wäre eine Art SAX-Event, der das gewünschte Element direkt liefert.
Daran haben Browserhersteller derzeit wenig Interesse. Der Trend geht (glücklicherweise) weg von Inline-JavaScript hin zu Unobtrusive JavaScript und DOM-ready-Lösungen. In diesem Bereich tut sich sehr viel momentan. HTML5 legt auf die Standardisierung dieser bewährten Techniken Wert und hat, wie ich glaube bewusst, auf eine SAX-API verzichtet. Siehe etwa <molily.de/weblog/javascript-asynchron>.
Gut, in dem Artikel beschreibst du die Performance-Probleme, die sich durch inline-JavaScript ergeben können. Das ist zweifellos ein Nachteil, aber letzlich liegt es doch an den Site-Betreibern selbst, was sie einbinden und wie. Es ist ja schon jetzt leicht möglich, unobstrusive Javacript einzusetzen. Eine nützliche Technik wie SAX abzulehnen bzw. nicht zu implementieren, nur weil sie von manchen (Hauptsächlich der Werbebranche) exzessiv und mit Performance-Einbußen verbunden eingesetzt werden kann, ist wohl auch nicht der Weisheit letzter Schluss.
Ich denke, das regelt sich von selbst. Wer Werbung wie im Fernsehen anschauen will, der soll halt den Fernseher einschalten. Heutzutage braucht man dafür ja nicht mal mehr nach Amerika auszuwandern.
Ich meide solche Sites und Portale, die vor blinkender Werbung und Popups nur so strotzen und und eine halbe Ewigkeit zum Laden brauchen. So mancher schaltet JS deswegen ganz ab. Man hat es als Benutzer doch in der Hand, was man auf dem Schirm zulassen will und was nicht.Schließlich gibt es noch andere Verwendungszwecke für Browser als immer nur in der freien Internet-Wildbahn herumzusurfen – Firmennetzwerke z.B. Da ist es schnurzegal, ob inline-Javascript mit viel Werbung die Performance bremst. Soche Scripte kommen einfach nicht vor. Dafür aber andere, nützliche, bei denen die Tatsache, dass sie mehr oder weniger inline notiert sind, überhaupt keinen Nachteil darstellt, sondern im Gegenteil Entwicklungskosten spart, weil man für jeden Zweck eine geeignete Technik zur Verfügung hat, äh hätte... *träum*
Gruß, Don P
-
Hi,
Wenn man es unbedingt Inline haben will und zeitlich so nah wie möglich am Parsen des Elements, dann kann man ein script-Element nach dem fraglichen Element einfügen - wurde glaube ich schon gesagt im Thread. Das ist nichts anderes als »onParsed« bezüglich des vorherigen Elements.
Das schon, aber wie greift man dann auf das vorherige Element zu? Man müsste irgendwie den unfertigen DOM-Baum durchlaufen um es zu ermitteln, was auch wieder die Performance drückt.
Richtig, das geht nicht ganz trivial.
Man könnte den Ansatz nehmen, den John Resig in Degrading Script Tags zu einem anderen Zweck vorschlägt - über
var scripts = document.getElementsByTagName("script"); var aktuellesScript = scripts[scripts.length-1]kriegst du die Referenz auf das Script-Element, welches zuletzt beim Parsen des Codes angetroffen wurde, dessen Code also aktuell ausgeführt wird; und dann könntest du bspw. über previousSibling auf das davor stehende Element zugreifen.
Aber wie du selbst schon sagtest, ein sonderlich performanter Weg ist das nicht.
MfG ChrisB
--
“Whoever best describes the problem is the person most likely to solve the problem.” [Dan Roam]
-
-
-
-
-
-
Was ist eigentlich so problematisch mit IDs? Man muss sie nicht unnötig vergeben, soviel ist klar, aber sind sie denn irgendwie schädlich? Du scheinst ja eine richtige Aversion gegen IDs zu haben, oder ist es nur eine Allergie? ;)
Das interessiert mich auch brennend, vielleicht ist die Abneigung ja gut begründet, dann denke ich über meinen Standpunkt nochmal nach (es kann ja wohl kaum um das bisschen Traffic gehen).
Ich wäre heilfroh wenn viele Webseiten-Bastler jene Elemente, die immer einzigartig sind vorhersehbar mit einer ID ausstatten würden. Dann nämlich könnte ich sie prima mit GreaseMonkey greifen anstatt mich durch einen langen Dokumentenbaum zu hangeln. Auch für viele andere maschinellen Verarbeitungen fände ich IDs von Vorteil. Sprich: Der Semantik kann und sollte es auch noch zuträglich sein.
Der einzige Nachteil den ich sehe ist - wie gesagt - die größere Datenmenge. Aber wie viel ist das noch nach der Kompression?Ich finde es z.B. nett wie MediaWiki das macht, aus der Wikipedia:
<table id="toc" class="toc"> <tr> <td> <div id="toctitle"> <h2>Inhaltsverzeichnis</h2> </div> <ul> <li class="toclevel-1 tocsection-1"><a href="#Geschichte"><span class="tocnumber">1</span> <span class="toctext">Geschichte</span></a></li> <!-- (...) --> <li class="toclevel-1 tocsection-8"><a href="#Weblinks"><span class="tocnumber">8</span> <span class="toctext">Weblinks</span></a></li> </ul> </td> </tr> </table> ~~~okay nicht das geschickteste, anstatt es mit Nummerierten Listen zu machen schreiben sie die Zahlen in den Quelltext und statt dem <h2> eine ID zu geben bauen sie ein DIV drum und statt verschachtelte Listen zu verwenden verwenden sie Klassen. Aber darum geht's ja nicht, es geht vielmehr darum, dass ich bei einer irgendwie gearteten automatischen Verarbeitung #toc greifen und verarbeiten kann. Andernfalls müsste ich die Position raten (drittes DIV nach erstem <h1> oder so) und dann anhand des Inhalts prüfen ob ich das richtige erwischt habe. Wie man liest stehe ich der Benennung grundsätzlich positiv gegenüber, warum magst du sie nicht Cheatah? -- sh:( fo:| ch:? rl:( br:& n4:& ie:{ mo:} va:) de:µ\_de:] zu:) fl:( ss:| ls:[ js:(
-
-
-
-
-
-
-
Hi,
Mir ist dagegen neu, dass nur window und body merken dürfen, dass sie geladen sind...
HTML 4.01, 18.2.3 Intrinsic events: „This attribute may be used with BODY and FRAMESET elements.“
DOM Level 2, 1.6.5. HTML event types bietet auch nichts gleich erhellendes, für welche Art von Elementen das verwendet werden darf/soll.
Wenn der body endlich da ist, muss man die einzelenen Elemente mühsam mit getElementById oder so rausklauben, was besonders schwierig wird, wenn man die IDs gar nicht kennt, da sie z.B. irgendwie dynamisch aus den Tiefen von asp.net kommen. Ein onload für die einzelnen Elemente würde da Wunder wirken.
Wieder mal habe ich den Eindruck, dass dein Anspruch an Funktionalität, die JavaScript bieten „müsste“, eher einer Bequemlichkeit entspringt, was den Aufbau über verschiedene Universen konsistenter Struktur angeht.
MfG ChrisB
--
“Whoever best describes the problem is the person most likely to solve the problem.” [Dan Roam]-
Hallo,
Wieder mal habe ich den Eindruck, dass dein Anspruch an Funktionalität, die JavaScript bieten „müsste“, eher einer Bequemlichkeit entspringt,
Ja natürlich aus Bequemlichkeit, wie immer beim Programmieren. Wäre es anders, dann würden wir uns noch heute wie in Urzeiten ausschließlich mit Maschinencode rumschlagen (müssen).
Ein onload für jedes Element habe ich wirklich für eine Selbstverständlichkeit gehalten und bin jetzt einfach nur überrascht...
Bin wirklich kein Freund von getElement(s)By... bei jeder Gelegenheit, das nervt einfach nur. Die Elemente liegen doch vor. Muss man sie denn wirklich immer wieder aus dem Urschleim ziehen? Wieso nicht einfach direkt mit ihnen arbeiten?
Inzwischen mache ich es am liebsten so, dass onload alle Elemente mit einer hardcodierten Liste verglichen werden (anhand id), und die in der Liste (ein Objekt) definierten individuellen Eigenschaften bzw. Methoden werden ihnen dabei einmalig zugewiesen, fertig. Dann ist Schluss mit getElement(s)By bis zum Abwinken. Jedes Element weiß dann, was es kann bzw. zu tun hat in einer bestimmten Situation.
Gruß, Don P
-
-
-