nicht angemeldet
Hallo Martin,
Linuchs möchte einen Container (in seinem Fall ein div) um sein input-Element, aber aus mir unerfindlichen Gründen will er den nicht ins Markup schreiben, sondern nachträglich mit Javascript bauen, während das input-Element schon existiert.
Das ist eine konsequente Weiterentwicklung von hier empfohlenen Richtlinien.
Ich soll ja nicht mehr <body onload=... verwenden und auch Event-Handler nicht beim Element einrichten, sondern sowas nutzen, um z.B. eine unbestimmte Menge Info-Schaltflächen klickbar zu machen:
window.addEventListener('DOMContentLoaded', function ( ) {
obj_help = document.getElementsByClassName( "help" );
for ( i=0; i<obj_help.length; i++ ) {
...
obj_help[i].addEventListener('click', function (event) { // click-Event setzen
... });
}
}
Das habe ich inzwischen gut verstanden. Es gefällt mir, dass *.js Dateien ihre Bedingungen selbst setzen um später damit zu arbeiten.
So sind auch Vorschlagsbereiche in vielen Programmen vorhanden. Da kann ich genausogut die Routinen von Javascript einrichten lassen und muss das in den einzelnen Programmen nicht selbst tun.
Also quasi ein Gewächshaus bauen, während die Stiefmütterchen schon blühen.
Sehr gut verstanden. Wenn ich keine Stiefmütterchen habe, brauche ich auch kein Gewächshaus. Oder noch besser: Erst dann, wenn ein Kunde Stiefmütterchen will, brauche ich einen Verkaufsraum mit Kasse. Das ist virtual reality. Der Mond muss doch auch erst dann scheinen, wenn einer hinguckt.
Also erst dann, wenn jemand einen Ort sucht, muss ich das Feld für die Vorschlagswerte einrichten und spare mir das ganze HTML-Gedöns auf Verdacht.
An dem Bild ist gut zu sehen, warum das Vorschlagsfeld kein Sibling des Input-Feldes ist. Dann könnte es ja den Bildschirm-Inhalt nicht überlappen, sondern würde die folgenden Felder nach unten stoßen und beim Schließen wieder nach oben zucken. Sieht doch sch** aus.
Linuchs
Henry
Der Martin
Matthias Scharwies
Auge
Linuchs
Gunnar Bittersmann
MudGuard
Tabellenkalk
TS
Orlok
Rolf B