Suchfunktion auf Homepage

[Gerhard]

Hallo, wie kann man eine Suchfunktion auf einer Internet-Seite realisieren? Gesucht werden soll nur auf der aktuellen Seite. Besten Dank für Eure Tipps Gerhard

[dedlfix]

Tach!

Gesucht werden soll nur auf der aktuellen Seite.

Das haben die Browser schon eingebaut. Mit Strg+F erreicht man das beispielsweise.

dedlfix.

[Gunnar Bittersmann]

@@dedlfix

Gesucht werden soll nur auf der aktuellen Seite.

Das haben die Browser schon eingebaut. Mit Strg+F erreicht man das beispielsweise.

Richtige Antwort. Aber ich denke, du hättest noch dazuschreiben sollen, dass eine Webseite was anderes ist als eine Website und nachfragen, ob vielleicht letzteres gemeint ist.

😷 LLAP

[Der Martin]

Hallo Gunnar,

Gesucht werden soll nur auf der aktuellen Seite.

Das haben die Browser schon eingebaut. Mit Strg+F erreicht man das beispielsweise.

Richtige Antwort. Aber ich denke, du hättest noch dazuschreiben sollen, dass eine Webseite was anderes ist als eine Website und nachfragen, ob vielleicht letzteres gemeint ist.

genau, und falls ja, dann ...?

Dann wird's nämlich für Laien (und als solchen schätze ich Gerhard aufgrund seiner Fragestellung ein) richtig anspruchsvoll.

Werden die Seiteninhalte aus einer Datenbank generiert? - Dann müsste man die nach den gewünschten Suchbegriffen durchsuchen, und wenn man den Suchtreffer verlinken will (sonst wäre er weitgehend nutzlos), muss man auch die Adresse der Seite raussuchen, auf der dieses Textfragment dann stehen würde.
Oder sind es nur statische HTML-Dateien? - Dann müsste man die HTML-Dateien eine nach der anderen öffnen, nach dem gegebenen Suchbegriff durchsuchen und die Ergebnisse aufsammeln. Oder ein externes Tool wie etwa grep drauf loslassen - vorausgesetzt, das gebuchte Hosting-Paket erlaubt und bietet solche Möglichkeiten.

Also alles andere als trivial.

Live long and pros healthy,
 Martin

[Gunnar Bittersmann]

@@Der Martin

Dann wird's nämlich für Laien (und als solchen schätze ich Gerhard aufgrund seiner Fragestellung ein) richtig anspruchsvoll.

Wenn man eine Suche selber programmieren will, dann ja. Aber ich glaube, das will Gerhard nicht.

😷 LLAP

[dedlfix]

Tach!

Gesucht werden soll nur auf der aktuellen Seite.

Das haben die Browser schon eingebaut. Mit Strg+F erreicht man das beispielsweise.

Richtige Antwort. Aber ich denke, du hättest noch dazuschreiben sollen, dass eine Webseite was anderes ist als eine Website und nachfragen, ob vielleicht letzteres gemeint ist.

Wenn du meinst, der OP hätte sich unklar ausgedrückt, fände ich es nett, wenn du ihn direkt fragst und nicht indirekt unterstellst, meine Antwort hätte umfangreicher ausfallen müssen.

Abgesehen davon ergibt die Anfrage für mich keinen Sinn, wenn man statt Seite Site annimmt.

dedlfix.

[Raketenwilli]

Hallo, wie kann man eine Suchfunktion auf einer Internet-Seite realisieren? Gesucht werden soll nur auf der aktuellen Seite

Zuerst muss man in Klarem sein, wie die Seite (gemeint: website) gespeichert ist, aber auch wer (mit welchem Wissen) sucht womöglich wie wonach. Dann kann man eine Suchfunktion planen.

Realisieren kann man das z.B. so. Das ist aber nur eine von wirklich unzähligen Möglichkeiten.

[Raketenwilli]

Wenn Du mit „Gesucht werden soll nur auf der aktuellen Seite“ tatsächlich die aktuell angezeigte Webseite (z.B. eine Artikelseite) meinst, dann gibt es eine einfache und eine komplizierte Antwort:

Einfache Antwort:

Die Benutzer kennen ihren Browser und also dessen Suchfunktion.

Komplizierte Antwort:

Nimm das DOM, lösche eine womöglich existierende Ergebnisliste aus dem DOM, wandere durch das Objekt und suche nach der ID eines Unterobjektes. Wenn nach Deinem Gutdünken die Suchbedingung erfüllt ist, dann schreibe den Link zur Fundstelle nach Deinem Gutdünken in eine Liste, welche Du wiederum ins DOM hängst und anzeigst…

[Gunnar Bittersmann]

@@Gerhard

Gesucht werden soll nur auf der aktuellen Seite.

Ich nehme an, du meinst auf der aktuellen Website. Wie dedlfix schon anmerkte, verfügen Browser ja bereits über eine Suche auf der aktuellen Seite.

Weiterhin nehme ich an, dass du eine Suche nicht selber programmieren willst, sondern eine Suchmaschine auf deiner Website suchen lassen willst.

Und schon haben wir ein kleines Problem: Verschiedene Nutzer verwenden verschiedene Suchmaschinen. Ich lasse mich ungern ausspionieren und mache einen großen Bogen um Google. Aber an die im Browser der jeweiligen Nutzerin eingestellte Suchmaschine kommt man wohl nicht ran. (Oder kann man die mit JavaScript irgendwie auslesen?) Also nehmen wir DuckDuckGo für alle – und tun allen damit einen Gefallen.

Das Eingabenfeld für die Suchbegriffe sollte den Namen q haben, damit beim Absenden der von DuckDuckGo erwartete Parameter q draus wird. Für die Angabe der Website(s) brauchen wir noch ein Eingabefeld namens sites – type="hidden", da das ja nicht zu sehen sein soll, sondern nur der Übermittlung des Parameters dient, der dort als value drinsteht.

Sieht dann so aus: herbstliches Beispiel.

<form role="search" action="https://duckduckgo.com/">
	<input name="q" type="search" aria-label="Suche auf gunnarbittersmann.de"/>
	<input name="sites" type="hidden" value="gunnarbittersmann.de"/>
	<button>Suchen</button>
</form>

Bei dir steht dann natürlich nicht gunnarbittersmann.de – weder als value noch im aria-label (welches blinde Screenreader-Nutzer erkennen lässt, wozu dieses Formular dient).

(Das JavaScript im Codepen entfällt; das dient nur der Vorbelegung mit einem Beispielwert und dem Setzen von target="_blank" wegen Codepen, was man aber normalerweise nicht tun sollte!)

😷 LLAP

[Gerhard]

Hallo, ich meinte den über mehrere Bildschirmseiten gehende Bereich einer mit einer bestimmten url aufgerufenen Seite. Da nicht alle Anwender die MS-Suchfunktion kennen, möchte ich auf der Seite ein Suchfeld angeben, in dem man den Suchbegriff eingeben kann.

[Gunnar Bittersmann]

@@Gerhard

Hallo, ich meinte den über mehrere Bildschirmseiten gehende Bereich einer mit einer bestimmten url aufgerufenen Seite. Da nicht alle Anwender die MS-Suchfunktion kennen, möchte ich auf der Seite ein Suchfeld angeben, in dem man den Suchbegriff eingeben kann.

Das genannte Tastaturkürzel für Find ist keine „MS-Suchfunktion“. Wenngleich es auf Mac nicht Strg+F ist, sonden command+F (⌘F), aber das wissen die In-den-Apfel-Beißer.

Die Suchfunktion wird vom Browser zur Verfügung gestellt – und zwar von allen gleichermaßen: Firefox, Safari, Edge, Chrome, … (Opera hab ich keinen installiert, würde dort aber nichts anderes erwarten.) Und nicht nur von Browsern – auch andere Anwendungen wie Textverarbeitungen bieten die Suche im aktuellen Dokument unter demselben Tastaturkürzel an. Das sollte Computernutzern hinreichend bekannt sein.

Wenn du diesbezüglich bei deiner Nutzerschaft Bedenken hast: Hast du einen Nutzertest mit einer repräsentativen Stichprobe gemacht? Wenn sich bei einem solchen herausstellen sollte, dass in deiner Zielgruppe wirklich viele DAUs sein sollten, dann finde einen Weg, sie auf die Browserfunktion aufmerksam zu machen. (Bspw. „Suche auf der Seite“ öffnet ein Hinweisfenster, wo auf Strg+F bzw. ⌘F hingewiesen wird.)

Es ist jedenfalls keine gute Idee, im Browser schon vorhandene Funktionen auf einer Webseite nachzubauen. Das schließt auch sowas wie Schriftvergrößerer und Umschalter zwischen Hell- und Dunkelmodus ein.

---

Aber wenn deine Homepage so elendig lang ist, dass du denkst, das Nutzer darauf eine Suchfunktion benötigen, dann stimmt womöglich was mit deiner Inhaltsstruktur nicht. Wie J.J. Garrett sagt: “I remain amazed and perplexed at how often people think they can solve an information architecture problem with interaction design.” (Tweet)

Vielleicht solltest du darüber nachdenken, deine Inhalte in kleinere Häppchen zu unterteilen und eine sinnvolle Navigation dorthin anzubieten?

Und sollte es sich bei deinen Inhalten um viele gleichartige Daten (Tabelle) handeln, dann solltest du vermutlich eine Filterfunktion anbieten.

😷 LLAP

[Gerhard]

@@Gerhard

Hallo,

Aber wenn deine Homepage so elendig lang ist, dass du denkst, das Nutzer darauf eine Suchfunktion benötigen, dann stimmt womöglich was mit deiner Inhaltsstruktur nicht.

Denke z.B. an eine z.B. alphabetische Liste Liste aller Pflanzen (mit ihren Eigenschaften) der Erde. Gruppen nach Alphabet sind noch zu groß, um z.B. übersichtlich auf eine Seite zu gehen. Für Gruppen nach Kategorien/Arten gilt dasselbe. Und die Zielgruppe sind Nutzer, die selten im Internet zugange sind.

[Der Martin]

Hi,

Aber wenn deine Homepage so elendig lang ist, dass du denkst, das Nutzer darauf eine Suchfunktion benötigen, dann stimmt womöglich was mit deiner Inhaltsstruktur nicht.

Denke z.B. an eine z.B. alphabetische Liste Liste aller Pflanzen (mit ihren Eigenschaften) der Erde. Gruppen nach Alphabet sind noch zu groß, um z.B. übersichtlich auf eine Seite zu gehen. Für Gruppen nach Kategorien/Arten gilt dasselbe.

soweit kann ich folgen. Aber zumindest für mich ist eine Suche völlig überflüssig, wenn ich weiß, dass die Liste alphabetisch sortiert ist. Dann kann ich zielstrebig an die Stelle hinscrollen, wo mein gesuchter Name steht.

Und die Zielgruppe sind Nutzer, die selten im Internet zugange sind.

Naja, trotzdem. Die Suche mit Strg-F ist mittlerweile ein Quasi-Standard und wird von sehr vielen Programmen angeboten. Sogar plattformübergreifend. Ich würde mich daher dedlfix anschließen und eine zusätzlich realisierte Suchfunktion für unnötig halten.
Auch Gunnars Tipp, einen entsprechenden Hinweis auf der Seite zu plazieren (falls es wirklich mal jemand nicht weiß), finde ich durchaus sinnvoll und ausreichend.

Live long and pros healthy,
 Martin

[Rolf B]

Hallo Gerhard,

Denke z.B. an eine z.B. alphabetische Liste Liste aller Pflanzen (mit ihren Eigenschaften) der Erde.

Wieviele sind das? 100'000 Arten? Eine Million? Das gehört in eine DB mit serverseitiger Suche.

Rolf

[Gunnar Bittersmann]

@@Gerhard

Aber wenn deine Homepage so elendig lang ist, dass du denkst, das Nutzer darauf eine Suchfunktion benötigen, dann stimmt womöglich was mit deiner Inhaltsstruktur nicht.

Denke z.B. an eine z.B. alphabetische Liste Liste aller Pflanzen (mit ihren Eigenschaften) der Erde.

Dann trifft also das zu, was ich danach auch noch schrieb:

Und sollte es sich bei deinen Inhalten um viele gleichartige Daten (Tabelle) handeln, dann solltest du vermutlich eine Filterfunktion anbieten.

Wer liest sich eine ellenlange Liste aller Pflanzen auf einer Webseite durch? Niemand. Also gehört die ellenlange Liste aller Pflanzen nicht auf eine Webseite. (Und damit erübrigt sich auch die Suchfunktion.)

Eine Filterfunktion – wie du sie wohl brauchst – lässt sich auch recht einfach umsetzen: ein Eingabefeld mit datalist.

Bei jedem eingegebenen Zeichen wird die Liste neu gefiltert und enthält nur noch die Einträge, die der eingebenen Zeichenkette entsprechen. Die Nutzerin kann weiter tippen oder aus der gefilterten Liste auswählen.

Nach Bestätigung der Eingabe lässt du die Information zur jeweiligen Pflanze anzeigen – bzw. eine Meldung, dass du zur getätigten Eingabe keinen Eintrag hast. Dann wäre eine Auswahl ähnlicher Begriffe („Meinten Sie vielleicht …?“) gut; vielleicht hatte der Nutzer sich ja vertippt. Das kostet dann aber schon etwas Programmieraufwand.

😷 LLAP

[Rolf B]

Hallo Gunnar,

ein Eingabefeld mit datalist

Nicht für eine Seite mit Infos zu allen Pflanzen dieses Planeten. Das ergibt mindestens 20-30 MB HTML, unzumutbar.

Rolf

[Gunnar Bittersmann]

@@Rolf B

ein Eingabefeld mit datalist

Nicht für eine Seite mit Infos zu allen Pflanzen dieses Planeten. Das ergibt mindestens 20-30 MB HTML, unzumutbar.

Dann ist es auch so schon unzumutbar. Ob die einzelnen Pflanzen nun as sind oder options, spielt dann auch keine Rolle.

😷 LLAP

[Gerhard]

Wer liest sich eine ellenlange Liste aller Pflanzen auf einer Webseite durch? Niemand. Also gehört die ellenlange Liste aller Pflanzen nicht auf eine Webseite. (Und damit erübrigt sich auch die Suchfunktion.)

Niemand will die ellenlange Liste durchlesen. Jemand möchte, um beim Beispiel Pflanzen zu bleiben, den Eintrag "Tulpe" direkt finden, ohne blättern zu müssen. Jetzt kommt sicher das Argument, man könnte über Google o.a. suchen. Allerdings handelt es sich in meiner "ellenlangen" Liste nicht um Begriffe, die sich immer über Google finden lassen. So long Gerhard

[Raketenwilli]

Jemand möchte, um beim Beispiel Pflanzen zu bleiben, den Eintrag "Tulpe" direkt finden, ohne blättern zu müssen.

Dann will er aber auch die Astern und Gladiolen überhaupt laden. Du hast also - wie von Gunnar beschrieben - einen Designfehler.

Also Datenbank -> Abfrage auf Server, Suchformular…

[Raketenwilli]

Dann will er aber auch die Astern und Gladiolen überhaupt laden.

Dann will er aber auch die Astern und Gladiolen überhaupt nicht erst laden.

[Gerhard]

Datenbanken und Serverseitige Proramme möchte er auch nicht haben, sondrn eine einfach HTML-Lösung, allenfalls noch Javascript.

[Raketenwilli]

Na, dann willst Du womöglich das hier an seine Wünsche anpassen:

https://blog.codecentric.de/en/2013/11/javascript-search-text-html-page/

[Rolf B]

Hallo Gerhard,

ja, aber das Problem ist, dass eine solche Seite ewig lang lädt. Auf meine Frage, wieviele Zeilen deine Tabelle hat, hast Du noch nicht geantwortet - aber wenn deine Liste so umfangreich ist wie Du sagst, dann überforderst Du den Browser beim Versuch, das darzustellen.

Ich habe firmenintern schon versucht, HTML Seiten zu machen mit 1000 Zeilen in einer Tabelle. Davon bin ich schnell wieder abgekommen, denn das hat viel Darstellungszeit gekostet. Trotz fixiertem Table-Layout. Auf einem fetten Desktop mit fixer Netzanbindung mag es gehen, aber ein Tablet oder Smartphone geht dabei in die Knie. Alle Pflanzenarten ist eine Masse mehr als 1000 Zeilen. Es sei denn, du hast eine recht minimalistische Auffassung von "alle".

Lösungshinweise hast Du bekommen - entweder traust Du dem Benutzer zu, seinen Browser bedienen zu können, oder Du musst einen Filter bauen. Allerdings funktioniert das nicht rein mit HTML. Ein auf der Seite integrierter Filter braucht JavaScript. Ein serverseitiger Filter braucht eine serverseitige Sprache.

Einer reinen HTML Lösung kommt die datalist noch am nächsten, aber nicht, wenn Du außer dem Namen noch Informationsspalten hast. Da musst Du dann wieder mit Javascript ran und den Rest anzeigen.

Rolf

[Der Martin]

Hallo,

Ein auf der Seite integrierter Filter braucht JavaScript.

und trotzdem muss die gesamte Datenmenge erstmal geladen werden.
Man gewinnt also auf der technischen Seite nichts.

Live long and pros healthy,
 Martin

[Gerhard]

Hallo, die Seite hat im Augenblick 2500 Zeilen über ca. 85 Bildschirmseiten und ist in 0,nix geladen. Die Performance ist also irrelevant. Leider darf ich die Seite hier nicht zeigen. Also in anderen Worten: Wie kann ich das "Strg-x" über ein Feld auf meiner Seite realisieren?

[Rolf B]

Hallo Gerhard,

sorry, diesen Beitrag hatte ich übersehen.

Wenn Du nur in einer Spalte suchen möchtest, brauchst Du JavaScript am Client. Strg+F sucht über alle Spalten, und ich glaube, mit einer <datalist> wirst Du auch nicht glücklich. Zumindest nicht ohne eine Prise JavaScript.

Wieviel JavaScript kannst Du?

Rolf

[Gunnar Bittersmann]

@@Gerhard

die Seite hat im Augenblick 2500 Zeilen über ca. 85 Bildschirmseiten und ist in 0,nix geladen.

Bei dir vielleicht. Bei anderen nicht.

Also in anderen Worten: Wie kann ich das "Strg-x" über ein Feld auf meiner Seite realisieren?

In Orlandos Worten: nicht.

😷 LLAP

[Rolf B]

Hallo Martin,

Man gewinnt also auf der technischen Seite nichts.

kömmt drauf an. Ich hab mir gerade eine HTML Seite mit einer Table aus 14000 Rows zu je 10 Spalten gemacht. Wenn ich die lade, gönnt sich Chrome ca 10 Sekunden, bis das Warterädchen nicht mehr dreht. Man sieht zwar sofort was, aber der Ladevorgang ist längst nicht fertig.

Wenn ich die meisten Zeilen ausblende und nur mittels td:nth-child(...) ein ca 20 sichtbar mache, ist er unter einer Sekunde fertig. Es kostet immer noch Zeit, das alles zu durchlaufen, aber jetzt ist es handhabbar.

Der Browser gönnt sich eine Menge Zeit beim Parsen und Darstellen einer Tabelle mit drölftausend Zeilen. Wenn man initial alle Rows ausblendet und mittels Filter nur die einblendet (bspw. über eine Klasse "matches-filter" am tr-Element), die auf die Suchbedingung zutreffen, spart man die Rendering-Zeit. Die Seite ist dann in 0,6s fertig, und eine Schleife, die 50 zufällige Rows einblendet, braucht 20ms.

Man könnte die Daten auch als Array of Array (nicht JSON, das hat zu viel Overhead) rüberschieben statt mit HTML Dekoration. Das spart eine Menge Volumen. Aber dann muss man die Tabellenzellen basierend auf dem Suchergebnis generieren - auch nicht ganz trivial.

Aber bevor wir hier über Optionen weiter debattieren, würde ich von Gerhard gern wissen: Mit welchem Know-How bezüglich der Magic Five des Web (HTML, CSS, JavaScript, Server-Programmiersprache und SQL) bist Du hier am Start?

Rolf

[Der Martin]

Hallo,

Man gewinnt also auf der technischen Seite nichts.

kömmt drauf an. Ich hab mir gerade eine HTML Seite mit einer Table aus 14000 Rows zu je 10 Spalten gemacht. Wenn ich die lade, gönnt sich Chrome ca 10 Sekunden, bis das Warterädchen nicht mehr dreht. Man sieht zwar sofort was, aber der Ladevorgang ist längst nicht fertig.

Wenn ich die meisten Zeilen ausblende und nur mittels td:nth-child(...) ein ca 20 sichtbar mache, ist er unter einer Sekunde fertig. Es kostet immer noch Zeit, das alles zu durchlaufen, aber jetzt ist es handhabbar.

okay, den Zeitbedarf kann man also ausreichend klein halten. Ich dachte aber auch an die unnütz übertragene Datenmenge. Gerhard spricht von ca. 2500 Zeilen. Lass mal außer einem Namen auch ein bisschen Meta-Information in den Zeilen stecken, dazu das Markup an sich - bei "nur" 100 Byte pro Zeile kämen wir also schon auf rund 250kB. Und nur ein paar hundert Byte davon interessieren den Besucher tatsächlich. Verdammt schlechter Wirkungsgrad. 😉

Live long and pros healthy,
 Martin

[Raketenwilli]

kömmt drauf an. Ich hab mir gerade eine HTML Seite mit einer Table aus 14000 Rows zu je 10 Spalten gemacht. Wenn ich die lade, gönnt sich Chrome ca 10 Sekunden, bis das Warterädchen nicht mehr dreht.

Vor gefühlt oder gar genau 25 Jahren hatten wir hier mal die konsente Erkenntnis, dass fixe Spaltenbreiten (in em, rm, px) und also fixe Tabellenbreiten die Zeit bis zur Darstellung verkürzen…

Damals ging es aber um eine Wartezeit von rund 10 Minuten - nachdem der Treiber fürs 33-kBit/s-Modem mangels Datenverkehr aufgelegt hatte...

[Rolf B]

Hallo Raketenwilli,

fixe Spaltenbreiten allein sind's nicht, man sollte auch table-layout:fixed ins CSS schreiben. Hab ich natürlich gemacht. Aber die width-Angaben für die tds vergessen 🙄. Das fiel mir dann gestern abend irgendwann auf.

Es sind 10s bei Auto-Layout und 8s bei festen Breiten. D.h. festes Layout ist hier nicht der entscheidende Faktor. Sondern die schiere Masse an Rows.

An irgendeiner Stelle hatte ich eine Kombi gefunden, die bei 14000 Rows den Browser auch nach einer Minute nicht fertig werden ließ. Trotz festem Layout. Aber die krieg ich nicht wieder hin. Man kann mit CSS jede Menge Dinge tun, die schädlich für die Wartezeit sind…

Ein böser Faktor ist z.B. ein CSS Counter in einem ::before-Element, um eine Zeilennummerierung zu erzeugen. Der kostet mich über eine Sekunde.

Rolf

[Raketenwilli]

Vor gefühlt oder gar genau 25 Jahren hatten wir hier mal die konsente Erkenntnis, dass fixe Spaltenbreiten (in em, rm, px) und also fixe Tabellenbreiten die Zeit bis zur Darstellung verkürzen…

fixe Spaltenbreiten allein sind's nicht, man sollte auch table-layout:fixed ins CSS schreiben.

[+1]

Gute Ergänzung. Ist „CSS 2, Revision 1“ also „anno 2011“. Wegen meiner Fokussierung auf den historischen Aspekt der „konsenten Erkenntnis“ aus „anno lange davor“ hab ich daran einfach nicht gedacht.

[Auge]

Hallo

Wer liest sich eine ellenlange Liste aller Pflanzen auf einer Webseite durch? Niemand. Also gehört die ellenlange Liste aller Pflanzen nicht auf eine Webseite. (Und damit erübrigt sich auch die Suchfunktion.)

Niemand will die ellenlange Liste durchlesen. Jemand möchte, um beim Beispiel Pflanzen zu bleiben, den Eintrag "Tulpe" direkt finden, ohne blättern zu müssen.

Die unter Anderem von @Rolf B vorgebrachten, begründeten(!) Argumente bezüglich der Performance „ellenlanger“ Tabellen und auch den Verweis auf die immer gleiche browsereigene Suchfunktion mal beiseite gelassen, wäre es nicht schon allein der Übersicht halber ein erster Schritt, die Liste/Tabelle der Pflanzen alphabetisch zu trennen und auf einzelne Seiten zu verteilen? Das Problem der Performance würde sich, je nach Anzahl der Einträge pro Anfgangsbuchstabe, mindestens entschärfen.

Bliebe die initial von dir erfragte Lösung für die Suche. Für eine Suche auf der konkret geladenen Seite ist die programm-, also browsereigene Suche ([STRG]-[F]) die einfachste und zu präferierende Lösung. Alles andere hieße, das Rad neu (und mutmaßlich schlechter als das Original) zu erfinden. Eine Website-weite Suche, die, wie eine „richtige“ Suchmaschine, eine Liste von Fundstellen ausspuckt, lässt sich sinnvoll nur mit einer serverseitigen Lösung implementieren.

Tschö, Auge

[JürgenB]

Hallo,

... Eine Website-weite Suche, die, wie eine „richtige“ Suchmaschine, eine Liste von Fundstellen ausspuckt, lässt sich sinnvoll nur mit einer serverseitigen Lösung implementieren.

man kann hier auch mit einem Formular den Suchbegriff an die Suchmaschine des geringsten Misstrauens senden, und mit site:... die Suche auf die eigene Domain beschränken.

Gruß
Jürgen

[Gunnar Bittersmann]

@@JürgenB

... Eine Website-weite Suche, die, wie eine „richtige“ Suchmaschine, eine Liste von Fundstellen ausspuckt, lässt sich sinnvoll nur mit einer serverseitigen Lösung implementieren.

man kann hier auch mit einem Formular den Suchbegriff an die Suchmaschine des geringsten Misstrauens senden, und mit site:... die Suche auf die eigene Domain beschränken.

Was du nicht sagst. So in etwa? 😜

😷 LLAP

[JürgenB]

Hallo Gunnar,

... Eine Website-weite Suche, die, wie eine „richtige“ Suchmaschine, eine Liste von Fundstellen ausspuckt, lässt sich sinnvoll nur mit einer serverseitigen Lösung implementieren.

man kann hier auch mit einem Formular den Suchbegriff an die Suchmaschine des geringsten Misstrauens senden, und mit site:... die Suche auf die eigene Domain beschränken.

Was du nicht sagst. So in etwa? 😜

um nicht zu sagen: Genau so.

Der Thread wird so langsam unübersichtlich.

Gruß
Jürgen

[Robert B.]

Moin Jürgen,

Der Thread wird so langsam unübersichtlich.

wird Zeit für eine Suchfunktion hier 😜

Viele Grüße
Robert

[Auge]

Hallo

Der Thread wird so langsam unübersichtlich.

wird Zeit für eine Suchfunktion hier 😜

Ungefähr so? 😆

Tschö, Auge

[Robert B.]

Moin Auge,

Der Thread wird so langsam unübersichtlich.

wird Zeit für eine Suchfunktion hier 😜

Ungefähr so? 😆

diese Funktionalität hat mein Leben verändert 👍

Viele Grüße
Robert

[Raketenwilli]

Die Treffer der öffentlichen Suchmaschine auf die site: zu begrenzen hat auch Nachteile (z.B. bei Änderungen, die dann nicht zeitnah wirksam werden).

@@Gerhard

Tatsächlich ist das aus dem Jahr 2013 stammende und in reinem JS notierte Skript - welches Du aber anpassen musst - wohl der Königsweg (aber nur soweit serverseitige Techniken nicht zur Verfügung stehen)

siehe:

https://forum.selfhtml.org/self/2021/oct/16/suchfunktion-auf-homepage/1792631#m1792631

• Vergib den durchsuchbaren Tabellenzellen (oder Überschriften) einen einheitlichen Klassenname.
• Ergänze das Eingabefeld im Suchformular am besten um eine datalist

Letztere kann im HTML fix notiert werden oder nach dem Laden der Seite mit Javascript (das verlinkte Skript zeigt eigentlich schon wie das geht) erzeugt werden.

var divs = document.getElementsByClassName("col-md-2");
...

(es müssen ja keine DIVs sein...)

ABER:

Auf älteren Geräten, insbesondere älteren Mobilgeräten kann es bei 2500 Einträgen (insbesondere in einer Tabelle) durchaus recht „zäh“ werden (Ladezeit der Seite, Initialisierung des Formulars, eigentliche Suche, Scrollen zum Treffer). Das solltest Du testen - und zwar nicht mit dem neuesten iPhone oder Oberklasse-Samsung.

[Raketenwilli]

Und vergiss nicht, dem Benutzer etwas zu geben, womit er schnell zur Suche zurückkehren kann. Rückkehrbutton, eventuell die Suche oben fixieren, stets sichtbares Hamburger-Menü oder sowas.

[Gunnar Bittersmann]

@@Raketenwilli

Das solltest Du testen - und zwar nicht mit dem neuesten iPhone oder Oberklasse-Samsung.

Und auch nicht im heimischen WLAN, sondern draußen. Und zwar nicht im Stadtzentrum, sondern auf dem platten Land. Ich sag nur BrandEDGEburg.

😷 LLAP

[Rolf B]

Hallo Raketenwilli,

ich betreue im Betrieb eine Anwendung, die eine längere Dokumentenliste abbildet. Da habe ich einen live-Filter drin, mit einem Suchfeld über der Liste und wenn man da was reintippt, wird die Anzeige auf die Dokumente gefiltert, die auf die Eingabe passen. Die „schnelle Rückkehr zur Suche“ besteht dann einfach im Sprung zum Seitenanfang. Im Zweifelsfall verfügbar über den Scrollbar, bzw. (vor allem für mauslose Geräte) über einen href="#" Link am Listenende.

Sobald das DOM erstmal verfügbar ist, ist das auch bei 2500 Zeilen unproblematisch. Die Zeit benötigt man beim Aufbau des DOM. Wenn es erstmal da ist, geht's.

Ich mag nur keinen abschreibfähigen Code dafür posten. Dazu müsste Gerhard erstmal auf meine Frage antworten, wie sein JS-Knowhow ist. Ich befürchte aber, dass er diesen Thread hier aufgegeben hat und anderswo nach Kopierquellen sucht.

Rolf

[Der Martin]

Hallo Rolf,

Die „schnelle Rückkehr zur Suche“ besteht dann einfach im Sprung zum Seitenanfang. Im Zweifelsfall verfügbar über den Scrollbar, bzw. (vor allem für mauslose Geräte) über einen href="#" Link am Listenende.

oder für Desktop-Nutzer bequem mit der Home-Taste.

Ich mag nur keinen abschreibfähigen Code dafür posten. Dazu müsste Gerhard erstmal auf meine Frage antworten, wie sein JS-Knowhow ist.

Wahrscheinlich eher "mäßig" (schade, das Zitat hat's wohl nicht in die Sammlung geschafft).

Ich befürchte aber, dass er diesen Thread hier aufgegeben hat und anderswo nach Kopierquellen sucht.

Gut möglich.

Live long and pros healthy,
 Martin

[Raketenwilli]

Ich mag nur keinen abschreibfähigen Code dafür posten. Dazu müsste Gerhard erstmal auf meine Frage antworten, wie sein JS-Knowhow ist.

Hab ich mit der gleichen Absicht nicht getan.

Einer von wirklich sehr vielen Gründen ist, dass ich befürchte, dass irgendwann die Frage kommt, wie er denn nunmehr das Laden der zusätzlich erforderlichen 2500 Blümchenbilder zu je 4000x3000 Pixeln beschleunigen kann…

[Matthias Scharwies]

Servus!

Hallo, wie kann man eine Suchfunktion auf einer Internet-Seite realisieren? Gesucht werden soll nur auf der aktuellen Seite.

Das wäre ein gutes Thema für ein Tutorial.

1. Frage: Google-Suche oder etwas eigenes?

2. Clientseitiges Modell mit JS

   • grad geshen, noch nicht durchgelesen: css-tricks: In-Page Filtered Search With Vanilla JavaScript

3. Fazit

   • oder doch ein CMS?

Herzliche Grüße

Matthias Scharwies

[Gunnar Bittersmann]

@@Matthias Scharwies

Gesucht werden soll nur auf der aktuellen Seite.

Das wäre ein gutes Thema für ein Tutorial.

Du willst aber nicht in einem Tutorial ctrl-F/cmd-F erklären?

1. Frage: Google-Suche oder etwas eigenes?

Was denn nun: Webseite oder Website?

Und nein, weder Google noch was eigenes.

Ist mein diesbezügliches Posting nicht Tutorial genug?

2. Clientseitiges Modell mit JS
   • grad geshen, noch nicht durchgelesen: css-tricks: In-Page Filtered Search With Vanilla JavaScript

Das ist keine Suche, sondern eine Filterung. Auf den Unterschied hatte ich in diesem Thread schon hingewiesen.

😷 LLAP

[Matthias Scharwies]

Servus!

@@Matthias Scharwies

Gesucht werden soll nur auf der aktuellen Seite.

Das wäre ein gutes Thema für ein Tutorial.

Du willst aber nicht in einem Tutorial ctrl-F/cmd-F erklären?

Doch, weil es eben vielen Newbies (unserem Zielpublikum) unbekannt ist

1. Frage: Google-Suche oder etwas eigenes?

Was denn nun: Webseite oder Website?

Und nein, weder Google noch was eigenes.

Ist mein diesbezügliches Posting nicht Tutorial genug?

Doch aber das geht bei mittlerweile 47 Posts unter!

Früher gab's mal die FAQ, bei der dann auf so einen Artikel/Post verlinkt wurde. Heute eben als Zusammenfassung im Blog oder im Wiki.

2. Clientseitiges Modell mit JS
   • grad geshen, noch nicht durchgelesen: css-tricks: In-Page Filtered Search With Vanilla JavaScript

Das ist keine Suche, sondern eine Filterung. Auf den Unterschied hatte ich in diesem Thread schon hingewiesen.

Das wäre eben auch etwas, in dem man Fachbegriffe passend erklärt!

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Matthias,

d.h. man müsste ein Tutorial für eine gefilterte Liste o.Ä. machen und einleitend erklären, dass die Fallback-Lösung die Suchfunktion ist, die jeder Browser ohnehin hat.

Rolf