framesets
-
-
Riesen Blödsinn.
Denn im Endeffekt läuft alles auf JS raus - und dass ist ja der Hauptkritikpunkt an Frames. Man darf eine Seite einfach nicht JS abhängig machen.Weiters gibt es keinen Grund Frames zu verwenden: Denn wofür werden Frames normalerweise verwendet? Für die Navigation.
Doch was lernt jeder Webdesigner in seiner ersten Usability Erfahrung: Ein Menü passt sich der angezeigten Seite an - uU mit Submenüs, mit Farbe, Breadcrumbs, etc.
Das ist mit Frames nicht möglich (bzw. möglich schon, man kann mit JS ja 2 Frames gleichzeitig laden - doch dann bricht man die wichtigste aller accessibility Regeln: mach die Navigation nicht von JS abhängig).
Mythos Eins: "Framesets werden von Suchmaschinen nicht oder nur mangelhaft katalogisiert!"
Jein. Natürlich kann Google alles. Aber wie sieht es mit anderen Suchmaschinenbots aus? Yahoo? MSN?
ich weiss es nicht.Angenommen Google folgt einem externen Link auf meine Seite - natürlich ein deep link. Dann kann es garnicht meine Navigationsleiste sehen, weil die ja nur per JS geöffnet wird - und ich glaube nicht, dass Google JS kann... Und selbst wenn - andere Suchmaschinen können es sicher nicht.
Von dem Nachteil, dass die Navigationsleiste nicht auf jeder Seite ist, sehe ich mal ab.
Mythos Zwei: "Framesets werden vom Besucher nicht akzeptiert!"
OK, stimmt. Den Users ist es egal.
Mythos Drei: "Frames werden von vielen Browsern nicht akzeptiert!"
Vielen? Naja, aber einige:
Dillo, Lynx, uU auch links - kann ich aber gerade nicht testen.Klar, sind nicht besonders wichtige Browser - aber sie haben durchaus ihre daseinsberechtigung.
Und jeder Besucher weniger, ist ein potentieller Kunde (wenn wir von Business Seiten reden - für privatseiten ist es ja egal).
Und ich verweigere mich den potentiellen Kunden nicht wirklich so gerne
Mythos Vier: "Quereinsteiger landen ausweglos auf Unterseiten!"
Was mache ich ohne JS? Dann bin ich aufgeschmissen.
Weiters habe ich hier doppelten Traffic.Mythos Fünf: "Die Wartung von Framesets ist komplizierter!"
Dass die Wartung von Frames leichter ist, stimmt nicht. Denn niemand (bzw. niemand sollte) betreibt copy&paste für das Menü - sondern man verwendet Template Engine - zu Not auch offline.
Die Wartung von Frames ist natürlich nicht besonders schwer - allerdings habe ich da keine so besondere Erfahrung - ausser einer (und dort hatte ich mit Frames nur trouble), das ist aber nicht repräsentativ.
Mythos Sechs: "Framesets wirken unprofessionell!"
Jo, tun sie.
Warum?
Weil sich das Menü nie anpasst und man uU einen strich (Frameborder) zwischen Navigation und Content hat.Mal abgesehen vom wichtigsten Grund:
das w3c hat den nachteil von Frames eingesehen und xhtml kann standardmäßig keine FramesMan kann auch in die Webzeugs FAQ sehen - dort ist ein schöner Beitrag von Loggy und mir.
btw: bei einem Webmagazin hätte ich eine bessere Seite erwartet: ich habe ja keine Ahnung wo ich mich gerade befinde...
dh, für diese Seite wäre ein Frameset OK (wenn da das JS Problem nicht wäre) - da sie nicht von dem Vorteil von angepassten Menüs, Breadcrumbs etc. gebrauch macht.
Ich verweise da immer gerne auf amazon - die seite ist sehr gut.
erst nach längerem Suchen habe ich den zweiten Artikel dieser Reihe gefunden... Der ist allerdings weitgehend in Ordnung.
-
Frames sind aber in manchen Bereichen notwendig.
z.B. CHAT. Hier gibt es ein iframe welche jede Minute refresht. Sollte etwas neues da sein zeigt es dies mit Hilfe von JS im Hauptframe an.
Ich weiß nicht ob dies mit CSS möglich ist. Wenn ja werde ich sofort auf CSS umsteigen.
-
Unix-Tom schrieb:
Frames sind aber in manchen Bereichen notwendig.
Ja, aber nicht auf einer Webseite.
Chat ist klar - oder auch wenn man eine Anwendung hat, die eine Vorschau erstellt - da ist ein Frame auch schön.
Denn hier ziehen die meisten Argumente ja nicht - JS ist sowieso nötig, usw.
Deshalb: keine Regel ohne Ausnahmen
-
Ich versuche mich auch gerade an einem Chat wenn mir da jemand ne lösung ohne Frames bieten kann wäre ich sehr dankbar
MFG eiskalt
-
Die gibt es ohne Frames IMHO nicht da du ja einzelne Steuerelemente ändern musst.
Bei CSS wird ja trotzdem die ganze Seite neu geladen. Da sind die Steuerelemente dann wieder auf dem Ausgangswert.
Wenn der USer z.B. gerade etwas eingibt ist es nicht hilfreich die Seite zzu laden um dann Chatdaten anzuzeigen.