See also ebooksgratis.com: no banners, no cookies, totally FREE.

CLASSICISTRANIERI HOME PAGE - YOUTUBE CHANNEL
Privacy Policy Cookie Policy Terms and Conditions
Diskussion:Frame (HTML) – Wikipedia

Diskussion:Frame (HTML)

aus Wikipedia, der freien Enzyklopädie

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)

[Bearbeiten] 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)


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)


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)

[Bearbeiten] 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)

[Bearbeiten] 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)


aa - ab - af - ak - als - am - an - ang - ar - arc - as - ast - av - ay - az - ba - bar - bat_smg - bcl - be - be_x_old - bg - bh - bi - bm - bn - bo - bpy - br - bs - bug - bxr - ca - cbk_zam - cdo - ce - ceb - ch - cho - chr - chy - co - cr - crh - cs - csb - cu - cv - cy - da - de - diq - dsb - dv - dz - ee - el - eml - en - eo - es - et - eu - ext - fa - ff - fi - fiu_vro - fj - fo - fr - frp - fur - fy - ga - gan - gd - gl - glk - gn - got - gu - gv - ha - hak - haw - he - hi - hif - ho - hr - hsb - ht - hu - hy - hz - ia - id - ie - ig - ii - ik - ilo - io - is - it - iu - ja - jbo - jv - ka - kaa - kab - kg - ki - kj - kk - kl - km - kn - ko - kr - ks - ksh - ku - kv - kw - ky - la - lad - lb - lbe - lg - li - lij - lmo - ln - lo - lt - lv - map_bms - mdf - mg - mh - mi - mk - ml - mn - mo - mr - mt - mus - my - myv - mzn - na - nah - nap - nds - nds_nl - ne - new - ng - nl - nn - no - nov - nrm - nv - ny - oc - om - or - os - pa - pag - pam - pap - pdc - pi - pih - pl - pms - ps - pt - qu - quality - rm - rmy - rn - ro - roa_rup - roa_tara - ru - rw - sa - sah - sc - scn - sco - sd - se - sg - sh - si - simple - sk - sl - sm - sn - so - sr - srn - ss - st - stq - su - sv - sw - szl - ta - te - tet - tg - th - ti - tk - tl - tlh - tn - to - tpi - tr - ts - tt - tum - tw - ty - udm - ug - uk - ur - uz - ve - vec - vi - vls - vo - wa - war - wo - wuu - xal - xh - yi - yo - za - zea - zh - zh_classical - zh_min_nan - zh_yue - zu -