Hi,

Bei mir (gestern) nicht (heute schon). (Ich hab auch einen JS Fehler in der Konsole)

Danke für den Hinweis. Hab gestern einen Tippfehler im Script produziert. :-/ Jetzt geht's wieder.

Aber aus deinen Schilderungen entnehme ich, das Frames durchaus einen erhöhten Aufwand bedeuten,

Das hatten wir doch alles schonmal?! =:-)

vor allem wenn man, a. deine Kenntnisse nicht hat und b. sowas zum ersten Mal macht, was meistens der Fall sein dürfte, wenn Leute hier fragen, weil sie Probleme mit Frames haben und c. dein Skript nicht hat.

Ad a) meine Kenntnisse sind nicht per Geburt vorhanden gewesen. Sie sind erworben. Das wird jedem Web-Newbee heute nicht anders gehen, als mir damals.

Ad b) Auch bei mir gab es das erste Mal. Der einzige Unterschied ist, daß ich Plain-HTML gemacht habe, und danach erst die Frames kamen (hatten wir ja noch gar nicht - damals, nach dem Krieg >;->). Wie HTML funktioniert, wußte ich da also schon. Und es hätte nie zur Diskussion gestanden, Frames einzusetzen, wenn dadurch solche gravierende Nachteile wie behauptet entstanden wären. Und ich finde, die konsequente Nutzung des NOFRAMES-Bereichs nicht mehr oder weniger unlogisch, als die Nutzung anderer Alternativ-Bereiche wie NOSCRIPT etc. *Dafür sind sie da!*
Wenn man sie nicht adäquat nutzt, dann hat man dafür entweder einen (mehr oder weniger) guten Grund, oder man setzt eine Technik unvollständig ein. Das ist nicht das Problem von Frames, sondern ein Problem der Unbedachtheit des Autors - und gilt für jede Technik jenseits von Plain-HTML. Ein konsequenter NOFRAMES-Einsatz mit "Ihr Browser unterstützt leider keine Frames!" sagt doch nichts aus über Frames, sondern einzig und allein etwas über den Autor. =:-o
Ggf. gefördert von schlechten Tools/"WYSIWYG"-Editoren und schlechten HTML-Büchern. Aber das gilt analog auch für z.B. JS.

Und wenn Newbees "Probleme mit Frames" haben, dann muß man ihnen genauso klarmachen, wie z.B. Suchmaschinen arbeiten, wie man es machen muß, wenn Newbees mit reinen JS-Menüs angedackelt kommen. Niemand hat was gegen JS-Menüs, wenn es einen HTML-Fallback gibt.

Wer codet muß auch entsprechend denken (egal worin er codet). Man muß geistig willens und in der Lage sein, nachvollziehen zu können, was dabei passiert. Wer dazu nicht bereit ist, der wird sich mit Frontpage & Co. abfinden müssen (inkl. den Fehlern die daraus resultieren) und ganz bestimmt nicht erfolgreicher Webdesigner werden (es sei denn, er findet einen Job in einer Werbeagentur, die ja solche Leute zu suchen scheinen >;->).

Das herumdoktern an Symptomen (laß jene Technik ganz, nimm diese Technik) ändert daran nichts. Der Proband wird letztlich in jeder Technik scheitern, wenn er nicht ein Mindestmaß an genannter Bereitschaft mitbringt - auch und gerade im nicht gerade unkomplexen Thema CSS.

Ad c) Die 80 Zeilen Script sind wohl kaum das Problem - zumal das ja optional als Automatisierung gedacht und nicht verpflichtend ist. Das Verständnis dahinter (s.o.), ist IMHO das einzige Problem.

Insofern ist es also richtig das wenn diese drei Punkte nicht zutreffen, Frames Nachteile haben, die mit erheblichen Aufwand umschifft werden müssen.

Frames müssen, wie jede Technik, erlernt werden. Wer meint, man setzt ein <frameset> und die gebratenen Tauben fliegen einem in den Mund, der irrt. Und wer meint, HTML ist ja auch nichts anderes als eine Textdatei, der irrt halt auch. Wer sich prinzipiell nicht auf die herrschenden Regeln einstellen will, der wird aber vermutlich schon rasch von irgendeinem Auto überfahren werden, wenn er die Straße überquert. Daß es genug User gibt, die das in EDV-Dingen nicht verstehen/erkennen, ist Fakt, aber kein originäres Problem der EDV. Vielleicht ist die EDV einfach noch nicht stark genug in unserem kulturellem Bewußtsein (Stichwort: Niemand läßt seine Tür offenstehen, aber mit IE und ohne Firewall surfen und alles herunterladen und anklicken was geht, da haben sich sehr viele nichts bei gedacht).

Ich war sicherlich seinerzeit in einer besonderen Position, denn auch wenn HTML mir noch recht neu war: Programmieren tue ich ja noch viel länger. Der Schritt von Plain-HTML zu Frames war insofern nicht mit Aufwand verbunden. Ich habe konnte schon damals "passend denken". Aber das muß ich von jemanden, der sich wirklich dafür interessiert (nein: begeistert), auch heute erwarten. Oder er sollte sich ein anderes Hobby suchen (von Beruf ganz zu schweigen).

Aber selbst ohne EDV-typisch zu denken: wer Frames nutzt ohne NOFRAMES, der nutzt Frames nicht, sondern nur einen Teil. Wer in CSS nur Inline-Styles verwendet, der nutzt CSS nicht, sondern nur einen Teil. Wer für Kunden Webseiten schreibt die nicht auf allen gängigen Clients funktionieren, der ist vielleicht Hobbyist (oder Fundamentalist ;->), aber kein Profi (und das verlangt halt eben leider auch die Bschäftigung mit solchen Abseitigkeiten wie unterschiedlichen Engines, CC oder schlimmstenfalls gar CSS-Hacks).

Ich hoffe mal das eine Internetanwendung nicht auf mein System (ausserhalb des Browsers) zugreift. Wie auch immer, ich sehe eine Interseite eher wie ein Office Dokument, das ja durchaus aktiv sein kann und dort trifft man auch eher selten auf fixierte Elemente (innerhalb des Dokuments).

*Ich* *lebe* online!

Für mich gibt es keinen Unterschied mehr zw. "meinem System (außerhalb des Browsers)" und dem Internet/Intranet. Der Server *ist* "mein System". Nur geht manches halt (noch) nicht online und manches nicht offline. Aber faktisch arbeite ich zu 90% online auf dem Servern/den Servern - auch privat.

Meine wichtigste Software ist mein Browser - bzw. die in ihm laufende Web-Applikation.

Gruß, Cybaer