Interne Suchmaschine für eine HTML-Seite

«	∧	»
	∨

Verfasst am 16.02.2008 01:11:08 Uhr
Interne Suchmaschine für eine HTML-Seite

Kurz, es ist soeben offline gelungen, mit Hilfe eines Suchformulars die Anzahl der Fundstellen eines Suchwortes in einer HTML-Musterseite, seine Startposition, Endposition und Länge (jeweils in Bytes) auf der gleichen Webseite tabellarisch auszugeben. Freund Reinhard bekommt die Krise, wenn er liest, dies ginge nur mit Javascript. Heute ist dann eben Krisensitzung!

Ausserdem gibt meine Musterseite inzwischen alle Title-Attribute der A-Tags auf der gleichen Webseite aus. Weiter geht's: mañana oder sprich: man'jaa'na.

Seinem Rat folgend, ist dies ein kurzer Weblogbeitrag. (dp) (0,25h)

Nachtrag_1 am 16.2.2008 um 17.40Uhr:
Nach weiteren "Übungsstunden" ist es jetzt (offline) möglich, die Quellcode-Positionen der gesuchten Worte oder Wortteile mit HTML-Position von A-Tags abzugleichen und als Treffer auf der gleichen Webseite aufzulisten. Eine Idee zur Hervorhebung der möglichen Fundstellen im Webseitenkontext ist bereits geboren, jedoch fehlt zur Umsetzung noch Javascript-Wissen. (dp)(0,15h)

Nachtrag_2 am 16.2.2008 um 21.40Uhr:
Nach weiterem Experimentieren mit javascript ist es nun (online) möglich, die gefundenen bildlichen Textpassagen farblich hervorzuheben. Auch lassen sich diese Hervorhebungen wieder zurücksetzen. Leider verstehe ich noch nicht, wie es (beim Firefox gezeigt) so einfach möglich ist, im normalen Text die Fundstellen farblich hervorzuheben. Andere Pseudo-Links braucht die Musterseite :

Musterseite mit Sütterlinschrift im Bildformat (letzte Revision 20.2.2008; weitere Suetterlin-Links: Beitrag vom 24.9.2007)

Wahrscheinlich muss auf der Musterseite im Body-Tag noch die Linkfarbe angegeben werden, damit der liebe Internet Explorer die Textpassagen ebenso wie der Firefox-Browser hervorhebt. Alles braucht seine Zeit. (dp) (0,75h)

Nachtrag_3 am 17.2.2008 um 17.30Uhr:
Mein letzter Gedanke: vielleicht rahmt der I.E.-Browser im Gegensatz zum Firefox-Browser und im Gegensatz zu jpg-Bildern die gif-Bilder anders (nämmlich garnicht)? Die (jpg-)Bilder auf dieser Seite http://www.c-vitamine.de/mydiss_1col.html werden doch auch vom I.E. als Link gerahmt. Noch verstehe ich es nicht!! (dp) (0,25h)

Nachtrag_4 am 18.2.2008 um 16.20Uhr:
Nach endlich vielen Stunden steht nun fest:

bei nichtinitial-vorliegendem href-Attribut im A-Tag des HTML-Codes gilt:
- Link-Hervorhebung im Firefox-Browser:
  - Zerlegung der Bilderkette in Einzelbilder
  - Link-Rahmung um jedes Einzelbild
- Link-Hervorhebung im I.E.-Browser: nichts passiert
bei initial-vorliegendem href-Attribut im A-Tag des HTML-Codes gilt:
- Link-Hervorhebung im Firefox-Browser:
  - Bilderkette ist bereits in Einzelbilder zerlegt
  - jedes Einzelbild ist bereits gerahmt
- Link-Hervorhebung im I.E.-Browser:
  - Bilderkette ist bereits in Einzelbilder zerlegt
  - jedes Einzelbild ist bereits gerahmt
- Link-Hervorhebung wird im Firefox-Browser gelöscht (= href-Attribut im A-Tag wird entfernt):
  - Link-Rahmung um jedes Einzelbild wird entfernt
  - Einzelbilder werden zu Bilderketten zusammengefasst (= Leerstellen werden entfernt)
- Link-Hervorhebung im I.E.-Browser gelöscht (= href-Attribut im A-Tag wird vermutlich nicht entfernt):
  - Link-Rahmung um jedes Einzelbild wird entfernt
  - Einzelbilder werden nicht zu Bilderketten zusammengefasst (= Leerstellen werden nicht entfernt)

D.h.: dieser Code

document.getElementsByTagName('a')[j].removeAttribute('href')

als auch dieser Code

document.getElementsByTagName('a')[j].href='javascript:NoLink()'

wird jeweils von beiden Browsern unterschiedlich interpretiert.

Vermutlich macht es eine Komfort-Funktion im Firefox möglich document.getElementsByTagName('a')[j].href erst zu erzeugen, falls das href-Attribut nicht existiert, und danach dieses href-Attribut mit einem Wert (hier z.B. "javascript:NoLink()") zu belegen. Beim I.E. ist vermutlich vorausgesetzt, dass das href-Attribut bereits im A-Tag existieren muss, um es belegen zu können.

Nach neuesten Erkenntinissen stimmt folgende Vermutung nicht, dass beim Firefox bei removeAttribut('href') nicht nur die Belegung des href-Attributes aufgehoben, sondern zur Code-Optimierung das unnötige href-Attribut aus dem A-Tag entfernt wird, wohingegen der I.E.-Browser nur die Belegung rückgängig macht, jedoch das href-Attribut als Dummy weiterhin im A-Tag belässt.

Denn wenn man sich mit Alert() den gesamten Code anschaut, dann werden die Attribut-Änderungen auch durchgeführt. Neue These: vermutlich prüft der I.E. vor der Link-Rahmung um die Bilder, ob noch genug Freiraum vorhanden ist. Da dies wohl nur bei Elternknoten (A-Tags) der Fall ist, die beim Seitenaufruf bereits das href-Attribut vorbelegt hatten, werden diese Bilder auch nur in diesem Fall (reversibel) durch Rahmung hervorgehoben. Leider lassen sich beim Löschen der Rahmung (mit Hilfe von removeAttribute) diese Freiräume bei der I.E.-Darstellung (noch) nicht beseitigen. Diese Freiräume müssten vielleicht über z.B. zu Cellspacing, Cellpadding usw. analoge Boxen-Parameter angesprochen werden können.

Ob man dieses Defizit beim I.E. mit einem Javascript-Code oder Stylesheet-Code CSS korrigieren kann? (dp) (1,35h)

Nachtrag_5 am 20.2.2008 um 21.40Uhr:
Trotz der Validierung in HTML und CSS hatten die I.E.-Testläufe nichts neues gebracht.

Jedoch liege ich, wie erste offline-Erfolge zeigen, mit meiner Vermutung vermutlich richtg: wenn man im IMG-Tag noch ein border-Attribut mit einer Vorbelegung ungleich "0" einbaut, kann man den I.E. wohlgefällig stimmen. Er rahmt beim ersten Aufruf die schon gerahmten Bilder mit einem link-Rahmen. Morgen werden wir vielleicht sehen, ob es vorteilhaft ist, für den I.E. eine Extrawurst zu braten und ihm zwecks Hervorhebung der Suchwort-Bilderkette das Border-Attribut mit Javascript einzubauen oder für die Löschfunktion zu entfernen. (dp) (0,25h)

Nachtrag_6 am 25.2.2008 um 08Uhr:
"Endlich fertig!" hatte ich am 24.2.2008 um 13.10Uhr gedacht, weil das Programm ab jetzt offline richtig lief. "Pustekuchen! Vorbeigedacht!" In einer Nachtsitzung wurde die Ursache geklärt, warum eine Variable beim Benutzen des Firefox mit richtigen Werten und bei der Benutzung des I.E. mit falschen Werten belegt war. Freudig hatte ich meine erste Erfahrung beim Firefox ausgedrückt: man braucht nur auf kleinbuchstaben-namige Tags (z.B.: "a", "img") und Attribute prüfen. Wie sich jetzt ergab, muss beim Benutzen des I.E. auf großbuchstaben-namige Tags (z.B.: "A", "IMG" ) geprüft werden.

Der Entwurf der logischen Funktion zur Abfrage nach dem Browser-Hersteller oder anderer Spezifikationen schien einfach, zumal bereits eine javascript-basierte funktionierende HTML-Webseite vorhanden ist.

Doch nach vielen Fehlermeldungen ist es mir in 2,5Stunden nicht gelungen, diese Funktion zum Laufen zu bringen, obwohl bereits logische Funktionen in meiner sütterlin-Seite funktionstüchtig integriert sind. Jetzt brauche ich erst mal eine Mütze voll Schlaf! (dp) (0,25h)

Nachtrag_7 am 25.2.2008 um 15.40Uhr:
Da war ich schon "betriebsblind" und hatte mit meinen Augen die Unterschiede in der Groß-/Kleinschreibung übersehen. Doch damit bin ich gleich beim Thema. Den Unterschieden in der Groß-/Kleinschreibung bezüglich der von Javascript ermittelten Browserdaten von Firefox und I.E. werde ich einen separaten Beitrag (25.2.2008) widmen. Damit wird auch plausibel (wenn auch noch nicht im Detail verstanden), warum die jeweilige linksseitige und rechtsseitige Position möglicher Suchwort-Fundstellen sich bei Anwendung durch Firefox und I.E. unterscheiden. (dp) (0,25h)

Linksammler:

archiviert (tbid1955.371): (dp) 17.05.2009 (+0,1h (+flagcounter +home.icon +w3c_LiCh +4navi)), 16.6.2009 (+0,2h (+Link-korr. +html-korr.))