Codeschnipsel einfügen

J. Strübig wrote:

Ferry Bolhar schrieb:
J Strübig:
es gibt keinen Browser (zumindest ist mir noch keiner über
den Weg gelaufen) wo das nicht so ist und war, warum sollte es also
morgen nicht mehr funktionieren?
Es kann implementierungs-spezifische Gründe haben, dass etwas,
das bislang funktionert hat, nun plötzlich nicht mehr funktioniert.

Mag ja alles sein, aber es gab bisher kein Browser, wo du nicht auf
Elemente zugreifen konntest obwohl der load Event noch nicht gefeuert,
wenn das Skript im Quelltext hinter dem Element plaziert ist.

Du hast bloss noch keinen solchen Browser entdeckt.

Keiner wird das Verhalten, das seit Netscape 2 oder IE 3 zuverlässig
funktioniert, plötzlich komplett ändern.

Non sequitur.


PointedEars
--

HTML ist keine Programmiersprache!!!11111
Wie getzt, immer noch nicht?????³ Wird's da nicht langsam mal Zeit?

repeat tablecells
until Steffi yells (Jygn zu mir in dagø <ai5oel.3vvi1fr.1 (AT) klingforth (DOT) de>)

Thomas 'PointedEars' Lahn schrieb:

J. Strübig wrote:
Ferry Bolhar schrieb:
J Strübig:
es gibt keinen Browser (zumindest ist mir noch keiner über
den Weg gelaufen) wo das nicht so ist und war, warum sollte es also
morgen nicht mehr funktionieren?
Es kann implementierungs-spezifische Gründe haben, dass etwas,
das bislang funktionert hat, nun plötzlich nicht mehr funktioniert.
Mag ja alles sein, aber es gab bisher kein Browser, wo du nicht auf
Elemente zugreifen konntest obwohl der load Event noch nicht gefeuert,
wenn das Skript im Quelltext hinter dem Element plaziert ist.

Du hast bloss noch keinen solchen Browser entdeckt.

Das sag mir welcher das ist, den ich noch nicht entdeckt habe.

Keiner wird das Verhalten, das seit Netscape 2 oder IE 3 zuverlässig
funktioniert, plötzlich komplett ändern.

Non sequitur.

ich meine dies wäre ein deutschsprachige Newsgroup.

Struppi.

Alexander Clauss:

Man kann sich natürlich auf den Standpunkt stellen, alles was in den
Speizifikationen steht, hat 1:1 in allen Browsern so zu funkionieren,
alles was nicht drin steht, darf man nicht verwenden.

Man darf ja, aber auf eigenes Risiko und sich dabei die Tatsache vor
Augen haltend, dass man ein nicht näher definiertes (und daher aus
Sicht des SW-Herstellers nicht festgelegtes) Verhalten voraussetzt.

Mit dieser
Einstellung wird man sich aber vollkommen und total aus der Web-Realität
entfernen, denn die sieht eben anders aus.

Dann frage ich mich, wozu wir überhaupt ein W3C brauchen, wenn
jeder ohnehin glaubt, machen zu können, was er will. Und das W3C,
RFC's usw., das ist alles keine Realität, oder vielleicht doch?

Mit diesem Standpunkt darf es kein AJAX, kein google-Maps, kein gmail,
uns vieles andere nicht geben.

Wieso? Für AJAX z.B. gibt es genau Definitionen, über welche
Schnittstellen es man wie benutzt. Und es gibt Browser(-Versionen),
die es unterstützen und solche, die es noch nicht tun. Und man kann
genau nachsehen, welche das sind. Wo ist da etwas undefiniert
oder unklar?

Alle die erwähnten Dinge sind neue Features, die in Verwendung
und Funktionsumfang genau definiert sind. Das hat mit "erwarteten
Verhaltensmustern" von Browsern nichts zu tun.

Es gibt zum Einen keinen Browser, der die Web-Standards komplett und vor
allem korrekt implementiert, und zum anderen garantieren diverse Browser
durchaus Dinge, zu denen die Web-Standards gar nichts sagen. Dazu gehört
u.A. auch daß bzw. ob das DOM vor dem onload-Event verfügbar ist.

Genau. Und weil die Web-Standards (aus gutem Grund) nichts
sagt, sollte man sich eben nicht darauf verlassen.

Die
Mozilla-Engine definiert dazu bespielsweise ein extra Event, das feuert
sobald das DOM komplett(!) verfügbar ist. Und das feuert vor dem
onload-Event, je nach Seite durchaus lange davor.

_Das_ ist ja auch wieder etwas Definiertes und es spricht ja nichts
dagegen (abgesehen davon, dass es proprietär ist), dieses Feature
zu verwenden. Aber die Überlegung, dass es "so etwas" auch z.B.
im IE "geben muss", nur weil Mozilla "es kennt" und "weil es so oft
verwendet wird" (wobei man "so oft" noch näher definieren müsste),
erscheint mir einfach zu unsicher, um mich darauf zu verlassen.

Andere Browser haben
ähnliche Mechanismen oder übenehmen z.T. auch gegenseitig die
vorhandenen Dinge, auch wenn kein Web-Standard diese Dinge schon
aufgenommen hat

Dann ist aber in deren Beschreibung enthalten.

Aber selbst das noch unfertige DOM ist durchaus schon vorher
ansprechbar, d.h. in der Realität, auch wenn's hier keine durch
Web-Standards angedeckten Vorgaben gibt.

Kannst du mir _genau_ sagen, _ab wann_ ein Skript, das vor dem
Triggern des onload-Handlers abläuft, DOM-Elemente ansprechen
kann? Eine Zeitangabe, oder ein Event, auf das ich mich in meinem
Code beziehen kann?

Kannst du das, ist es gut. Kannst du es aber nicht, ist jeder Code,
der darauf fußt, schlicht und einfach "Pfusch", weil es sich in einem
Fall - je nach Browser, Rechnergeschwindigkeit, Auslastung, u.a -
ausgehen kann, ein bestimmten Element vorher anzusprechen, im
anderen Fall aber nicht und der Code daher zu einem Laufzeit-
fehler führt.

bestimmten Browser funktioniert hat - schon morgen bei Einsatz einer
neuen Version nicht mehr funktionieren.

Das mag in gewissen Bereichen passieren, in anderen aber nicht, denn
kein Browserhersteller kann es sich leisten, daß mit der nächsten
Browserversion die MS-Seiten, die ebay-Seite, google-Mail usw. nicht
mehr funkioniert.

Wieso sollen diese Seiten nicht mehr funktionieren? Und anders
gefragt: könnten sich Ebay, Google u.a. leisten, dass ihre Seiten
mit neuen Browsern nicht mehr funktionieren?

Wie oben schon erwähnt, mag zwar vieles nicht in den
Web-Standards erwähnt werden, aber das heißt nicht, daß die
Browser-Hersteller das nicht für ihren Browser selbst dokumentiert
haben und damit das Funkionieren bescheinigen.

Ja, gut. Dann zeig mir bitte in der IE-Doku, wo exakt dokumentiert
ist, ab wann ich DOM-Elemente vor dem Triggern von onload()
ansprechen kann.

Daten zu erfassen -, und zweitens - und da muss ich Thomas recht-
geben - ist es Sache des Benutzer zu schauen, wo er sensible
Informationen wie Passwörter u.a. eingibt.

Was hat das damit zu tun, daß die Seite dem User auf diese Weise den
Fokus entziehen bzw. versetzen kann, auch wenn dieses Login an sich für
den User wichtig und gewollt ist?

Naja, sagen wir so: ich würde in eine Seite erst Daten eingeben,
wenn ich sehe, dass sie fertig geladen ist. Und damit stellt sich das
Problem nicht. Das habe ich eben mit "Hineindreschen" gemeint.
Genauso wie du nicht sofort etwas unterschreiben wirst, bloß weil
es ein schönes großes Feld für deine Unterschrift gibt.

sein, solche Daten nicht einfach ohne Rücksicht auf Verluste in
die Tastatur zu dreschen.

Das ist so natürlich Unsinn. Niemand erwartet, daß während der Eingabe
ein Programm oder eine Web-Seite den Focus bzw. den Cursor woanders
hinsetzt. Das ist GUI-technisch ein absoluter GAU.

Wenn die Seite einmal zur Gänze geladen ist, erwarte ich das
auch nicht mehr. Vorher warte ich lieber ab...

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: ferdinand.bolhar-nordenkampf (AT) wien (DOT) gv.at

Ferry Bolhar schrieb:

Kannst du mir _genau_ sagen, _ab wann_ ein Skript, das vor dem
Triggern des onload-Handlers abläuft, DOM-Elemente ansprechen
kann? Eine Zeitangabe, oder ein Event, auf das ich mich in meinem
Code beziehen kann?

Exakt dann, wenn du das Element im HTML Code geschlossen hast.

Struppi.

Ferry Bolhar <bol (AT) adv (DOT) magwien.gv.at> wrote:

Dann frage ich mich, wozu wir überhaupt ein W3C brauchen, wenn
jeder ohnehin glaubt, machen zu können, was er will. Und das W3C,
RFC's usw., das ist alles keine Realität, oder vielleicht doch?

Das Problem am W3C ist, daß es keine Macht hat, Browserhersteller zu
zwingen, ihre Standards sofort und vollständig und korrekt umzusetzen.

Leider definiert das W3C leider oft Dinge, die kein Browser
implementiert und dann in späteren Versionen genau deswegen aus dem
Standard wieder rauswirft, um dann später u.U. das Feature wieder
einzuführen. Beispiel "text-shadow", in CSS 2.0 eingeführt, in CSS2.1
wieder rausgeflogen und in CSS 3 ist es möglicherweise wieder da, oder
auch nicht, wird sich zeigen. Oder auch Dinge definiert, die so komplex
sind, daß es Jahre benötigt, bis es die Browserhersteller
implementieren. Oder auch lange nach dem diverse Browser durch ihre
konkrete Implementierung diverser Features ein Quasi-Stadard geschaffen
haben, das dann offiziell in ihre Spezifikationen einfügt.
Das führt dann leider dazu, daß Theorie (W3C-Standards) und Praxis (die
Browser) doch recht große Unterschiede aufweisen. Das führt dann auch
zwangsläufig dazu, daß man sich nicht immer streng und ausschließlich
auf die W3C-Standards stützen kann.

Bitte verstehe mich nicht falsch, ich bin ein großer Verfechter der
Web-Standards und versuche wo immer möglich die Leute auch zu ermuntern,
die W3C-Standards einzuhalten. Aber wie schon erwähnt, sagen die
W3C-Standards z.T. nicht zu allen Dingen etwas, lassen viele Freiheiten,
und z.T. machen die Browser auch was komplett anderes, so daß man eben
in einigen wenigen Bereichen dann doch etwas pragmatischen vorgehen muß.

Und speziell bzgl. des Originalproblems des Ursprung-Postings im Thread
funktioniert mein Vorschlag sicherlich in nahezu 100% der eingesetzten
Browsern ohne Probleme und hat definitiv weniger schlechte Seiteneffekte
als die onload-Methode. Und selbst falls es mal nicht funktionieren
sollte, hat meine Methode keine Nebenwirkungen, so daß kein Schaden
entsteht.

Mit diesem Standpunkt darf es kein AJAX, kein google-Maps, kein gmail,
uns vieles andere nicht geben.

Wieso? Für AJAX z.B. gibt es genau Definitionen, über welche
Schnittstellen es man wie benutzt.

Und? Genau diese Schnittstellen funkionieren eben nicht in jedem Browser
gleich. Jeder (aktuelle) Browser mag zwar vergleichbare Funktionen
bereitstellen, aber ohne Browser-Sniffing oder "Feature-Sniffing" kommt
keine AJAX-Seite aus. Der IE will anderes behandelt werden, als Firefox.
Man muß sich somit zwangsläufig auch außerhalb der W3C-Standards
bewegen, wenn man eine Web-Seite bauen will, die allgemein benutzbar
sein soll. Es funktioniert schlicht nicht, die W3C-Standards als
alleinige und ausschließliche Glücksseeligkeit zu verstehen.

verwendet wird" (wobei man "so oft" noch näher definieren müsste),
erscheint mir einfach zu unsicher, um mich darauf zu verlassen.

Du musst Dich ja auch nicht darauf verlassen. Wenn es wie hier im
Urposting dieses Threads nur um das Setzen des Fokus geht, kann man sich
ohne Probleme drauf stützen. Falls es tatsächlich irgendwo nicht
funktionieren sollte, ist definitiv kein Schaden entstanden, wogegen die
"onload"-Lösung durchaus "Schaden" oder zumindest Ärger einhandeln kann.

Browserversion die MS-Seiten, die ebay-Seite, google-Mail usw. nicht
mehr funkioniert.

Wieso sollen diese Seiten nicht mehr funktionieren? Und anders
gefragt: könnten sich Ebay, Google u.a. leisten, dass ihre Seiten
mit neuen Browsern nicht mehr funktionieren?

Schau dir den Code von Ebay, google & Co an, und Du wirst sehen, daß
diese fleißig Dinge tun, die in keinem W3C-Standard zu finden sind. Ganz
im Gegenteil, die tun Dinge, die den W3C-Standards widersprechen und
verlassen sich auf browerspeziefische Implementierungen. Die verlassen
sich z.T. voll darauf, daß im HTML-Code stehende Elemente praktisch
sofort von einem nachfolgenden Script über das DOM ansprechbar sind.
Diese Seiten verlassen sich auf konkrete Implementierungen der 2-3
großen Browserhersteller, und pfeifen auf W3C-Standards. Nicht daß ich
das gut finde, ganz im Gegenteil, aber das ist eben mal Fakt.

Schau Dir mal Quelltexte von OpenSource-Browsern wie z.B. Safari oder
Mozilla an. Dort wirst Du feststellen, daß Browserhersteller z.T.
explizit Code und Workarounds einbauen, damit deren Browser mit gewissen
wichtigen Web-Seiten funktioniert. D.h. kein Browserhersteller kann es
sich leisten, seinen Browser ausschließlich auf den W3C-Standards
basieren zu lassen. D.h. heißt dann aber auch, weil sich unmengen
Web-Seiten darauf verlassen, daß das DOM z.T. schon vor onload
zugänglich ist, daß die Browserhersteller ihren Browsern dieses Feature
(auch wenn's nicht dokumentiert ist) nicht wegnehmen können.

Naja, sagen wir so: ich würde in eine Seite erst Daten eingeben,
wenn ich sehe, dass sie fertig geladen ist.

Ich wage zu bezweifeln, daß Dir das nicht passieren kann. Es reicht, daß
ein Werbebanner-Server man nicht schnell antwortet, und schon ist für
den User die Seite eigentlich vollständig da, obwohl da noch irgendwo
was vollkommen unnützes lädt, was einen überhaupt nicht interessiert,
und auf das man auch gar nicht warten will und es vermutlich auch nicht
tut.

--
Alexander

J. Strübig wrote:

Ferry Bolhar schrieb:
Kannst du mir _genau_ sagen, _ab wann_ ein Skript, das vor dem
Triggern des onload-Handlers abläuft, DOM-Elemente ansprechen
kann? Eine Zeitangabe, oder ein Event, auf das ich mich in meinem
Code beziehen kann?

Exakt dann, wenn du das Element im HTML Code geschlossen hast.

Reines Wunschdenken.


PointedEars
--

hoehe=screen.height; breite=screen.width;
Was hat dies mit der Fenstergröße zu tun? Genauso kannst Du fragen:

"Wie groß ist Nachbars Garage?", um zu ermitteln, wie groß wohl mein
Auto sein mag. (Georg Maaß in dcljs <ap315c$r2pon$2 (AT) ID-3551 (DOT) news.dfncis.de>)

J Strübig:

Exakt dann, wenn du das Element im HTML Code geschlossen hast.

Und wie kann ich das von meinem Code aus feststellen?

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: ferdinand.bolhar-nordenkampf (AT) wien (DOT) gv.at

Ferry Bolhar schrieb:

J Strübig:

Exakt dann, wenn du das Element im HTML Code geschlossen hast.

Und wie kann ich das von meinem Code aus feststellen?

Was musst du das feststellen???

<p id="test"></p>
<script type="text/javascript">
alert( document.getElementById('test') );
</script>


Struppi.

J. Strübig:

Exakt dann, wenn du das Element im HTML Code geschlossen hast.

Und wie kann ich das von meinem Code aus feststellen?

Was musst du das feststellen???

p id="test"></p
script type="text/javascript"
alert( document.getElementById('test') );
/script

Wenn ich dich richtig verstehe, meinst du, dass jeder Code,
der sich lexikalisch unterhalb von in HTML definierten DOM-
Elementen befindet, diese bereits ansprechen kann, bevor das
Dokument fertig geladen ist?

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: ferdinand.bolhar-nordenkampf (AT) wien (DOT) gv.at

Ferry Bolhar schrieb:

Wenn ich dich richtig verstehe, meinst du, dass jeder Code,
der sich lexikalisch unterhalb von in HTML definierten DOM-
Elementen befindet, diese bereits ansprechen kann, bevor das
Dokument fertig geladen ist?

Ja.

Struppi.