Codeschnipsel einfügen

Alexander Clauss wrote:

Thomas 'PointedEars' Lahn <PointedEars (AT) web (DOT) de> wrote:
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...

Keineswegs. man Konjunktiv


PointedEars
--
Was funktioniert in Tabellen bei NN4 wirklich verläßlich? Nicht mal die
Abstürze in Zusammenhang mit Tabellen sind verläßlich, auch wenn sie
häufig vorkommen. (Georg Maaß in dcljs <3D6CCAEC.8060702 (AT) vnett (DOT) de>)

Kai Norhausen schrieb:

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?

Der Benutzer kann gar nichts unterbinden. Das YUI-framework bietet einen
onavailable eventhandler an.

br | rb
--
Sie freuten sich riesig, wenn eine Maschine nach sechs Stunden etwas
fertig brachte, wozu jeder Mensch auf der Straße für 2 Cent fähig
gewesen wäre. Anschließend ließen sie sich Bananen- und Sushi-Pizza
kommen und schliefen vor der Tastatur ein. [aus T.P., Heiße Hüpfer]

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. Keiner
wird das Verhalten, das seit Netscape 2 oder IE 3 zuverlässig
funktioniert, plötzlich komplett ändern.

Handler getriggert wird. Das muss genügen, vorher ist graue
Zone, und jeder, der sich da reinwagt, tut das auf eigenes
Risiko.

Wie gesagt, seit ca. 1998 funktioniert das zuverlässig und mir ist kein
Browser bekannt wo das nicht so ist, dass es nicht in den Specs ist kein
Kriterium, diese hinken gerne mal der tatsächlichen Entwicklung hinterher.

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.

In dem konkreten Beispiel läßt sich das von Claus beschriebene Phänomen
verhindern, wenn du den Fokus unmittelbar setzt und nicht abwartest bis
der Event gefeuert wird (was u.U. lange dauern kann, wenn z.b. ein Bild
gerade nicht verfügbar ist oder ein externes Bild von einem langsameren
Server)

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 mag ja Sinn machen, ich finde das bei google auch seh praktisch. Aber
nicht alles was Sinn macht ist in jedem Fall gut.

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?

Wieso klüger? Alles was eine Sicherheitslücke darstellen kann, wurde
bisher abgeschafft oder mit einer Warnmeldung versehen. Damit tragen die
Browserentwicklung der Phanatsie von Online Betrügern Rechung, das halte
ich für keine schlechte Sache.

Struppi.

Gregor Kofler schrieb:

J. Strübig meinte:

Es wird meiner Meinung also vermutlich genau umgekehrt sein, das
zugreifen auf das DOM vor dem onload Event wird spezifiziert werden

Wieso spezifizieren? Das geht ja jetzt schon.

Sag ich ja.

Wie wär's mit dem load-Event?

Joh, ich hab's gemerckt ;-)

und das Fokusieren eines Elementes beim onload Event wird unterbunden
werden, aus den genannten Gründen.

Schmarrn. Warum auch? Damit dann trilliarden Script-Kinder aufheulen,
weil ihre tolle setfocus-Routine nicht mehr klappt?

Aha? Du hast hier noch nie eine Anfrage gelesen, wo sich einer über die
same origin policy beschwert hat? Ob das alles Skript Kiddies waren?
Oder als Microsoft den fullscreen Modus abgeschafft hat, bzw. das resizen eines
solchen Fensters?
Das ist ja der Punkt, das so beliebte Features, die eine
Sicherheitslücke herbeiführen könnten, in dem Moment wo diese ausgenutzt
wird, eben abgeschafft oder eingeschränkt werden, das ist doch nicht neues.

Struppi.

Thomas 'PointedEars' Lahn schrieb:

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

Er ist ein DAU, keine Ahnug ob du solche Leute kennst, für die gibt es
solche Begriffe nicht.

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.

Und du hälst es nicht für möglich, dass der load Event sich verzögern
kann, weil ein Server überlastet ist, die Verbindung des Users blockiert
ist oder was auch immer die Übertragung Teile des Dokumentes - wir reden
ja vom load Event, d.h. es betrifft alle eingebundenen Resourcen -
verlangsamt?

Struppi.

J. Strübig wrote:

Thomas 'PointedEars' Lahn schrieb:
Er könnte beispielsweise Script-Support ganz oder teilweise abschalten.

Er ist ein DAU, keine Ahnug ob du solche Leute kennst, für die gibt es
solche Begriffe nicht.

Ich kenne genug DAUs, und davon wissen einige, wie man Script-Support
abstellt. Stand ja oft genug in der ComputerBLÖD und ähnlichen Magazinen.

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.

Und du hälst es nicht für möglich, dass der load Event sich verzögern
kann, weil ein Server überlastet ist, die Verbindung des Users blockiert
ist oder was auch immer die Übertragung Teile des Dokumentes - wir reden
ja vom load Event, d.h. es betrifft alle eingebundenen Resourcen -
verlangsamt?

DAUs haben Breitbandverbindungen (meist von T-Offline) und greifen auf
Server zu, die für viele DAUs ausgelegt sind. Natürlich kann immer etwas
nicht wie erwartet funktionieren -- das lässt sich aber dann auch nicht mit
clientseitigem Scripting erschlagen. Insofern halte ich diese
Nebendiskussion für rein akademisch und ein Ablenkungsmanöver. JFTR: Ich
schrieb jetzt bereits zweimal in diesem Thread, dass der OP sich mit dem
Bestehen auf diesem Feature Probleme schafft.


PointedEars
--
"Use any version of Microsoft Frontpage to create your site. (This won't
prevent people from viewing your source, but no one will want to steal it.)"
Tipp gegen Quellcode-Klau <http://www.vortex-webdesign.com/help/hidesource.htm>

Thomas 'PointedEars' Lahn schrieb:

J. Strübig wrote:
Thomas 'PointedEars' Lahn schrieb:
Er könnte beispielsweise Script-Support ganz oder teilweise abschalten.
Er ist ein DAU, keine Ahnug ob du solche Leute kennst, für die gibt es
solche Begriffe nicht.

Ich kenne genug DAUs, und davon wissen einige, wie man Script-Support
abstellt. Stand ja oft genug in der ComputerBLÖD und ähnlichen Magazinen.

Ein DAU liest keine solchen Magazine, ich kenne zumindest keine, das was
du meinst sind eher Hobbydaus.

DAUs haben Breitbandverbindungen (meist von T-Offline) und greifen auf
Server zu, die für viele DAUs ausgelegt sind.

Aha.

Natürlich kann immer etwas
nicht wie erwartet funktionieren -- das lässt sich aber dann auch nicht mit
clientseitigem Scripting erschlagen.

Aber wie es so ist, wenn genug DAUs mit diesem Problem konfrontiert
werden und es dazu führt dass bei wenigen das Konto geplündert wird,
kann es passieren das diese Funktion beschränkt werden, ob du, ich oder
Trilliarden von Skript Kiddies das wollen oder nicht.

Nebendiskussion für rein akademisch und ein Ablenkungsmanöver.

Das könnte man auch für deine Ausführungen zur Verwendung von innerHTML
sagen.

Struppi.

J. Strübig wrote:

Thomas 'PointedEars' Lahn schrieb:
Nebendiskussion für rein akademisch und ein Ablenkungsmanöver.

(sic!)

Du könntest wenigstens ganze Sätze zitieren, wenn Du meine Aussagen aus dem
Kontext reisst.

Das könnte man auch für deine Ausführungen zur Verwendung von innerHTML
sagen.

Genau das meine ich mit Ablenkungsmanöver. Und Du liegst falsch: die
Verwendung von `innerHTML' statt DOM-Methoden kann nachweislich negative
Folgen haben.


EOD

PointedEars
--

[Stehlen von Links durch Manipulation der Statuszeile verhindern]
Vielleicht solltest du in diesem Fall dir das Ganze mit dem WWW noch mal

überlegen und statt dessen Landschaftsgärtner, Busfahrer oder so was
ähnliches werden. (Philip Steffan in dcljs <3DD3FEC7.5090309 (AT) lunique (DOT) de>)

Thomas 'PointedEars' Lahn schrieb:

Das könnte man auch für deine Ausführungen zur Verwendung von innerHTML
sagen.

Genau das meine ich mit Ablenkungsmanöver. Und Du liegst falsch: die
Verwendung von `innerHTML' statt DOM-Methoden kann nachweislich negative
Folgen haben.

Genau wie das versehentlich eintippen eines Passworts in einem falschen
Feld aufgrund (unnötig) verzögerter Fokusierung.

Wobei ich negative Folgen bei der Entwicklung eines Skriptes eher
verkrafte, als negative Folgen beim benutzen. Bei der Entwicklung habe
ich die Möglichkeit etwas zu ändern, während der Nutzer nur hoffen kann.
Aber jeder wie er's mag.

Struppi.

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

DAUs haben Breitbandverbindungen (meist von T-Offline) und greifen auf
Server zu, die für viele DAUs ausgelegt sind.

In welcher Spezifikation ist das festgelegt?

--
Alexander