Servus!
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:
Das habe ich inzwischen gut verstanden. Es gefällt mir, dass *.js Dateien ihre Bedingungen selbst setzen um später damit zu arbeiten.
Ja, das ist alles gut. Das Grundproblem ist aber das Container-Element UM das input-Element herum.
Was die anderen so erheitert, ist, dass Du einen bestehenden Elementbaum im DOM um ein Elternelement erweitern willst. Du müsstest also das input entfernen, an dessen Elternelement ein Kindelement erzeugen und dann das gelöschte input in dieses als Enkel wieder einhängen. Ja ne is klar, oder?
Ich würde erst mal die Aufgabe formulieren:
- Eingabefeld mit Suchvoschlägen
- Erst wenn jemand was eingibt, sollen die Suchvorschläge nachgeladen werden.
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.
In HTML5 verwendet man für so etwas das schon erwähnte datalist-Element. Und das sieht nicht wie von Dir befürchtet aus:
in Firefox:
in Chrome:
Fazit:
Erzeuge input, label und datalist zusammen. Stell Dir mal vor ich suche was und nach 3sec (bei schlechter Datenübertragungsrate, Responsetime) kommen dann Deine Suchvorschläge nachgeladen.
Herzliche Grüße
Matthias Scharwies
Heute mal keine Signatur