Codeschnipsel einfügen

#11

Alexander Clauss wrote:

Quote:

Thomas 'PointedEars' Lahn <PointedEars (AT) web (DOT) de> wrote:
Verwende das onload-Event-Handler-Attribut des body-Elements.

Du weisst aber schon, das das die schlechteste aller Lösung für dieses
Problem ist.

Nein, es ist bei den angegebenen Einschränkungen die einzig brauchbare Lösung.

Quote:

Und insbesondere kann diese Lösung auch Sicherheitsprobleme
aufwerfen, wenn der User eine solche Seite aufruft und nicht alleine
ist.

Blödsinn!

Quote:

Man stelle sich vor, die Seite lädt, das Formular (ein
Login-Formuar) ist da, der User fängt an seinen Usernamen und Passwort
einzugeben. Während der Passorteingabe ist die Seite fertig mit laden,
und jetzt schlägt der onload-Handler zu und setzt den Focus auf das
erste Eingabefeld (das mit dem Usernamen). Der User merkt das natürlich
nicht sofort, und schreibt nun sein Passort munter für alle Anwesenden
lesbar im Klartext ins Feld für den Usernamen zuende.

Gegen völlige Unfähigkeit (sowohl auf UA-Hersteller[1]- als auch User-Seite)
ist leider kein Kraut gewachsen -- wie man an Dir sehr schön sehen kann.
Ein Sicherheitsproblem ist das natürlich nicht.

Quote:

[weiteres Gewäsch]

Ich habe eine Lösung für das (vermeintliche) Problem des OP angeboten, und
bereits darauf hingewiesen, dass er kein Problem hat, sondern sich mit dem
Bestehen auf diesem Feature nur neue Probleme schafft.

Quote:

Ausnamhsweise[tm](!) müsste der Code in Deinem Fall komplett inline sein:

Warum?

Lern lesen!

Quote:

Außerdem habe ich auch keinen Zugriff auf den <HEAD> Bereich da ich
nur Redakteur für eine Typo3 Seite bin.

PointedEars
___________
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=58724

#12

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

Quote:

Gegen völlige Unfähigkeit (sowohl auf UA-Hersteller[1]- als auch User-Seite)
ist leider kein Kraut gewachsen

Das ist mit Sicherheit keine Unfähigkeit des Users. Der weiß nicht was
eine Seite so treiben wird, und wird anfangen, Formulare auszufüllen,
auch wenn ggfs. ein Werbeserver klemmt, und das letzte Bild der Seite
noch nicht ausgeliefert hat und daher der onload-Handler noch nicht
gefeuert hat.

Das ist nichts, was man irgendjemandem vorwefen könnte-

Und was ein UA-Hersteller dagegen tun soll, ist mir auch schleierhaft.
Onload darf eben nur feuern, sobald die Seite komplett geladen ist, und
die Seite erst dann anzeigen, wenn sie komplett geladen ist, damit ja
kein User vorzeitig formulare ausfüllen wird, ist ja wohl keine Lösung.

Quote:

-- wie man an Dir sehr schön sehen kann.

Was ist denn Dir über die Leber gelaufen?

Das Problem existiert und ist nicht dadurch wegzubekommen, daß Du mich
für einen Trottel hälst. Es gibt einige solcher Seiten (sogar Bankseiten
sind mir schon untergekommen), die auf der Login-Seite so ein dämliches
onfocus auf's erste Feld eingebaut haben, wo man dann öfters als
unbeabsichtigt das passwort ins falsche Feld einträgt...

Quote:

Ein Sicherheitsproblem ist das natürlich nicht.

In gewissem Sinn eben doch, wenn eine Seite dafür sorgt, daß z.B. der
User ungewollt und unbeabsichtigt sensible Daten dort eingibt, wo sie
jeder sehen kann.

Quote:

[weiteres Gewäsch]

Soso...

Quote:

Lern lesen!

| Außerdem habe ich auch keinen Zugriff auf den <HEAD> Bereich da ich
| nur Redakteur für eine Typo3 Seite bin.

Und? Lerne lieber selber lesen, und zwar die HTML-Spezifikation.
Script-Elemente sind fast überall im HTML-Code zulässig (ich gehe mal
vom transitional DOCTYPE aus). Der fehlende Zugriff auf den HEAD-Bereich
ist daher vollkommen unnötig.

--
Alexander

#13

Alexander Clauss wrote:

Quote:

Thomas 'PointedEars' Lahn <PointedEars (AT) web (DOT) de> wrote:
| Außerdem habe ich auch keinen Zugriff auf den <HEAD> Bereich da ich
| nur Redakteur für eine Typo3 Seite bin.

Und? Lerne lieber selber lesen, und zwar die HTML-Spezifikation.
Script-Elemente sind fast überall im HTML-Code zulässig (ich gehe mal
vom transitional DOCTYPE aus). Der fehlende Zugriff auf den HEAD-Bereich
ist daher vollkommen unnötig.

Das spielt keine Rolle, da vor dem load-Event nicht von der Existenz der
entsprechenden DOM-Objekte ausgegangen werden kann. Das würdest Du wissen,
wenn Du den Hauch der Spur einer Ahnung hättest, worüber Du schreibst.

Du sonderst eben hier nur heisse Luft ab. Geh sterben.

PointedEars
--
gibt es Variablen, die in allen gängigen Browsern funktionieren?
(Patrick Fiekers in dcljs <am7bvc$3bg2l$1 (AT) ID-83673 (DOT) news.dfncis.de>)

#14

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

Quote:

Das spielt keine Rolle, da vor dem load-Event nicht von der Existenz der
entsprechenden DOM-Objekte ausgegangen werden kann.

Sagt wer?

Die Realität sind jedenfalls so aus, daß es i.d.R. bestens funkioniert.
Abgesehen davon würde ein großer Teil des Webs nicht mehr funktionieren,
sollte das DOM tatsächlich nicht vor dem onload-Element vorhanden sein,
bzw. nicht ansprechbar sein. Nahezu alle Scripte für JS-Menüs und
sonstige JS-Spielereien warten nicht auf ein onload bis sie ihre Arbeit
anfangen und das DOM ändern/ergänzen.

Quote:

Du sonderst eben hier nur heisse Luft ab. Geh sterben.

Wow, Deine Umgangsformen werfen mich echt um, wenn alle Menschen nur so
höflich wären...

--
Alexander

#15

Gregor Kofler wrote:

Quote:

Wenn nicht der load-Event verwendet wird, dann eben Skript am Ende
des Markups (was mit Einschränkungen aufs gleiche hinausläuft).

Eben diese Einschränkungen machen die Alternative fehlerträchtiger als
load-Eventbehandlung.

Quote:

Ich kenne keine "ernsthafteren" Lösungen, die nicht eine dieser 2
Varianten nutzen.

Udiags.

PointedEars

#16

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

Quote:

Das spielt keine Rolle, da vor dem load-Event nicht von der Existenz der
entsprechenden DOM-Objekte ausgegangen werden kann.

Selbst wenn man nicht davon ausgehen könnte, weil's nirgendwo
dokumentiert ist (aber in der Realität kann man das durchaus, denn die
Browser lassen das zu und ein großer Teil der Scripte im Web verlassen
sich auch darauf, daß das geht), spielt das für die Ausgangsfrage, warum
das Script "inline" definiert werden muß, natürlich auch keine Rolle.
Denn Dein Script kann selbstverständlich auch so definiert werden, daß
es nicht im HEAD-Abschnitt steht, nicht inline im BODY-Element definiert
wird, und dennoch im onload-Handler ausgeführt wird:

Eine Möglichkeit wäre z.B. folgendes irgendwo in den Body-Bereich
einfügen:

<script type="text/javascript">
function spitzohrsOnLoadHander() {
/* Dein Code */
}
document.onload = spitzohrsOnLoadHander;
</script>

Quote:

Das würdest Du wissen,
wenn Du den Hauch der Spur einer Ahnung hättest, worüber Du schreibst.

Mit meinem nicht vorhandenen Hauch einer Spur von Ahnung komme ich ganz
gut zurecht.

--
Alexander

#17

Gregor Kofler <usenet (AT) gregorkofler (DOT) at> wrote:

Quote:

Das glaubst jetzt aber nicht wirklich?

Das muß ich nicht glauben, das weiß ich. Du ebenfalls, wie Du ja
ansatzweise schon selbst mit folgender Aussage folgerst...

Quote:

Wenn nicht der load-Event
verwendet wird, dann eben Skript am Ende des Markups (was mit
Einschränkungen aufs gleiche hinausläuft).

Also mal langsam zum mitdenken...

onload wird gefeuert, sobald die komplette Seite mit all ihren Resourcen
(Bilder, externen StyleSheets usw.) usw. geladen ist (Aunahmen sind in
gewissen Situationen die Resourcen, die dynamisch über JavaScript
nachgeladen werden). Ein Script am Ende des Markups kann daher lange
Zeit vor dem feuern des onload-Handler auftreten (kommt auf die
Geschwindigkeit der Verbindung und die Menge an eingebetteten Bildern
an).

Unser "Stitzohr" behaupten nun, erst zu diesem Zeitpunkt währe das DOM
vorhanden bzw. ansprechbar. Hätte er recht, würde Deine folgende
Aussage...

Quote:

Ich kenne keine "ernsthafteren" Lösungen, die nicht eine dieser 2
Varianten nutzen.

falsch sein, denn es kann dann ja nur eine Lösung geben (onload), nicht
zwei. Wie Du aber selbst schon festgestellt hast, arbeiten viele
Lösungen tatsächlich anders und funkionieren in den Browsern durchaus.

--
Alexander

#18

Alexander Clauss wrote:

Quote:

Thomas 'PointedEars' Lahn <PointedEars (AT) web (DOT) de> wrote:
Das spielt keine Rolle, da vor dem load-Event nicht von der Existenz der
entsprechenden DOM-Objekte ausgegangen werden kann.

Selbst wenn man nicht davon ausgehen könnte, weil's nirgendwo
dokumentiert ist

http://www.w3.org/TR/html4/interact/....html#h-18.2.3
http://www.w3.org/TR/DOM-Level-2-Eve...ngs-htmlevents

(Wie oft willst Dich in diesem Thread eigentlich noch zum Brot machen?)

Quote:

(aber in der Realität kann man das durchaus, denn die Browser

"Die Browser", wie gross diese Teilmenge aller UAs lt. Deiner Definition
auch immer sein mag, sind irrelevant. Entscheidend ist, was spezifiziert
ist *und* was nachweislich in der Mehrzahl aller Fälle funktioniert, nicht
Ergebnisse verfälschter Testcases inkompetenter Scriptkiddies.

Quote:

lassen das zu

Es ist also reiner Zufall, wenn es mal funktioniert.

Quote:

und ein großer Teil der Scripte im Web verlassen sich auch darauf, daß das geht),
[...]
script type="text/javascript"
function spitzohrsOnLoadHander() {
/* Dein Code */
}
document.onload = spitzohrsOnLoadHander;
/script

(Ich ziehe die Frage zurück.)

Du magst den Standard zeigen, wo das definiert ist. Weiterhin magst Du
zeigen, dass dies weniger fehlerträchtig ist als die Verwendung des
onload-Attributs.

Quote:

Das würdest Du wissen,
wenn Du den Hauch der Spur einer Ahnung hättest, worüber Du schreibst.

Mit meinem nicht vorhandenen Hauch einer Spur von Ahnung komme ich ganz
gut zurecht.

Einbildung ist ja immerhin auch eine Bildung.

PointedEars

#19

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

Quote:

http://www.w3.org/TR/html4/interact/....html#h-18.2.3
http://www.w3.org/TR/DOM-Level-2-Eve...eventgroupings
-http://www.w3.org/TR/htmlevents

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.

Quote:

auch immer sein mag, sind irrelevant. Entscheidend ist, was spezifiziert
ist

Was ist denn spezifiziert? Deine Behauptung lässt sich jedenfalls in den
von Dir zitierten Abschnitten nicht belegen.

Quote:

(Ich ziehe die Frage zurück.)

Welche Frage ziehst Du zurück?

Quote:

Du magst den Standard zeigen, wo das definiert ist.

??? was genau meinst Du?

Quote:

Weiterhin magst Du
zeigen, dass dies weniger fehlerträchtig ist als die Verwendung des
onload-Attributs.

Das ist exakt genauso fehlerträchtig, wie Deine Verwendung des
onload-Attributes, weil es exakt das selbe tut, wie Deine onload-Lösung,
nur eben nicht inline. Das war nur der Beweis, daß Deine anfängliche
Behauptung, es ginge nur inline, falsch ist.

--
Alexander

#20

Alexander Clauss wrote:

Quote:

Thomas 'PointedEars' Lahn <PointedEars (AT) web (DOT) de> wrote:
http://www.w3.org/TR/html4/interact/....html#h-18.2.3
http://www.w3.org/TR/DOM-Level-2-Eve...eventgroupings
-http://www.w3.org/TR/htmlevents

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.

auch immer sein mag, sind irrelevant. Entscheidend ist, was spezifiziert
ist

Was ist denn spezifiziert? Deine Behauptung lässt sich jedenfalls in den
von Dir zitierten Abschnitten nicht belegen.

(Ich ziehe die Frage zurück.)

Welche Frage ziehst Du zurück?

Es wird wohl langsam Zeit für eine Merkbefreiung.

Quote:

Du magst den Standard zeigen, wo das definiert ist.

??? was genau meinst Du?

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

Quote:

Weiterhin magst Du zeigen, dass dies weniger fehlerträchtig ist als
die Verwendung des onload-Attributs.

Das ist exakt genauso fehlerträchtig, wie Deine Verwendung des
onload-Attributes, weil es exakt das selbe tut, wie Deine onload-Lösung,

Mitnichten.

PointedEars
--
Der erfahrene IE-Fahrer weiß, daß man Slalom am besten im ersten Gang fährt,
weil schnelles Lenkradumreißen bei IE zum Lenkradabreißen führt. Wer
sportlich fahren will, muß Netscape fahren und hin und wieder auch mal
anschieben. ;-) --Georg Maaß, dcljs, <amuqrl$91i3q$1 (AT) ID-3551 (DOT) news.dfncis.de>