Diskussion:Frame (HTML)

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Frame (HTML)“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

loeschung der argumente pro und contra frames

Ich bin gegen die Löschungen der Argumente für und gegen die Frameverwendung um 01:34 am 4. November 2003 und fordere die Sperrung des Artikels bis über den weiteren Inhalt des Artikels Konsens besteht. Ich wüsste auch nicht in welchem Artikel diese Argumente besser platziert wären als hier. Steven 82.82.117.221 02:27, 4. Nov 2003 (CET)

bzgl. Trennung von Struktur und Präsentation

Ich habe folgenden vermeintlichen Nachteil gelöscht: "dass Frames dem Grundgedanken der Trennung von Struktur und Präsentation widersprechen, da sie auch ein Mittel zur visuellen Gestaltung sind". Wo ist der Punkt? Frames sind eine HTML-Zusatztechnik, die ausschließlich auf die Präsentation abzielt. Ein Frameset "strukturiert" nicht im Sinne von semantischem Markup, daher ist dieses Unterscheidungsschema nicht anwendbar. Ein Frameset ist nichts anderes als eine Präsentationsvorschrift, ähnlich einem Stylesheet, nur dass sie in SGML abgefasst ist. [XFrames machen das noch deutlicher. Natürlich steckt hinter einer Präsentation, die ein Frameset definiert, auch immer eine Logik und eine Bedeutung. Aber wird Struktur und Präsentation vermischt? Höchstens wenn das target-Attribut gebraucht wird, was meistens der Fall ist. In diesem Fall liegt tatsächlich eine Vermischung von Strukturbeschreibung und Präsentationslogik vor. Deshalb ist target auch Bestandteil von (X)HTML Transitional. Das ist aber kein Problem von Frames an sich, sondern eine Fehlentscheidung von (X)HTML (bzw. den Erfindern von Frames). XFrames bzw. CSS 3 wird diese Vermischung aufheben. -- molily 18:48, 26. Mai 2005 (CEST)

nachteile

Ich habe bei Nachteile ausgebessert das Suchmaschienen die unterseiten nicht Indexieren könnnen und nur den text zwischen <noframes> und </noframes> auslesen was zu einem erheblichen Nachteil bei suchmaschienen füht.

Außerdem habe ich hinzugefühgt das sich Framebasierende Seiten schlecht bookmarken und drucken lassen. --Big v 13:29, 28. Jan 2006 (CET)

wischi-waschi

Das ist alles ein bisschen "Wischi-Waschi". Eine Auflistung von persönlichen Geschmäckern und Vorlieben, etwas garniert mit Gesagt-Gehörtem, die Hälfte davon im Konjunktiv. Viele der Argumente stammen aus alten Zeiten und sind nicht besser geworden über die Jahre.

Ich will hier kein Framedebatte starten, aber auch hier wird so getan, als ob "Frames was für Anfänger wären, Profis habe sowas nicht nötig". Das ist nicht richtig. Frames haben Vorteile und Nachteile, die individuell abgewogen werden müssen. Manchmal (nicht oft, aber doch) überwiegen die Vorteile, vor allem bei kleineren Sites.

Framebasierende Seiten lassen sich genauso bookmarken und drucken wie andere Seiten auch. Auch Suchmaschinen haben keine wirklichen Probleme mit Frames, Besucher merken es meistens gar nicht und wenn stört es sie nicht. Frames sind für "häufig" für bestimmte Auflösungen gemacht? Häufiger als andere?

Die Seite sollte auf die Hälfe zusammengestutzt werden.

--Chio 18:18, 2. Feb 2007 (CET)

Diskussion

Server-seitige Techniken, etwa Server Side Includes, oder der Einsatz von CSS sind mögliche Alternativen, um Seiten aus Teilstücken zusammenzusetzen oder die Seite visuell in Teilbereiche aufzuteilen, um damit den Einsatz von Frames zu vermeiden.

Das mit CSS ist Unsinn. Mit CSS kann man keine Seiten aus Teilstücken zusammensetzen; nutzen kann man es auch, wenn man Frames benutzt.

Ich habe den Satz so verstanden, dass man mit SSI die Seite zusammensetzt und mit CSS die Seite in Teilbereiche (z.B. div-Attribut) aufteilen kann.--84.148.2.13 17:13, 17. Jul 2006 (CEST)

Ladezeiten sind dann nicht mehr von Bedeutung, und man spart auch Webspace.

Das verstehe ich nicht.

• Die Ladezeit für die Seite ist erheblich größer, da bei jedem Seitenaufruf die gesamte Webseite heruntergeladen werden muss.
  • Ob die Ladezeit größer ist, ist relativ. Das Frameset selber und die target Attribute an den Links tragen so gesehen ja auch zur Ladezeit bei. Wenn auch nur beim ersten Abruf und nicht bei jeder Seite, wei bei der Variante ohne Frames. Fällt das nun ins Gewicht? Eine 1Mbit DSL Verbindung erlaubt das Herunterladen von 128kbyte pro Sekunde (1Mbit = 1024kbit; 1 byte = 8 bit; 1 Mbit = 128 kbyte). ISDN gestattet das Herunterladen von 64kbit/8kbyte pro Sekunde. Wenn wir von dem Standard-Anwendungsfall einer Navigation im Frame ausgehen, dann können wir mit einer Dateigröße zwischen 3 kbyte und 10 kbyte mehr bei der Seite ohne Frames rechnen. Noch weniger, wenn der Server die angefragte Seite mit Kompression ausliefert. Der Browser muss die heruntergeladene Seite dann noch rendern. Das ist abhängig von der Rendering Engine des Browsers und der Leistung des Rechners, sollte aber angesichts der heutigen CPU-Taktraten zu vernächlässigen sein. Das bedeutet, selbst für den ISDN Nutzer ist die zusätzliche Ladezeit unterhalb von einer Sekunde anzusiedeln. Nutzer die keine Flatrate haben, könnten jetzt argumentieren, dass sie dennoch mehr Geld für das Abrufen der Seite bezahlen müssen. Das stimmt. Allerdings muss man dann dagegen halten, dass Seiten, die heute noch Frames verwenden gerne auch noch Tabellen für Layouts zweckentfremden und von einer sauberen Trennung von Inhalt und Präsentation weit entfernt sind. Und das trägt wesentlich mehr zur Ladezeit der Seite bei, also ein valides semantisches Markup ohne Frames (auf dem man dann wenigstens die Seite bookmarken kann und wo der Zurück-Button funktioniert). Es kommt auf den Anwendungsfall an, aber prinzipiell überwiegen bei Frames die Nachteile. 87.123.60.251 14:13, 25. Sep. 2007 (CEST)

• An Webspace spart man nur die Header jeder Seite, das hat dann aber wiederum als Nachteil, dass die Seite auf die Weise dann überhaupt nicht mehr maschinenlesbar ist.
  • Bei SSI ist auch nicht vorgesehen, dass man die einzelnen Teile einzeln anzeigt, sondern immer im Kontext einer Seite 87.123.60.251 14:13, 25. Sep. 2007 (CEST)

Ich sehe Javascript als Datenquelle für Seiteninhalte weniger als "perfektionierung", vielmehr als krasses Gegenstück zu Frames.

Ich bitte um Meinungen. -- 84.143.44.99 11:39, 25. Mär 2006 (CET)

Frameset-Beispiel

Habe das Frameset-Beispiel mal entfernt, da sich ein ähnliches bereits im Artikel Frameset befindet (wo es meines Erachtens auch besser hingehört) --Dominic Z. 21:03, 9. Mai 2006 (CEST)

barrierefreiheit

gudn tach!
erst hue, dann hott.[1] mag da mal jemand mit reichlich screenreader-ahnung hand anlegen? -- seth 01:40, 2. Mär. 2009 (CET)

Und wo ist das Wichtigste?

Erschöpfender Artikel. Ich vermisse allerdings den benötigten Code, um eine Frameseite zu definieren, ein "HowTo", bevor man sich in die Diskussion begibt, was warum wie sinnvoll ist. Ich habe diesenArtikel nämlich aufgerufen, um ansatzweise zu erfahren, wie man sowas programmiert. Hat jemand Lust, das nochmal nachzubasteln? Bitte kein Verweis auf SelfHTML ;-) (nicht signierter Beitrag von 213.39.229.64 (Diskussion | Beiträge) 07:46, 10. Mär. 2009 (CET))

Siehe WP:WWNI, Punkt 9: Wikipedia ist weder Anleitung noch Ratgeber. Es ist nicht Aufgabe der Wikipedia zu erklären, wie man eine Redewendung, ein Gerät oder eine Software verwendet. Was ist denn falsch an SelfHTML? -- Hgulf Diskussion 12:12, 10. Mär. 2009 (CET)

html-Code

Ich würde gern wissen wie man eine Website mithilfe von html erstellt. Dafür müsste ich die Codes dafür wissen. (ohne Benutzername signierter Beitrag von 82.212.22.112 (Diskussion | Beiträge) )

gudn tach!

dies ist eine diskussionsseite ueber den wikipedia-artikel. hilfe zu html erhaeltst du z.b. auf [2]. -- seth 11:16, 25. Apr. 2009 (CEST)

Erläuterungen zu Frames

Also, für einen Laien, der eine Information benötigt, was denn ein "Frame" nun ist, wirken die Erläuterungen wenig erhellend. Wenn ich sowas in meinem Brockhaus lesen würde, würde ich ihn an den Verlag mit einem geharnischten Beschwerdebrief retournieren. Theobald Tiger (nicht signierter Beitrag von 91.115.179.25 (Diskussion | Beiträge) 18:44, 18. Jun. 2009 (CEST))

Nachteile nicht unbedingt.

Die hier beschriebenen Nachteile entsprechen wenn überhaupt nur einen Blickwinkel. Den des allgemein zugänglichen Internetportals. In einer WebApplikation, die ggf. nur im Intranet läuft, hat ein Frame viele Vorteile. Die hier aufgelisteten Nachteile greifen nicht. Einige anwendungsspezifische Bedingungen können auch mit ajax nicht gelöst werden. -- 188.46.144.48 15:19, 29. Mär. 2010 (CEST)

Rewrite Engine

Wow - ein Editwar und noch kein Diskussionsbeitrag? Darf ich mal einen Kompromiss versuchen? Auch wenn ich das noch nie probiert habe kann ich mir vorstellen, dass sowas funktioniert. Aber den Leser des Artikels so völlig allein zu lassen finde ich auch nicht richtig. Vorschlag: Der Hinweis mit der Rewrite Engine darf hinein und wird mit einer Referenz zu einer beschreibenden Website versehen. Damit sollten alle leben können. Munter bleiben -- Hgulf Diskussion 17:03, 23. Feb. 2011 (CET)

hallo hgulf! ich habe Benutzer:M-J direkt angesprochen [3]. solange seine behauptung nicht bewiesen ist sollte das auch nicht in den artikel. -- ∂ 02:04, 24. Feb. 2011 (CET)

Ich hatte auch etwas gesucht - in allen "offiziellen Beispielen" für mod_rewrite (und da gibt es schon recht ausführliche, zum Teil abstruse Kombinationen) werden Frames nicht wirklich erwähnt. Meiner Meinung nach kann man sowas höchstens über den (unzuverlässigen) Referrer machen.... was technisch eine eher unüberlegte Lösung wäre. Ich lasse mich gerne eines besseren belehren und freue mich auf ein Beispiel. --Guandalug 21:31, 24. Feb. 2011 (CET)

Ich zitiere hier mal MJ zum Thema:

„Hier für dich ein Tutorial: http://www.junko.de/redirect.0.html#497 Banales muss nicht belegt werden, wenn man keine Ahnung von den Gebiet Rewrite_Engine hat, sollte man das Revertieren um des Revertierenwillens sein lassen.“

– M-J: (auf meiner Diskussionsseite)

Ich vermute daher, sachliche Beiträge oder gar endlich mal Belege, dass das erstens überhaupt funktioniert und zweitens praktiziert wird (denn nur dann kann es Wikipedia-relevant sein), werden von MJ nicht kommen. Aufgrund der mehrmaligen Revertierung seines Beitrags, immer verbunden mit der Bitte um Belege, durch verschiedene Personen hat er stattdessen eine Vandalismusmeldung abgesetzt.--Fritzbruno 17:52, 28. Feb. 2011 (CET)

Meiner Ansicht nach ist das Thema jetzt vom Tisch: Kein Beleg, keine Erwähnung. Vielen Dank Euch beiden.-- Hgulf Diskussion 09:56, 3. Mär. 2011 (CET)

Ich hatte es auf SelfHTML zur Diskussion gestellt, Fazit dort: "Geht nicht!" --Fritzbruno 16:33, 3. Mär. 2011 (CET)

Entwicklung / Geschichte

Zu Zeiten des ersten Browserkrieges jedoch gab es zwei Möglichkeiten, eine graphisch einheitliche Gestaltung im Web realisieren: Frames oder komplexe Tabellenlayouts. Frames sind dabei meist schlanker und wurden in den unterschiedlichen Browsern auch einigermaßen einheitlich dargestellt. Die Webseitengestaltung über Frames hatte insofern ihre Berechtigung. Websites, die heute noch auf Frames basieren, sind meistens alt.

Ich finde, diese Informationen über den historischen Zusammenhang wären sinnvoll für diesen Artikel.--Intermalte 11:37, 10. Mai 2011 (CEST)