nicht angemeldet
Hallo, Danny.
daß Frames Nachteile haben, ist nicht von der Hand zu weisen. Langfristig gesehen werden modernen Techniken wie CSS-Boxen und Server-Scripte den Einsatz von Frames überflüssig machen, bzw. ersetzen.
position:fixed ist m.M.n kein Allheilmittel gegen Frames. Serverseitig dynamische Seiten gibt es schon seit... ehm... der Cern HTTPd konnte doch schon CGI, oder? Davor gab es scheinbar htbin, d.h. die Möglichkeit besteht mindestens seit dem 4. November 1993. Auch das hat also wenig mit Frames zu tun.
Trotzdem habe ich den Eindruck, daß die "Anti-Frame"-Fraktion gerne übertreibt.
Bitte zeige mir ein Frameset bzw. eine Seitenstruktur, welches die meisten bekannten Probleme von Frames umgeht,
werden Frames oft vermieden. Je größer und professioneller Websites gestaltet sind, umso seltener trifft man idR Frames an.
idR ist trefflich, denn t-online.de und auch andere Global Player setzten immer noch Frames ein.
Die haben echt gar nix begriffen, im noframes-Element steht bei denen, dass man einen anderen Browser benutzen soll.
Bezüglich t-online.de hat Stefan schon einiges gesagt, genau das wollte ich auch anmerken. Es ist nahezu unmöglich, auf dieser Seite etwas zu finden, zudem produziert deren CMS die abenteuerlichsten URLs. Fehlschlag auf ganzer Linie.
Das Argument mit der Pflege-Vereinfachung ist also kein Widerspruch.
Hm...? Große Seiten, welche heute noch Frames einsetzen, geht es nicht darum. T-Online erstellt alle Seiten mit einem CMS, es ist gleich, ob die Navigation auf jeder Seite oder nur im Navigationsframe enthalten ist, das eine ist nicht mehr aufwändig als das andere.
Es ist nur so, daß die meisten großen Websites mittlerweise PHP oder ASP einsetzen. Damit zieht sich das Argument Pro Frames nicht mehr. Aber bei umfangreichen Inhalten ist es doch übersichtlicher, einen Navigationsframe immer im Blick zu haben.
Das ist eine subjektive Beobachtung, keine empirische belegte. In Diskussionen über Frames melden sich immer beide Fraktionen zu Wort, jeder hat diesbezüglich andere Erfahrungen. Übersichtlichkeit über umfangreiche Inhalte können framelose Seiten bieten (oder genauso daran scheitern wie Seiten mit Frames).
Bei reinen Tabellen-Layouts habe ich dagegen oft das "Lost in Hyperspace" Gefühl. Vielleicht ist das aber auch bloß reine Gewöhnungs- oder Geschmackssache... ;)
Ich sehe keinen direkten Zusammenhang zwischen einem Design, welches die Navigationsmechanismen nicht ständig im Blickfeld positioniert (Frames oder position:fixed) und "Lost in Hyperspace". Als Lost in Hyperspace würde ich das Fehlen von Navigationsmechanismen bezeichnen, welche der Komplexität der Seitenstruktur gerecht werden und gleichzeitig alle Informationen schnell zugänglich machen.
Für viele Hobby-Webmaster und kleine Websites lohnt sich aber keine Serversprache oder es fehlen entsprechende Kenntnisse. Also warum dann nicht einfach Frames verwenden?
Es gibt (kostenlose) Editoren, welche es ermöglichen, Templates einzubinden. Phase 5 kann dies meines Wissens. Mit anderen Programmen und Skripten kann man vor dem Upload alles mögliche automatisieren (z.B. die Navigation zentralisieren), dazu bedarf es nicht viel Programmierkenntnis, da gibt es auch sicher fertiges Programme und Präprozessoren. Selbst Netzkommunen, welche es ermöglichen, eine Webseite ohne HTML-Kenntnis zu erstellen, benutzen auch frameloses Layout; für die Benutzung und Erstellung der Seiten hat das keine Auswirkung, denn das Einfügen der Navigation auf jede Unterseite erledigt das CMS automatisch.
Ich kann das Argument, dass Frames für den gemeinen laienhaften Seitenbastler eine Erleichterung sind, folglich nur eingeschränkt nachvollziehen. Ich persönlich habe mich vor Jahren mit Mühe in die Frames-Syntax eingearbeitet und war glücklich, als ich völlig auf Tabellenlayout und später CSS umgestiegen bin. Ich mutmaße deshalb, dass Frames für einen HTML-Anfänger als Layouttechnik ungeeignet sind.
Die Probleme mit Suchmaschinen lassen sich zwar nicht umgeghen, aber doch minimieren. Dafür gibt es NoFramet-Bereiche, spezielle Meta-Tags, Robots.txt und Javascripts. Außerdem lassen sich Einzelseiten immer noch mit dem Hauptframeset verlinken...
Eine Unterseite sollte IMHO unabhängig davon, ob sie in einem Frameset steht oder nicht, zumindest eine breadcrumb trail-Navigation enthalten. Im Falle von Frames wäre m.E. ein volle noframes-Navigation naheliegender. Mit Frames können nur eindimensionale Navigationen realisiert werden, ein Link zum Hauptframeset bringt wenig. Ein Beispiel:
Frameset +----------------+ | | | +--- Navigation --- | - Startseite | | | | +--- Startseite | - Rubrik foo | | | | - Rubrik bar | | | | - Rubrik baz | | | Seitenhierarchie +----------------+ | ^ +-- Rubrik foo | | | | | +-- foo1 | | | | | | | +-- foo1_1 ^ | | | | +-- foo2 | | | | | +-- foo3 | | | +-- Rubrik bar ^ | | | | +-- bar1 | | | | | +-- bar2 | | | | | | | +-- bar2_1 ^ | | | | | | +-- bar2_2 | | | | | +-- bar3 | | | +-- Rubrik baz ^ | | | | +-- baz1 | | | | | +-- baz2 | | | ^ | +-- baz3 | | | | | +-- bar3_1 | | | | | +-- bar 3_1_1 ----+ | | | +-- bar 3_1_2 v
Das Frameset kann nicht als Site Map dienen, d.h. es bildet nur die Rubriken der obersten Hierarchie ab. Ein Link zum Frameset bzw. zur Hauptnavigation auf einer Unterseite ist demnach sinnfrei, eine Navigation, welche der Struktur gerecht wird, ist demnach nötig. Damit schlägt man die Brücke zu Unterseiten, welche auf das Frameset nicht mehr angewiesen sind. Zum dritten Mal in diesem Thread fg: Frames bedürfen einer Alternativversion --> Alternativversion muss ohne das Frameset benutzbar sein --> Alternativversion ist eine vollständige, framelose Version der Seite --> Frameset ist überflüssig. :) Insofern sehe ich das sehr pragmatisch.
Never change a running system... ?
Darum geht es ja nicht. Wenn bereits Frames verwendet werden, sollten sie zumindest zugänglich gemacht werden bzw. so gestaltet werden, dass sie wenig Probleme bereiten. Wenn man sich hingegen all diesen Problemen aussetzen will, wenn man das Layout einer neue Seite entwirft oder Relaunch plant, muss man schon ein wenig sadistisch veranlagt sein, da man sich mit unnötiger Arbeit belastet, während der Benutzbarkeitszuwachs für den Benutzer m.E. gering ist.
Mathias