Warum sollte man keine Frames verwenden?



  • OK, also Frames können auch sinnvoll sein - dann aber in speziellen Situationen. Nur um eine Navbar zu beinhalten -> dazu haben sie zuviele Nachteile:

    Frames haben ein semantisches Problem: jede Seite im Internet hat eine URL -> bei Frames ist das nicht so. Da hat eine URL mehrer Dateien! Hinter index.html versteckt sich also die ganze Seite. Es ist nicht möglich direkt auf eine der Unterseiten zu springen.
    Bei Scriptsprachen kann das Problem auch bestehen (man könnte die Navigation über Sessions realisieren), bei Frames besteht es aber immer.

    Unterschiedliches Aussehen
    Verschiedene Browser stellen Frames unterschiedlich dar, was viel weitreichendere Auswirkungen hat, als die unterschiedliche Darstellung von normalen HTML Elementen.

    Bookmarking
    Frames verhindern Bookmarking!
    Man kann zB auch niemanden den direkten link geben, sondern muss den weg beschreiben -> so sollte es nicht sein, denn wir benutzen ja nicht umsonst Hyper Text Markup Language (HTML), mit dem man ganz gezielt auf Homepage Inhalte verlinken kann und nicht nur auf ganze Seiten.

    History
    Die Browser History wird verkompliziert. Einige Browser steigen ganz aus, andere können gut damit umgehen, aber dennoch ist es für den User komplizierter zurück zu gehen.

    direkter Link
    Wenn das Frameset umgangen wird, und nur der Inhalt-Frame angezeigt wird, dann hat der User keine Navigation.
    Der User kann sich nicht selber aussuchen was er angezeigt bekommen will. zB er macht ein 'open in new window' und schwupsdiwups hat er keine navbar mehr.

    scrolling
    Wenn man nicht gut aufpasst ist die navbar breiter als der frame -> user mus scrollen.
    Wenn man jetzt scrollen verboten hat, schaut der User dumm drein.
    Das hat nicht unbedingt etwas mit der Unfähigkeit des Webdesigners zu tun (außer, dass er Frames einsetzt ;)), sondern hängt komplett vom Medium ab, über das der Webdesigner keine Annahme machen kann.

    aktiver Frame
    Die Browser/Benutzer können sich nicht immer sicher sein, welcher Frame das aktive ist. Auf welchem Frame werden die Tastdrücke jetzt angewendet? Wo wird mit meiner Scrollmaus gescrollt?

    Drucken
    Frames zu drucken ist eine Qual. Einige Browser beherrschen das nicht ordentlich.

    Suchmaschinen
    Framesets können von Suchmaschinen nicht vernünftig ausgelesen werden. Viele Suchmaschinen nutzen nicht nur die Meta Tags. Oft wird dann in den Suchmaschinen auf eine Unterseite verlinkt (was ja auch sinnvoll ist). Bei Frames fehlt hier aber die Navigation.

    Mehr Aufwand
    Frames zu warten ist komplizierter als ein CSS-Layout.
    Man muss ein <noframe> anbieten, oder man verzichtet absichtlich (und unnütz) auf Besucher! Auch wenn jeder PC Browser Frames unterstützt. Der Trend geht immer weiter hin zu Handys und Handhelds, die nicht die gewünschte Fenstergröße und Leistungsfähigkeit haben soetwas darzustellen.

    Copyright
    Bei Frames kann es vorkommen, dass man (aus versehen) eine andere Seite im eigenen Frame öffnet -> kann ne Copyright Verletzung sein.

    blinden Schrift
    Browser für blindenschrift haben extreme probleme im umgang mit frames.
    wie das mit Sprach-Browsern ist, weiss ich nicht, aber ich denke die können das n bisschen besser.

    Wie gesagt, es gibt Ausnahmen, aber der normale Webdesigner, der seine Private Homepage erstellt, wird Frames nie brauchen.

    [edit]Habe die Kritik von Intrudor hier gleich mit eingearbeitet. Ist so leichter zu lesen.

    [ Dieser Beitrag wurde am 09.03.2003 um 10:34 Uhr von Loggy editiert. ]



  • Ich möchte noch ein paar Punkte anführen:

    Mit Frames spart man keine Ladezeit!
    Oft wird als Pro-Argument von Frames aufgeführt, dass der eine Teil der Seite doch nicht jedesmal neu geladen werden muss und das man deshalb Ladezeitvorteile hat. Das ist nicht so. Alle Bilder werden vom Browser sowieso gecached und müssen nicht nochmal gelesen werden. Also muss nur der Text neu geladen werden. Dafür hat man aber den Vorteil, dass man den (X)HTML overhead nicht mehrmals laden muss (wie im Frameset, wo jeder Bereich seinen Doketype, seinen Head usw. braucht). Und wer mal einen HTTP Header gesehen hat, der wird soetwas nicht wieder behaupten.

    Frames sind sehr unflexibel!
    Die sind sogar noch schlimmer als Tabellen, was die Flexibilität angeht. Möchte man irgendwas etwas exotischer gestalten, ufert das in verdammt viele Frames aus, was dann schlecht wartbar und auch schlecht zu benutzen ist (Stichwort: Focus). Eine Anpassung an die größe des Anwendungsfenster ist sehr schwierig.

    Frames gehören nicht zum XHTML Standard
    Zum Beispiel ist das target Attribut nicht mehr im Standard enthalten (ohne das kann man aber praktisch keine Frames benutzen). Das hat auch einen Grund, denn der Benutzer soll lernen seinen Browser zu bedienen und nicht von der Webseite bevormundet werden. Ich möchte entscheiden, wann eine neue Seite geladen wird und wann nicht.
    Genauso sind solche Sachen, wie das weglassen des Randes usw. nicht mehr möglich.

    Frames verleiten dazu JavaScript einzusetzen
    Auf Seiten, die Frames benutzen kommt man nur selten um JavaScript herum (weshalb JavaScript nicht für elementare Dinge eingesetzt werden soll ist eine andere Sache. Nur so viel dazu: Nicht jeder hat JavaScript aktiviert und möchte damit belästigt werden (Mozilla für Linux hat es z.B. standardmäßig deaktiviert)).
    Zum Beispiel ist es normalerweise nicht möglich zwei Frames gleichzeitig zu ändern. Und das nachladen von Framesets ist auch nur mit JavaScript möglich.

    Anpassung des Menüs ist kaum möglich!
    Wo bin ich denn gerade auf der Seite? Das fragt man sich öfter auf Seiten, die Frames zur Navigation einsetzen. Der Grund ist, dass sich das Menü nicht der Seite anpasst. Oft findet man auch die Untermenüpunkte ganz woanders, weil es eben ohne viel JavaScript nicht möglich ist das Menü zu erweitern.


Anmelden zum Antworten