Codeschnipsel einfügen

Thomas 'PointedEars' Lahn <PointedEars (AT) web (DOT) de> wrote:

Dein Ansatz ist nicht nur komplett proprietär, er ist noch nicht einmal
universell in Referenzmaterial dokumentiert.

Durchaus möglich, daß ich da was verwechselt haben sollte und statt

document.onload = ...

besser

window.onload = ...

hätte schreiben sollen. Aber da wohl alle Browser auch document.onload
implementieren, sollte das kein prinzipielles Problem darstellen. Aber
window.onload funktioniert in dem beispiel genause und dieses wird
selbst in den von Dir zitierten W3C-Dokumenten in einem Beispiel
verwendet, ist also wohl nicht so proprietär, wie Du das so darstellst.
Damit hast Du also immer noch nicht gezeigt, wieso Deine anfängliche
Behauptung korrekt sein muß.

Ich bin gerne bereit aus Fehlern zu lernen, aber bisher kam von Dir
bisher außer irgendwelchen Behauptungen ohne Beweise/Belege nur
Beleidigungen. Ich hätte nie gedacht, daß die einfache harmlose Frage,
"warum nur eine inline-Lösung im onload-Handler des BODY-Elements
möglich ist", so viel böses Blut hervorbringen kann ("geh sterben",
"Merkbefeit", usw.).

--
Alexander

Alexander Clauss:

Und wo genau steht dort das was Du behauptest? Da steht nur, daß der
Onload-Handler gefeuert wird, sobald alle Resourcen der Seite fertig
geladen sind (das bestreitet aber auch niemand). Aber da steht nicht,
daß das DOM auch erst zu diesem Zeitpunkt erreichbar ist.

Es steht aber auch nicht drin, dass es _früher erreichbar ist. Genauer
gesagt: bevor nicht der onLoad-Handler getriggert wird, kannst du dich
nicht darauf verlassen, dass DOM bzw. Elemente davon ansprechbar
sind. Oder noch anders ("informatischer" ;-): die Ansprechbarkeit von
DOM-Elementen vor dem Triggern von onLoad ist undefiniert,
browser-spezifisch und kann - auch wenn sie jahrelang in einem
bestimmten Browser funktioniert hat - schon morgen bei Einsatz einer
neuen Version nicht mehr funktionieren. Dass das scheinbar etliche
Web-Autoren nicht wissen, macht die Sache nicht besser und ändert
vor allem an bestehenden Tatsachen nichts.

Bzgl. der "Gefährlichkeit" des Fokussierens auf eine bestimmtes
Eingabefeld möchte ich nur feststellen, dass dies erstens nicht die
Frage des OP war - möglicherweise hat er keine "gefährlichen"
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. So weit sollte jeder
sein, solche Daten nicht einfach ohne Rücksicht auf Verluste in
die Tastatur zu dreschen. Du schaust ja bei einer Unterschrift
auch vorher hin, was du unterschreibst, oder? Hier ist jeder
aufgeforder, selbst durch vernünftiges Handeln diese Maß an
"Gefahr" hintanzuhalten.

LG, Ferry

--
Ing Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: bol (AT) adv (DOT) magwien.gv.at

Alexander Clauss wrote:

Thomas 'PointedEars' Lahn <PointedEars (AT) web (DOT) de> wrote:
Dein Ansatz ist nicht nur komplett proprietär, er ist noch nicht einmal
universell in Referenzmaterial dokumentiert.

Durchaus möglich, daß ich da was verwechselt haben sollte und statt

document.onload = ...

besser

window.onload = ...

hätte schreiben sollen. Aber da wohl alle Browser auch document.onload
implementieren,

Das kannst Du nicht wissen.

sollte das kein prinzipielles Problem darstellen.

Non sequitur.

Aber window.onload funktioniert in dem beispiel genause

Tut es nicht.

und dieses wird selbst in den von Dir zitierten W3C-Dokumenten in einem
Beispiel verwendet, ist also wohl nicht so proprietär, wie Du das so darstellst.

Non sequitur. Beispiele in Spezifikationen sind nie normativ.

Damit hast Du also immer noch nicht gezeigt, wieso Deine anfängliche
Behauptung korrekt sein muß.

Doch, habe ich. Das onload-Attribut und der load-Event ist spezifiziert;
die onload-Eigenschaft nicht. Zumal es sich bei `window' und `document'
nicht nur um host-definierte Eigenschaften sondern auch Referenzen auf
Host-Objekte handelt. Und jetzt bitte die studentische Transferleistung.

Ich bin gerne bereit aus Fehlern zu lernen, aber bisher kam von Dir
bisher außer irgendwelchen Behauptungen ohne Beweise/Belege nur
Beleidigungen. Ich hätte nie gedacht, daß die einfache harmlose Frage,
"warum nur eine inline-Lösung im onload-Handler des BODY-Elements
möglich ist", so viel böses Blut hervorbringen kann ("geh sterben",
"Merkbefeit", usw.).

Es ist die Art und Weise, wie Du Dein (vermeintliches) Wissen präsentierst,
welche solche Reaktionen heraufbeschwört.


PointedEars
--
Die Bereitschaft fühlender Wesen, Deinen Code näher anzuschauen, liegt wohl
selbst auf logarithmischen Skalen unter Null (das geht genau dann, wenn der
Leidensdruck dieser Wesen beim Anschauen größer wird als die mathematische
Notwendigkeit für Werte größer Null). -- Dietmar Meier in dcljs

Ferry Bolhar schrieb:

Es steht aber auch nicht drin, dass es _früher erreichbar ist. Genauer
gesagt: bevor nicht der onLoad-Handler getriggert wird, kannst du dich
nicht darauf verlassen, dass DOM bzw. Elemente davon ansprechbar
sind. Oder noch anders ("informatischer" ;-): die Ansprechbarkeit von
DOM-Elementen vor dem Triggern von onLoad ist undefiniert,
browser-spezifisch und kann - auch wenn sie jahrelang in einem
bestimmten Browser funktioniert hat - schon morgen bei Einsatz einer
neuen Version nicht mehr funktionieren.

Mal abgesehen davon, dass es keinen onLoad Event gibt - JS ist case
sensitive - 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?

Weil ein Browserhersteller sagt, "es steht nicht klar in den Specs
definiert, also implementiere ich es anders als alle anderen"?

Dass das scheinbar etliche
Web-Autoren nicht wissen, macht die Sache nicht besser und ändert
vor allem an bestehenden Tatsachen nichts.

Die Tatsache ist, das es genauso funktioniert. Ich lasse mich natürlich
eines besseren belehren, aber nur aus akademisch philosophischen Gründen
auf Tatsachen zu schliessen, ist nicht praktikabel.

Und mal davon abgesehen wird es eher umgekehrt laufen, die Specs werden
i.d.R. an die vorhandenen Gegebenheiten angepaßt, nicht umgekehrt.

Bzgl. der "Gefährlichkeit" des Fokussierens auf eine bestimmtes
Eingabefeld möchte ich nur feststellen, ...

Auch wenn ich dir prinzipiell zustimme, ist es aber auch hier eher
umgekehrt, die Browserhersteller müssen sich auf DAUs einstellen, d.h.
das was Claus beschreibt ist Realität und kommt exakt so häufig vor, ob
das klug ist oder nicht weiß der DAU nicht (was sich ja schon aus seinem
Namen ergibt). Früher oder später, falls diese Funktion zu
sicherheitsrelevanten Problemen führt, kann es passieren, dass genau das
nicht mehr funktioniert.

Es wird meiner Meinung also vermutlich genau umgekehrt sein, das
zugreifen auf das DOM vor dem onload Event wird spezifiziert werden und
das Fokusieren eines Elementes beim onload Event wird unterbunden
werden, aus den genannten Gründen.

Struppi.

Ferry Bolhar schrieb:

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. So weit sollte jeder
sein, solche Daten nicht einfach ohne Rücksicht auf Verluste in
die Tastatur zu dreschen. Du schaust ja bei einer Unterschrift
auch vorher hin, was du unterschreibst, oder? Hier ist jeder
aufgeforder, selbst durch vernünftiges Handeln diese Maß an
"Gefahr" hintanzuhalten.

Eben nicht. Es ging Alexander darum, daß $Benutzer, während die Seite
noch im Hintergrund lädt die Eingabe im _richtigen_ Feld beginnt, aber
durch ein beim onload gesetzten Focus *mitten im Tippvorgang* auf ein
anderes Feld umgeleitet wird. Wie, außer erst nach dem kompletten Laden
mit der Eingabe aunzufangen, soll irgendein Benutzer dieses Verhalten
unterbinden?

--
The first time you'll get a Microsoft product, that doesn't suck,
will be the day they start producing vacuum cleaners. (unbekannt)

J Strübig:

Mal abgesehen davon, dass es keinen onLoad Event gibt - JS ist case
sensitive -

Ja, sorry.

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.
Ist ein bestimmtes Verhalten durch einen Standard vorgegeben,
dann wird ein Entwickler darauf achten, dass in neuen oder
erweiterten Implementierungen seiner SW dieses Verhalten
auch weiterhin gegeben ist. Gibt es eine solche Vorgabe aber
nicht, so wird der Entwickler sich auch nicht darum kümmern,
dass das Verhalten beibehalten wird. Bleibt es, ist es gut, bleibt
es aber nicht, haben alle, die sich darauf verlassen haben, Pech
gehabt. Und darauf wollte ich hinaus - man kann (und sollte)
sich eben nicht darauf verlassen.

Es wird schon seinen Grund haben, warum im DOM nicht
exakt ausspezifiziert wurde, ab wann genau ein DOM-Element
ansprechbar ist, meinst du nicht? Es gibt einen klaren Zeit-
punkt, zu dem es garantiert ansprechbar ist - wenn der onload
Handler getriggert wird. Das muss genügen, vorher ist graue
Zone, und jeder, der sich da reinwagt, tut das auf eigenes
Risiko.

Weil ein Browserhersteller sagt, "es steht nicht klar in den Specs
definiert, also implementiere ich es anders als alle anderen"?

Wie schon gesagt: nicht bewußt und absichtlich, aber wenn
man nicht darauf achtet, kann das passieren, ja.

Dass das scheinbar etliche
Web-Autoren nicht wissen, macht die Sache nicht besser und ändert
vor allem an bestehenden Tatsachen nichts.

Die Tatsache ist, das es genauso funktioniert. Ich lasse mich natürlich
eines besseren belehren, aber nur aus akademisch philosophischen Gründen
auf Tatsachen zu schliessen, ist nicht praktikabel.

Ich habe schon des öfteren erlebt, dass bestimmtes Verhalten
von Software, das nicht genau ausspezifiziert war, sich von
einer Version zur nächsten geändert hat. Und dass Program-
mierer oder Anwender, die ungerechtfertigt von diesem
Verhalten ausgegangen sind, dann ziemlich lange Gesicher
hatten. Es bleibt ein Restrisiko und es ist letztlich die Ent-
scheidung jedes Einzelnen, ob er es eingeht. Ich will mich
deswegen auch nicht streiten; ich weise nur darauf hin bzw.
stimme Thomas zu, der das getan hat. Ich würde - in diesem
Fall - die Variante mit dem onload-Handler wählen, umso
mehr, weil ich keinen Vorteil in den Alternativlösungen sehe.

Auch wenn ich dir prinzipiell zustimme, ist es aber auch hier eher
umgekehrt, die Browserhersteller müssen sich auf DAUs einstellen, d.h.
das was Claus beschreibt ist Realität und kommt exakt so häufig vor, ob
das klug ist oder nicht weiß der DAU nicht (was sich ja schon aus seinem
Namen ergibt). Früher oder später, falls diese Funktion zu
sicherheitsrelevanten Problemen führt, kann es passieren, dass genau das
nicht mehr funktioniert.

Was Claus beschreibt, mag in Einzelfällen zutreffen; es gibt
aber sicher Anwendungsfälle, wo das Fokussieren eines
bestimmten Eingabefeldes beim Laden eines Dokumentes
Sinn macht. Ich nehme an, dass sich der OP bei seiner Idee,
das zu tun, etwas gedacht hat.

Es wird meiner Meinung also vermutlich genau umgekehrt sein, das
zugreifen auf das DOM vor dem onload Event wird spezifiziert werden und
das Fokusieren eines Elementes beim onload Event wird unterbunden
werden, aus den genannten Gründen.

Das will ich nicht hoffen. Das hieße, dass dein Browser klüger
sein will als du! Willst du das wirklich?

LG, Ferry

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

Kai Norhausen wrote:

Ferry Bolhar schrieb:
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. So weit sollte jeder sein, solche Daten nicht einfach ohne
Rücksicht auf Verluste in die Tastatur zu dreschen. Du schaust ja bei
einer Unterschriftauch vorher hin, was du unterschreibst, oder? Hier
ist jeder aufgeforder, selbst durch vernünftiges Handeln diese Maß an
"Gefahr" hintanzuhalten.

Eben nicht. Es ging Alexander darum, daß $Benutzer, während die Seite
noch im Hintergrund lädt die Eingabe im _richtigen_ Feld beginnt, aber
durch ein beim onload gesetzten Focus *mitten im Tippvorgang* auf ein
anderes Feld umgeleitet wird. Wie, außer erst nach dem kompletten Laden
mit der Eingabe aunzufangen, soll irgendein Benutzer dieses Verhalten
unterbinden?

Er könnte beispielsweise Script-Support ganz oder teilweise abschalten.

Alexanders Argument hätte dann *geringfügiges* Gewicht, wenn heutzutage noch
ein DAU vorstellbar wäre, der, vernünftige Dokumentstrukturierung des Autors
vorausgesetzt, schnell genug das entsprechende Formularfeld fände.


PointedEars
--
Kopf = {};
Kopf.onzahnweh = aua;
function aua(){alert('Aua!');}
€(Georg Maaß in dcljs <b57n6s$26cacq$1 (AT) ID-3551 (DOT) news.dfncis.de>)

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

Es steht aber auch nicht drin, dass es _früher erreichbar ist. Genauer
gesagt: bevor nicht der onLoad-Handler getriggert wird, kannst du dich
nicht darauf verlassen, dass DOM bzw. Elemente davon ansprechbar
sind.

Die Realität wollen wir nicht aus den Augen lassen.

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. Mit dieser
Einstellung wird man sich aber vollkommen und total aus der Web-Realität
entfernen, denn die sieht eben anders aus.

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

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. 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. Andere Browser haben
ähnliche Mechanismen oder übenehmen z.T. auch gegenseitig die
vorhandenen Dinge, auch wenn kein Web-Standard diese Dinge schon
aufgenommen hat (das W3C benötigt dann auch zeitweise ewig, die
bestehenenen defacto-standards in offizielle Standards zu übernehmen,
d.h. z.T. hinken die offiziellen endgültigen Standards der Realität weit
hinterher). 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.

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. 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.

Bzgl. der "Gefährlichkeit" des Fokussierens auf eine bestimmtes
Eingabefeld möchte ich nur feststellen, dass dies erstens nicht die
Frage des OP war

Muss ja auch nicht. Ich habe nur geschrieben, daß das Probleme
verursachen kann. Erfahrungsgemäß denkt kaum ein Anfänger an solche
Probleme, warum soll ich also auf Probleme nicht aufmerksam machen?

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?

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.

Du schaust ja bei einer Unterschrift
auch vorher hin, was du unterschreibst, oder?

Ich will ja mich auf dieser Seite einloggen (bzw. irgendwo
unterschreiben). Aber genausowenig wie ich will daß der Focus
unvermittelt und unvorhersehbar woanders hin gesetzt wird, will ich bei
einer realen Unterschrift, daß mein Gegenüber mir dabei das Blatt
wegzieht während ich noch schreibe. Und genau das ist in etwa das, was
die Web-Seite hier machen könnte. Das ist etwas, was man weder in der
richtigen Leben, noch im Web erwartet.


--
Alexander

Thomas 'PointedEars' Lahn <PointedEars (AT) web (DOT) de> wrote:

Er könnte beispielsweise Script-Support ganz oder teilweise abschalten.

In Zeiten von AJAX & Co ist das eher kein guter Vorschlag. Zuviele
Seiten laufen ohne JS nicht mehr.

Und nur bei Bedarf JS abzuschalten setzt voraus, daß man im Voraus schon
weiß, was die Seite alles mit JS anstellen wird. Dazu muß man sie aber
erst mal besuchen und dann kann es schon zu spät sein und man ist schon
die "Falle" gelaufen und der Kollege hätte u.U. das Passwort sehen
können.

Alexanders Argument hätte dann *geringfügiges* Gewicht, wenn heutzutage noch

Wow, nun gibst Du sogar zu, daß meine Argumentation doch nicht ganz
gewichtslos war...

--
Alexander

Thomas 'PointedEars' Lahn <PointedEars (AT) web (DOT) de> wrote:

Das kannst Du nicht wissen.

Ich kann das für eine ganze Reihe von Browsern wissen.

Aber window.onload funktioniert in dem beispiel genause

Tut es nicht.

Wo funktioniert es nicht? Ein Browser der zu 100% die
Web-Spezifikationen und sonst nichts anderes implementiert akzeptiere
ich als Antwort nicht, denn der existiert nicht und der wäre im Web auch
noch vollkommen unbrauchbar.

Non sequitur. Beispiele in Spezifikationen sind nie normativ.

Klar. Aber kein Browser implementiert zu 100% und fehlerfrei die
Spezifikationen. Insofern kannst Du Dich nicht auf Spezifikationen
verlassen, sondern musst auch die Realität berücksichtigen.

Es ist die Art und Weise, wie Du Dein (vermeintliches) Wissen präsentierst,
welche solche Reaktionen heraufbeschwört.

Soso. Was habe ich denn so Schlimmes angestellt? Selbst wenn ich was
falsches gesagt oder mich geirrt haben sollte, ist es sicherlich nicht
normales Verhalten, wenn man dann sofort "vollkommene Unfähigkeit"
bescheinigt bekommt, "Gewäsch", "geh sterben" usw. an den Kopf geworfen
bekommt. Dein komplettes Verhalten hier ist definitiv daneben. Wenn Dein
Ego es nicht verkraftet, daß man Dir widerspricht, dann geh die Sache
einfach mal langsamer an.

--
Alexander