nicht angemeldet
Darf man Frames jetzt verwenden, oder nicht?
Hallo Freunde!
Mich würde das jetzt mal interessieren. Warum will das W3C Frames nicht offiziell machen, wo sie doch eigentlich recht praktisch sind und von vielen benutzt werden? Wie stellen die sich das eigentlich vor, wenn jemand eine nicht dynamische Seite erstellt? Dass er dann das Menü extra auf jede Seite pickt und dann bei Änderungen vielleicht 20 Mal ändern muss? Hat das W3C schon mal eine offizielle Erklärung dazu abgegeben?
gruß, wenzel
-
Warum will das W3C Frames nicht offiziell machen, wo sie doch eigentlich recht praktisch sind und von vielen benutzt werden?
http://www.w3.org/TR/html401/present/frames.html#edef-FRAMESET
http://www.w3.org/TR/html401/present/frames.html#edef-FRAME -
Hallo!
Mich würde das jetzt mal interessieren. Warum will das W3C Frames nicht offiziell machen, wo sie doch eigentlich recht praktisch sind und von vielen benutzt werden? Wie stellen die sich das eigentlich vor, wenn jemand eine nicht dynamische Seite erstellt? Dass er dann das Menü extra auf jede Seite pickt und dann bei Änderungen vielleicht 20 Mal ändern muss? Hat das W3C schon mal eine offizielle Erklärung dazu abgegeben?
(Warnung: Ich befreie mich von jeglichen Realitäten im World Wide Web. Es ist mir durchaus klar, dass kein derzeitiger Browser, auch nicht der Mozilla, fähig ist, das Konzept umzusetzen.)
Das Konzept von HTML sieht doch ein Menü an sich gar nicht vor. Blättern, Glossar, Inhaltsverzeichnis, Anfänge von Kapitel und Projekt, Copyright und haufenweise mehr lässt sich durch Verwendung von <link> machen. Die Meta-Angaben weisen den Autor und noch einige wichtige andere Dinge aus. Von der einen Seite zur anderen sind im eigentlichen Dokument nur sinnhafte Links, die einen logischen Bezug zum Text haben, notwendig, denn der eigentliche Hypertext macht keinen Unterschied zwischen verschiedenen Projekten.
Frames kommen aus einer Zeit, wo der erste große kommerzielle Browser herausgekommen ist und mit dem zweiten großen kommerziellen Browser, dem Internet Explorer, einen höchst eigenartigen Browserkrieg an mehreren Fronten geführt hat, zuletzt vor Gericht. Zu dieser Zeit wurden auch <font>, <table>, <center> und viele weitere Tags, die dem Prinzip von HTML zuwiderlaufen, erfunden, und dann vom W3C zähneknirschend abgesegnet. Die Seitenbastler wussten zu dieser Zeit teilweise gar nicht mehr um das Konzept oder sogar die Snytax von HTML, denn überall kamen lustige Programme daher, die vorgaben, WYSIWYG-fähig zu sein, was natürlich völliger Blödsinn ist, aber das ist ja egal. Sie stellen doch, wenn man sich es überlegt, einen Bruch mit der gesamten Idee des World Wide Webs dar und ziehen zusätzlich noch einen Rattenschwanz an Problemen mit sich, die zwar mittlerweile teilweise durch allerlei hochkomplexe Skripts beseitigt werden können, was aber noch mehr Probleme aufwirft. Weiters sind Frames sicher nicht plattformunabhängig, einfach zu warten oder in irgendeiner Weise mit dem Prinzip der Textauszeichnung vereinbar.
Das World Wide Web Consortium hat in der Vergangenheit bei einigen Elementen Fehler gemacht. Mittlerweile hat es, gemeinsam mit dem Aufkommen von Opera und Mozilla sowie dem Standard-Compliant-Mode des Internet Explorer einen Schritt in die richtige Richtung gemacht, in dem Frames nicht mehr vorgesehen sind.
Das hat sich jetzt ziemlich weit hergeholt angehört, aber ich denke, von der Seite hast du es noch nie betrachtet.
Und nein - ich bin keiner, der am liebsten HTML2 und graphische Browser abschaffen würde, auch war ich zu der Einführung der Frames noch gar nicht im Internet und ja - ich habe Frames lange für selbstverständlich erachtet. Das ändert aber trotzdem nichts an der Unsinnigkeit von Frames.
emu
[...]-
Hi,
Zu dieser Zeit wurden auch <font>, <table>, <center> und viele weitere Tags, die dem Prinzip von HTML zuwiderlaufen,
Wieso laufen Tabellen dem Prinzip von HTML zuwieder? (Höchstens wenn man sie fürs Layout mißbraucht, aber es soll ja noch leute geben, die mit Tabellen das tun, für das sie erfunden wurden: Tabellarische Daten darstellen)
Chris
-
Hallo!
Zu dieser Zeit wurden auch <font>, <table>, <center> und viele weitere Tags, die dem Prinzip von HTML zuwiderlaufen,
Wieso laufen Tabellen dem Prinzip von HTML zuwieder? (Höchstens wenn man sie fürs Layout mißbraucht, aber es soll ja noch leute geben, die mit Tabellen das tun, für das sie erfunden wurden: Tabellarische Daten darstellen)
Stimmt. Allerdings sind sie von Netscape erfunden worden und dann irgendwie in die Spezifikationen eingeflossen. Ich habe sie auch mehr zum Illustrieren der proprietären Eigenheiten während des Browserkrieges verwendet. Außerdem stellt sich natürlich die Frage ob man die Tabellen nicht etwas unkomplizierter und logischer definieren hätte können.
emu
[...]-
Hi,
Außerdem stellt sich natürlich die Frage ob man die Tabellen nicht etwas unkomplizierter und logischer definieren hätte können.
ACK, Tabellen von Hand zu erstellen ist wirklich eine Strafarbeit. Aber wie willst du es anders machen, ohne das Prinzip der Tags zu verändern?
Vielleicht so:?
<table>
<cell coordinate='A1'>1</cell>
<cell coordinate='A2'>2</cell>
<cell coordinate='B1'>11</cell>
<cell coordinate='B2'>12</cell>
</table>;-)
Ich finde das bisherige Prinzip recht logisch aufgebaut vom Gedanken des HTML-Trees her
<table>
<tr>
<td></td>
</tr>
</table>Chris
-
hi
<table>
<tr>
<td></td>
</tr>
</table>grotzdem wünscht man sich oftmals die Möglichkeit Tabellen in Spalten zu definieren. <table> in einem Atemzug mit <font> oder gar dem ultimativen sinnlos-Tag <center>, das schon als es von Netscape erdacht wurde redundant war, gleichzusetzen halte ich aber wirklich für riskant...
Grüße aus Bleckede
Kai
-
-
-
-
-
Mich würde das jetzt mal interessieren. Warum will das W3C Frames nicht offiziell machen, wo sie doch eigentlich recht praktisch sind und von vielen benutzt werden? Wie stellen die sich das eigentlich vor, wenn jemand eine nicht dynamische Seite erstellt? Dass er dann das Menü extra auf jede Seite pickt und dann bei Änderungen vielleicht 20 Mal ändern muss? Hat das W3C schon mal eine offizielle Erklärung dazu abgegeben?
So praktisch, wie es den Anschein hat, sind Frames garnicht. Gerade die "Großen" arbeiten entweder mit Content-Management-Systemen, die die entsprechende Änderung in allen HTML-Dateien automatisch vornehmen oder eben mit dynamischen Websites. Verwendet man nämlich Frames, dann steht man vor dem Problem, mit dem Viele Newbies die Regulars in den Foren nerven, nämlich wie ändere ich bei einem Click auf einen Link zwei Frames. Es gibt zwei Lösungen, beide genügen nicht professionellen Anforderungen. (Die HTML-Lösung mit je einem Frameset für jede mögliche Kombination aus Frames ist nur für kleinere Projekte geeignet, da sie schnell unübersichtlich und damit nicht mehr wartbar ist und die JS-Lösung führt zu Inkompatiblitäten zwischen Browsern und zu Problemen, wenn User JS ausgeschaltet haben) Außerdem ist da noch das Problem mit den Suchmaschinen, siehe hier:
http://www.google.de/search?hl=de&q="uses+frames"&btnG=Google-Suche&meta=
Stefan
-
hi
Das W3C hatte Frames temporär in der Spezifikation, in den HTML 4.0 Frameset und XHTML 1.0 Frameset DTDs. Allerdings haben Frames derartig viele Nachteile, während man die Vorteile mit der Lupe sichen kann.
Vorteile:
solange viele Browser noch kein position:fixed können um eine Navigation zu haben, die nicht mitscrollt
geringere Ladezeiten [wirklich? bei 2-3 kb code für die Navigation?]
zentrale Datei für die Navigation [oder man nutzt sowas wie SSI]Nachteile:
Traditionell ist der Inhalt im Web linear und damit auch z.B. für Screenreader lesbar
schon mal Frames gedruckt? [Standardfrage hier: wie kann ich dafür sorgen, dass immer ein bestimmter Frame gedruckt wird]
Ladezeit in Wahrheit höher -> mehr Header-Informationen durch 3 statt 1 Datei
Bookmarken, lokal abspeichern? Vergiss es.Grüße aus Bleckede
Kai
-
Hallo Kai,
ich widerspreche Dir nur ungern, aber nicht weil ich Deine Argumente entscheidend finde, sondern weil ich andere Nachteile sehe: Wir sehen ja an den vielen Fragen, dass der Steuerungs- und Wartungsaufwand nach schnellem Beginn stetig wächst.
Vorteile:
solange viele Browser noch kein position:fixed können um eine Navigation zu haben, die nicht mitscrollt
Vielleicht mit das beste Argument für Frames.
geringere Ladezeiten [wirklich? bei 2-3 kb code für die Navigation?]
Bei der von Dir angegebenen Größe genauso irrelevant wie die Header, die Du unten angibst, selbst bei Modem. Aber wenn's ein komplexes Javascript-Menü ist, spielt's vielleicht doch eine Rolle. Vor allem gibt's beim jeweiligen Neuladen des Menüs manchmal Effekte, wenn Anfänger schon etwas anklicken wollen, bevor das Menü komplett geladen ist.
zentrale Datei für die Navigation
Finde ich auch nicht schlecht. Vielleicht der einzige Wartungsvorteil.
Ergänzung: Maskierung von kryptischen URLs wird oft gewünscht.Nachteile:
Traditionell ist der Inhalt im Web linear und damit auch z.B. für Screenreader lesbar
stimmt; aber denken wirklich alle bei div-Konstruktionen daran, wie's linear aussieht?
schon mal Frames gedruckt?
Faktisch heute kein Problem mehr, da die meisten aktuellen Browser auch einzelne Rahmeninhalte drucken können. Viel nerviger: Tabellen mit 1000 Leergifs, von denen man Inhalte per cut und paste abspeichert und dann in der Zielanwendung eine völlige Katastrophe vorfindet.
Ladezeit in Wahrheit höher -> mehr Header-Informationen durch 3 statt 1 Datei
s.o.
Bookmarken, lokal abspeichern? Vergiss es.
Mit ein bisschen Javascript sind Deep-Links machbar und kontrollierbar, wenn man das als Anbieter möchte, vor allem die von Suchmaschinen. Allerdings wirklich ein Problem. Ein Pferdefuß: Seiten, die mittels JS die Zuordnung zu den Frames kontrollieren, sind lokal nur noch durch Auskommentieren wartbar...
Ergänzung:
m.E. Hauptnachteil: Eine komplexe Site läßt sich auf Dauer mit Frames sehr schwer warten. Auch history() funktioniert nur mit einigem Scriptaufwand, wenn überhaupt.Mein Fazit: Bei kleineren bis mittleren Projekten kann man mit Frames ziemlich schnell eine funktionale Lösung bauen, die wirklich in 98% aller Browser funktioniert, bei kommerziellen Kunden würde ich schon fast 100% angeben, da dort kaum jemand ohne Frames unterwegs ist. Vor allem, wenn man den Code mittels konsequentem Einsatz von CSS schlank hält, bleibt das Ganze halbwegs übersichtlich. Bei größeren Projekten sollte man nach anderen Lösungen, vor allem serverseitigen Techniken suchen. Aber wie Du weißt: Auch das hat seine Schattenseiten.
Viele Grüße
Mathias Bigge-
hi
Vielleicht mit das beste Argument für Frames.
wird aber das W3C nicht gelten lassen.
Ergänzung: Maskierung von kryptischen URLs wird oft gewünscht.
findet man aber eigentlich nur bei der "ich find' mich toll"-Fraktion, nicht so sehr bei großen Firmen.
stimmt; aber denken wirklich alle bei div-Konstruktionen daran, wie's linear aussieht?
denkt man fast von alleine. Bei einem Frame-Konstrukt wirkt das zu 99% als Blocker.
Faktisch heute kein Problem mehr, da die meisten aktuellen Browser auch einzelne Rahmeninhalte drucken können.
sofern mal erkennen kann, was hier welcher Frame ist, klappt das noch.
Mit ein bisschen Javascript sind Deep-Links machbar und kontrollierbar, wenn man das als Anbieter möchte, vor allem die von Suchmaschinen.
also die einzige mir bekannte Frameseite, die Depplinks erlaupt, ist Microsoft. Bei allen anderen würde man mit der Frage wohl höchstens ein "hä?" ernten.
Grüße aus Bleckede
Kai
-
-