Scrollbar per CSS in einer Fremseite ändern?

[Alexander B.]

Ist es möglich den Scrollbalken per CSS in einer frameseite, also in der seite mit frameset zu bestimmen?
ich möcht nicht den css code immer auf jeder seite, dei da angezeigt werden kann einfügen müssen.
wäre echt eine lücke in html, bzw. css, wenn sowas net ginge.

mfg, alexander

[Cheatah]

Hi,

Ist es möglich den Scrollbalken per CSS in einer frameseite, also in der seite mit frameset zu bestimmen?

was meinst Du mit "bestimmen"? Ob sie angezeigt werden oder nicht? CSS ist für die Darstellung von Elementen da, nicht für die Existenz derselben.

ich möcht nicht den css code immer auf jeder seite, dei da angezeigt werden kann einfügen müssen.

Darum kann man sie als externe Ressourcen referenzieren.

wäre echt eine lücke in html, bzw. css, wenn sowas net ginge.

Warum? Frames an sich werden in HTML lediglich geduldet; es besteht große Hoffnung, dass sie demnächst nicht mehr Teil davon sind. In jedem Fall steht jeder Frame bzw. dessen Inhalt grundsätzlich für sich; Du kannst lediglich die Eigenschaften des Sets (explizit _ohne_ die einzelnen Frameinhalte) definieren, die Eigenschaften der eingebundenen HTML-Dokumente sind ohne Abhängigkeit davon.

Cheatah

[MudGuard]

Hi,

Hi,

Ist es möglich den Scrollbalken per CSS in einer frameseite, also in der seite mit frameset zu bestimmen?

was meinst Du mit "bestimmen"? Ob sie angezeigt werden oder nicht? CSS ist für die Darstellung von Elementen da, nicht für die Existenz derselben.

Bei Scrollbars muß ich da widersprechen: overflow:hidden läßt die Scrollbars verschwinden, overflow:scroll immer anzeigen, overflow:auto; nur bei Bedarf.
Für (HTML-)Elemente gibt es display:none und visibility:hidden; um sie verschwinden zu lassen (klar, im Dokumentenbaum existieren die Elemente noch, sind aber nicht mehr sichtbar)

Warum? Frames an sich werden in HTML lediglich geduldet; es besteht große Hoffnung, dass sie demnächst nicht mehr Teil davon sind.

Da braucht man nicht hoffen: XHTML 1.1 kennt bereits keine Frames mehr...

cu,
Andreas

[Christian Seiler]

Hallo Andreas,

Warum? Frames an sich werden in HTML lediglich geduldet; es besteht große Hoffnung, dass sie demnächst nicht mehr Teil davon sind.

Da braucht man nicht hoffen: XHTML 1.1 kennt bereits keine Frames mehr...

Einspruch. XHTML 1.1 kennt bei der Standard-DTD keine Frames, aber es gibt, da XHTML 1.1 modularisiert ist, durchaus ein Frames-Modul:

http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_framesmodule

Grüße,

Christian

[MudGuard]

Hi,

Warum? Frames an sich werden in HTML lediglich geduldet; es besteht große Hoffnung, dass sie demnächst nicht mehr Teil davon sind.
Da braucht man nicht hoffen: XHTML 1.1 kennt bereits keine Frames mehr...
Einspruch. XHTML 1.1 kennt bei der Standard-DTD keine Frames, aber es gibt, da XHTML 1.1 modularisiert ist, durchaus ein Frames-Modul:

http://www.w3.org/TR/xhtml-modularization/abstract_modules.html#s_framesmodule

Uuuuuuuuups. Übersehen....
Warum gibt es das Zeug aber auch immer noch...

cu,
Andreas

[Christian Seiler]

Hallo Andreas,

Warum gibt es das Zeug aber auch immer noch...

Naja, in manchen Ausnahmefällen können Frames schon sinnvoll sein. Ich denke, die Message ist die richtige: Es ist nicht mehr in der DTD, d.h. Du musst schon wirklich genau wissen, was Du tust, wenn Du Frames einsetzt. :-)

Grüße,

Christian

[MudGuard]

Hi,

Naja, in manchen Ausnahmefällen können Frames schon sinnvoll sein. Ich denke, die Message ist die richtige: Es ist nicht mehr in der DTD, d.h. Du musst schon wirklich genau wissen, was Du tust, wenn Du Frames einsetzt. :-)

Nenne mir einen solchen Ausnahmefall, in dem Frames sinnvoller sind als serverseitig zusammengebaute Seiten.
Das Problem ist doch eigentlich, daß Frames von genau den Leuten benutzt werden, die NICHT wissen, was sie tun. Sieht man ja immer wieder an den Postings zum Thema Frames hier im Forum...

cu,
Andreas

[Christian Seiler]

Hallo Andreas,

Nenne mir einen solchen Ausnahmefall, in dem Frames sinnvoller sind als serverseitig zusammengebaute Seiten.

Bildergallerie mit Thumbnails auf der linken Seite z.B.? Da ist so etwas _enorm_ praktisch. (Tragischerweise sind Bildergalerien, die IMHO wirklich sinnvoll für Frames wären, gerade oft mit Tabellen und nicht mit Frames gestaltet...) Oder Webanwendungen - natürlich funktionieren die auch ohne Frames, aber mit Frames sind einige wesentlich komfortabler. Es gibt sicherlich noch mehr sinnvolle Einsatzgebiete - man muss nur darauf kommen.

"Frames sind böse"[tm] ist eine einfache Antwort auf eine komplexe Frage - manchmal geht es nicht oder nur mit großen Einbußen ohne Frames. Natürlich stimme ich Dir im großen und ganzen zu, dass man wirklich genau wissen muss, was man tut, wenn man Frames einsetzt, aber sie einfach kategorisch ablehnen - das ist »töricht«.

Das Problem ist doch eigentlich, daß Frames von genau den Leuten benutzt werden, die NICHT wissen, was sie tun.

Und das wird sich hoffentlich genau umdrehen.

Grüße,

Christian

[Cheatah]

Hi,

Bildergallerie mit Thumbnails auf der linken Seite z.B.? Da ist so etwas _enorm_ praktisch.

die Bilder werden gecachet, der zugehörige HTML-Code ist nicht wirklich umfangreich. Der einzige Vorteil wäre, dass die Scrollposition (und ergo schnelle Orientierung) nicht verloren geht; ob einem das die Nachteile eines Framesets wert sind, weiß ich nicht.

"Frames sind böse"[tm] ist eine einfache Antwort auf eine komplexe Frage - manchmal geht es nicht oder nur mit großen Einbußen ohne Frames. Natürlich stimme ich Dir im großen und ganzen zu, dass man wirklich genau wissen muss, was man tut, wenn man Frames einsetzt, aber sie einfach kategorisch ablehnen - das ist »töricht«.

Richtig. Unterscheide aber bitte Pauschalisierungen und deutliche Zeigefinger (insbesondere im Hinblick auf das "genau wissen müssen, was man tut") von kategorischer Ablehnung. Jede Technik hat ihren Platz, sonst gäbe es sie nicht - bei Frames darf aber bis zum Gegenbeweis sehr wohl bezweifelt werden, dass eben dieser Platz vorliegt.

Das Problem ist doch eigentlich, daß Frames von genau den Leuten benutzt werden, die NICHT wissen, was sie tun.
Und das wird sich hoffentlich genau umdrehen.

Dazu muss es notwendig(!) sein, tiefgehende Fachkenntnisse zu haben, wenn man Frames einsetzen will - und das wird wohl kaum passieren, solange Browser auch HTML beherrschen... oder der IE existiert.

Cheatah

[Christian Seiler]

Hallo Cheatah,

die Bilder werden gecachet, der zugehörige HTML-Code ist nicht wirklich umfangreich. Der einzige Vorteil wäre, dass die Scrollposition (und ergo schnelle Orientierung) nicht verloren geht; ob einem das die Nachteile eines Framesets wert sind, weiß ich nicht.

Es kommt darauf an. Wenn es eine private Bildergalerie ist, (evtl. noch passwortgeschützt) wäre das durchaus möglich, dass die Vorteile überwiegen.

bei Frames darf aber bis zum Gegenbeweis sehr wohl bezweifelt werden, dass eben dieser Platz vorliegt.

Du hast ihn doch selbst genannt: Intranet.

und das wird wohl kaum passieren, solange Browser auch HTML beherrschen... oder der IE existiert.

Ich würde es nicht nur auf den IE, sondern auf jeden Browser, der Frames unterstützt, beziehen. Das Problem ist aber ein Teufelskreis: Kein Browser hat ohne Framesunterstützung Erfolgschancen, keiner, der ohne Fachkenntnis Webseiten erstellt, wird auf Frames verzichten wollen, wenn er sie erst mal "liebgewonnen" hat, wenn nicht irgendein sehr triftiger Grund wie z.B. mangelnde Browserunterstützung gibt. Und im Moment scheinen die Webseitenersteller, die keine Fachkenntnis besitzen, anscheinend Überhand zu nehmen - das bezieht sich jetzt aber nicht auf dieses Forum, sondern auf den Eindruck vom WWW, den ich generell habe. (Hmmm. Ich sollte vielleicht mal eine Umfrage machen, wer alles <dfn> kennt. ;-))

Grüße,

Christian

[Cheatah]

Hi,

Es kommt darauf an.

das ist die Quintessenz des Themas ;-)

bei Frames darf aber bis zum Gegenbeweis sehr wohl bezweifelt werden, dass eben dieser Platz vorliegt.
Du hast ihn doch selbst genannt: Intranet.

Ich meinte das auf den jeweiligen, individuellen Fall bezogen.

und das wird wohl kaum passieren, solange Browser auch HTML beherrschen... oder der IE existiert.
Ich würde es nicht nur auf den IE, sondern auf jeden Browser, der Frames unterstützt, beziehen.

Sicher. Beim IE wissen wir aber, dass veraltete Techniken bis zum Erbrechen weitergeführt werden, und dass vor allem die Fehlerkorrektur so ziemlich jeden Schwachsinn noch interpretiert. Selbst wenn man irgendein XML mit eigener DTD angibt, bin ich nicht überrascht, wenn der IE ein statt dessen beinhaltetes Frameset noch "richtig" interpretiert.

Nebenbei: Unter http://heise.de/newsticker/data/pab-02.01.03-000/ kann man nachlesen, was von einer "zu guten" Fehlerkorrektur zu halten ist.

Das Problem ist aber ein Teufelskreis: Kein Browser hat ohne Framesunterstützung Erfolgschancen, keiner, der ohne Fachkenntnis Webseiten erstellt, wird auf Frames verzichten wollen, wenn er sie erst mal "liebgewonnen" hat, wenn nicht irgendein sehr triftiger Grund wie z.B. mangelnde Browserunterstützung gibt.

Ja, das ist leider nur allzu wahr. Möglicherweise könnte man einen namhaften Browserhersteller dazu bewegen, mit Framesets speziell umzugehen; ich denke da an ein "Diese Seite enthält Frames. Trotzdem darstellen?"-Warn-Popup, an standardmäßige lynx-like-Darstellungen (Opera ist diesbezüglich beispielsweise konfigurierbar) u.ä. Erfolgreich kann so etwas natürlich nur dann sein, wenn die Verbreitung dieses Browsers insbesondere auch den DAUs, Verzeihung, Hauptsächlich-Frame-Einsetzern hinreichend bekannt ist; d.h. er muss mit dem IE _spürbar_ konkurrieren.

Und im Moment scheinen die Webseitenersteller, die keine Fachkenntnis besitzen, anscheinend Überhand zu nehmen - das bezieht sich jetzt aber nicht auf dieses Forum, sondern auf den Eindruck vom WWW, den ich generell habe.

Tja... vielleicht sollten wir eine Standardmail (auch als offener Brief) verfassen, welche man Frame-Einsetzern[1] zukommen lassen kann?

(Hmmm. Ich sollte vielleicht mal eine Umfrage machen, wer alles <dfn> kennt. ;-))

Ich kenne das DFN (http://www.dfn.de/), aber <dfn> in der Tat nicht. Was ist das?

Cheatah

[1] Weicheiern, Warmduschern, Seerosengießern ;-)

[Christian Seiler]

Hallo Cheatah,

Ich meinte das auf den jeweiligen, individuellen Fall bezogen.

Natürlich, außer Frage. Ich war nur etwas »schreibfaul«. Besser: Im Intranet kann es Situationen geben, bei denen der Einsatz von Frames sinnvoll ist.

Sicher. Beim IE wissen wir aber, dass veraltete Techniken bis zum Erbrechen weitergeführt werden, und dass vor allem die Fehlerkorrektur so ziemlich jeden Schwachsinn noch interpretiert. Selbst wenn man irgendein XML mit eigener DTD angibt, bin ich nicht überrascht, wenn der IE ein statt dessen beinhaltetes Frameset noch "richtig" interpretiert.

Worauf Du Gift nehmen kannst...

Nebenbei: Unter http://heise.de/newsticker/data/pab-02.01.03-000/ kann man nachlesen, was von einer "zu guten" Fehlerkorrektur zu halten ist.

*rotfl* Die hatte ich gar nicht gelesen - Outlook-Wurmmeldungen ignoriere ich inzwischen - aber das ist genial. ;-)

Tja... vielleicht sollten wir eine Standardmail (auch als offener Brief) verfassen, welche man Frame-Einsetzern[1] zukommen lassen kann?

Hmmm. So eine Standardantwort meinst Du? Keine schlechte Idee, wobei mir freundliche Standardantworten auf die 2FF oder ähnliche lieber wären. Am besten noch mit automatischen Knopf zum einfügen - ließe sich sicher per Bookmarklet lösen. ;-)

Ich kenne das DFN (http://www.dfn.de/), aber <dfn> in der Tat nicht. Was ist das?

Waaaaaaas? *ungläubigdreinschau* _Du_ kennst das nicht?
http://selfhtml.teamone.de/html/text/logisch.htm#elemente

[1] Weicheiern, Warmduschern, Seerosengießern ;-)

Pssssssssst. ;-)

Grüße,

Christian

[Cheatah]

Hi,

Ich meinte das auf den jeweiligen, individuellen Fall bezogen.
Natürlich, außer Frage. Ich war nur etwas »schreibfaul«. Besser: Im Intranet kann es Situationen geben, bei denen der Einsatz von Frames sinnvoll ist.

ich auch. Ebenfalls besser: Wenn jemand hier im Forum irgendwie zu Frames tendiert, halte ich es für richtig, davon abzuraten, solange nicht schlüssig belegt ist, dass es sich um einen jener Fälle handelt - z.B. den Einsatz im Intranet - in dem Frames wirklich sinnvoll sind.

Irgendwo dazwischen treffen wir uns jetzt, glaube ich :-)

Worauf Du Gift nehmen kannst...

Also beispielsweise eine aktuelle Bro'sis-CD, die vermutlich garantiert tödlich wirkt *g*

Nebenbei: Unter http://heise.de/newsticker/data/pab-02.01.03-000/ kann man nachlesen, was von einer "zu guten" Fehlerkorrektur zu halten ist.

*rotfl* Die hatte ich gar nicht gelesen - Outlook-Wurmmeldungen ignoriere ich inzwischen - aber das ist genial. ;-)

Es wäre doch mal interessant, einen Outlook-Wurm zu schreiben, welcher alle empfangenen Mails durchleuchtet, dort nach Outlook-Headern sucht (damit er nur an Outlook-User weitergeschickt wird - warum andere nerven?), und an das From eine Liste der Outlook-Sicherheitslücken und -Viren der letzten paar Monate schickt. Es dürfte sich dabei zwar um eine ziemlich umfangreiche Mail handeln (naja, <iframe src="da_wo_die_liste_steht"/> würde vom Prinzip her schon reichen), aber vielleicht merkt es dann ja mal der eine oder andere ;-)

Tja... vielleicht sollten wir eine Standardmail (auch als offener Brief) verfassen, welche man Frame-Einsetzern[1] zukommen lassen kann?
Hmmm. So eine Standardantwort meinst Du?

Ja, nur halt im Stile "Sehr geehrter Webmaster, ich habe Ihre Site besucht und dabei negativ festgestellt, dass ...". In der Richtung "ich konnte Ihre Site nicht richtig benutzen, bitte reparieren Sie sie".

Keine schlechte Idee, wobei mir freundliche Standardantworten auf die 2FF oder ähnliche lieber wären. Am besten noch mit automatischen Knopf zum einfügen - ließe sich sicher per Bookmarklet lösen. ;-)

*g* Ja, in Verbindung mit einer Formmailer-Site, welche die Standardtexte für verschiedene typische guck-mal-ich-kann-HTLM[tm]-programmieren-"Profi"-Sites bereithält ;-)

Ich kenne das DFN (http://www.dfn.de/), aber <dfn> in der Tat nicht. Was ist das?
Waaaaaaas? *ungläubigdreinschau* _Du_ kennst das nicht?

Nein, ich kenne längst nicht alles. Insbesondere in jener Ecke (danke für den Link) bin ich wenig bewandert, weil ich solche Elemente für nicht wirklich HTML-tauglich halte: Sie sind IMHO zu speziell für besondere Anwendungen konzipiert, die man dann eher über ein z.B. <span class="definition"> und title-Attribute lösen oder auf XML umsteigen sollte. Natürlich sind mir die Möglichkeiten wie Fußnoten, seitenglobale Markierungen usw. bewusst; dennoch halte ich die Praxisnähe und die Unterschiede zwischen jenen Elementen nicht für groß genug, um eigenständige Elemente in einer für HTTP konzipierten Auszeichnungssprache zu rechtfertigen. Dann doch eher ein Universalattribut mit bestimmten Tokens definieren - nur für jene Fälle, wo tatsächlich eine _logische_ Unterscheidung möglich ist (also z.B. Fußnoten erzeugt werden können), nicht wenn der einzige Unterschied in einer potentiell anderen Darstellung liegt.

[1] Weicheiern, Warmduschern, Seerosengießern ;-)
Pssssssssst. ;-)

Mit-vielen-s-psster ;-)

Cheatah

[Christian Seiler]

Hallo Cheatah,

Irgendwo dazwischen treffen wir uns jetzt, glaube ich :-)

Genau. :-)

Also beispielsweise eine aktuelle Bro'sis-CD, die vermutlich garantiert tödlich wirkt *g*

Full ACK. Ich kenne nur das, womit man im Radio und Fernsehen ab und zu von denen vollgedudelt wird - das reicht mir.

Es wäre doch mal interessant, einen Outlook-Wurm zu schreiben, welcher alle empfangenen Mails durchleuchtet, dort nach Outlook-Headern sucht (damit er nur an Outlook-User weitergeschickt wird - warum andere nerven?), und an das From eine Liste der Outlook-Sicherheitslücken und -Viren der letzten paar Monate schickt. Es dürfte sich dabei zwar um eine ziemlich umfangreiche Mail handeln (naja, <iframe src="da_wo_die_liste_steht"/> würde vom Prinzip her schon reichen), aber vielleicht merkt es dann ja mal der eine oder andere ;-)

Wir können das ja mal als längerfristiges Projekt in Angriff nehmen. .oO(Wo war noch mal gleich diese Sicherheitslockseite?)

Ja, nur halt im Stile "Sehr geehrter Webmaster, ich habe Ihre Site besucht und dabei negativ festgestellt, dass ...". In der Richtung "ich konnte Ihre Site nicht richtig benutzen, bitte reparieren Sie sie".

*g*

*g* Ja, in Verbindung mit einer Formmailer-Site, welche die Standardtexte für verschiedene typische guck-mal-ich-kann-HTLM[tm]-programmieren-"Profi"-Sites bereithält ;-)

*hehe*

weil ich solche Elemente für nicht wirklich HTML-tauglich halte: Sie sind IMHO zu speziell für besondere Anwendungen konzipiert, die man dann eher über ein z.B. <span class="definition"> und title-Attribute lösen oder auf XML umsteigen sollte.

Warum? IMHO fehlen noch ein oder zwei Elemente, die ganz nützlich sein könnten. (Ich merke mir nur nie, welche, nur wenn ich sie wieder brauche, fallen sie mir wieder ein. ;-)) <dfn> heißt Definition - das kann es überall geben, egal, auf welcher Art Webseite man sich befindet, zumindest wenn die Webseiten informativ sind bzw. sein wollen. Ich selbst verwende <dfn> auch nicht so häufig, aber <abbr>, <acronym>, <code>, <var> und <samp> (letzteres neuerdings, molily hat mich mal darauf aufmerksam gemacht) verwende ich sehr häufig.

nicht wenn der einzige Unterschied in einer potentiell anderen Darstellung liegt.

IMHO haben diese logischen Auszeichnungen eine semantische Bedeutung. Aber da kann man ewig diskutieren.

Gute Nacht,

Christian

[Cheatah]

Hi,

Also beispielsweise eine aktuelle Bro'sis-CD, die vermutlich garantiert tödlich wirkt *g*
Full ACK. Ich kenne nur das, womit man im Radio und Fernsehen ab und zu von denen vollgedudelt wird - das reicht mir.

mehr brauchte ich glücklicherweise auch noch nicht zu ertragen...

Es wäre doch mal interessant, einen Outlook-Wurm zu schreiben, [...]
Wir können das ja mal als längerfristiges Projekt in Angriff nehmen.

Gerne :-)

.oO(Wo war noch mal gleich diese Sicherheitslockseite?)

Sorry, auf dem Uralt-Mac meiner Mutter fehlt mir leider meine Bookmark-Liste... aber unter heise.de findest Du einen Browser-Check, über den sicher die eine oder andere Seite aufgespürt werden kann.

weil ich solche Elemente für nicht wirklich HTML-tauglich halte: Sie sind IMHO zu speziell für besondere Anwendungen konzipiert, die man dann eher über ein z.B. <span class="definition"> und title-Attribute lösen oder auf XML umsteigen sollte.
Warum?

Hm, genau diese Frage dachte ich beantwortet zu haben :-)

IMHO fehlen noch ein oder zwei Elemente, die ganz nützlich sein könnten.

Na klar, es gibt regelmäßig Fälle, in denen diese und ähnliche Elemente sinnvoll sind. Dazu gehört auch <doublea> mit den Attributen href1, href2, target1 und target2.

Soll heißen: Es gibt viele oft auftauchenden Spezialfälle. Das rechtfertigt aber noch lange keine eigenständigen Elemente - ganz besonders dann, wenn zu einem oder gar mehreren anderen Elementen quasi kein Unterschied besteht.

<dfn> heißt Definition - das kann es überall geben, egal, auf welcher Art Webseite man sich befindet, zumindest wenn die Webseiten informativ sind bzw. sein wollen.

Wo sind <author>, <mainpage> und <faq element="question|answer">?

Ich selbst verwende <dfn> auch nicht so häufig, aber <abbr>, <acronym>, <code>, <var> und <samp> (letzteres neuerdings, molily hat mich mal darauf aufmerksam gemacht) verwende ich sehr häufig.

Respekt. Dennoch: Welche Vorteile bietet das - sowohl in Praxis als auch in Theorie - einem HTTP-Client und/oder dessen User, die nicht auch mittels eines einzigen Elementes oder nur Universal- oder anderen Attributen hätten gelöst werden können? Verzichte dabei bitte auf jene Dinge, die mittels handelsüblicher CSS-Anwendungen durchgeführt werden können :-)

Cheatah

[Christian Seiler]

Hallo Cheatah,

Na klar, es gibt regelmäßig Fälle, in denen diese und ähnliche Elemente sinnvoll sind. Dazu gehört auch <doublea> mit den Attributen href1, href2, target1 und target2.

*rotfl*

Wo sind <author>, <mainpage> und <faq element="question|answer">?

<author> und <mainpage> kann ich nicht nachvollziehen, (<link rel=".."> wenn Du das meinst, wenn nicht, sag' mir bitte, was Du damit wie auszeichnen willst) <faq> wäre ein extremer Sonderfall. Definitionen tauchen aber doch häufiger auf.

Respekt.

I wo. Ich denke nur an meine Besucher. (nicht nur an die mit graphischen Browsern)

Dennoch: Welche Vorteile bietet das - sowohl in Praxis als auch in Theorie - einem HTTP-Client und/oder dessen User, die nicht auch mittels eines einzigen Elementes oder nur Universal- oder anderen Attributen hätten gelöst werden können?

Hmm. Da hast Du allerdings recht. Aber es gibt auch keinen Nachteil. IMHO sind beide Varianten gleichwertig.

Verzichte dabei bitte auf jene Dinge, die mittels handelsüblicher CSS-Anwendungen durchgeführt werden können :-)

*hehe* Naja, Attributselektoren funktionieren ja in Mozilla und Konqueror. (Opera bin ich zu faul zum testen) :-) Der IE wird *hoffentlich* in der Version 7 nachziehen...

Grüße,

Christian

[Cyx23]

Hallo,

Ich meinte das auf den jeweiligen, individuellen Fall bezogen.
Natürlich, außer Frage. Ich war nur etwas »schreibfaul«. Besser: Im Intranet kann es Situationen geben, bei denen der Einsatz von Frames sinnvoll ist.

ich auch. Ebenfalls besser: Wenn jemand hier im Forum irgendwie zu Frames tendiert, halte ich es für richtig, davon abzuraten, solange nicht schlüssig belegt ist, dass es sich um einen jener Fälle handelt - z.B. den Einsatz im Intranet - in dem Frames wirklich sinnvoll sind.

ich möchte einfach mal auf fast immer mögliche Vorteile beim Einsatz
von Frames und JavaScript im Internet hinweisen, es kann nämlich ganz
massiv Traffic eingespart werden, zugleich steigt die Geschwindigkeit.
Wenn z.B. aus ergonomischen Gründen Inhalt auf mehrere Seiten verteilt
wird, ob nun eine textlastige Abhandlung oder ein kleiner Shop, kann
der Traffic per Frames und/oder clientseitigem JavaScript auf bis
unter zehn Prozent anderer Lösungen gedrückt werden. Also sehr gute
Performance und ordentliche Kostenersparnis.

Grüsse

Cyx23

[molily]

Hallo ihr,

Möglicherweise könnte man einen namhaften Browserhersteller dazu bewegen, mit Framesets speziell umzugehen

Ja.
Framesets waren bei gekonnter Anwendung schon immer kompatibel und damit sollte eine derartige Browsereinstellung schon heute vorhanden sein, im Idealfall würde es dem Benutzer keine Nachteile bringen.
Frames können auch heute bereits im Hinblick auf deren Probleme verantwortungsvoll eingesetzt werden, wenn man sie für notwendig erachtet. Es lassen sich Nachladescripts und -links, noframes-Bereiche und Alternativnavigationen einbauen und framelose Versionen on-the-fly erzeugen, weiterhin lassen sich alle Unterseiten verlinkbar machen und so weiter. (Dazu könnte jemand einmal ein Feature-Artikel schreiben... *hüstel* <I>) Das alles ist hinlänglich bekannt, erfährt aber, wie Andreas sagt, nur wenig Bekanntheit. Neunzig Prozent dieser Arbeit müssen meiner Meinung nach auf der Seite vom Autor und nicht im Benutzeragent getan werden - selbst wenn die Browser das Abschalten von Frames erlauben, bringt dies momentan »nullkommanichts«, da noframes-Bereiche in der Regel leer sind und die Seiten in völliger Unkenntnis der Probleme von Frames erstellt wurden.

ich denke da an ein "Diese Seite enthält Frames. Trotzdem darstellen?"-Warn-Popup

Siehe auch XFrames und Content-Negotiation über den Accept-Header...

Und im Moment scheinen die Webseitenersteller, die keine Fachkenntnis besitzen, anscheinend Überhand zu nehmen - das bezieht sich jetzt aber nicht auf dieses Forum, sondern auf den Eindruck vom WWW, den ich generell habe.

Das ist der Gedanke des Webs. *smirk* Deshalb muss es einfach bedienbare Autorenwerzeuge geben, welche technisch hochwertige Seiten produzieren. Wobei selbige im Endeffekt nur so gut assistieren können, wie der Netzpublizist es bedienen kann, dennoch liegt momentan einiges im Argen.

Grüße,
Mathias

[emu]

Hallo!

Framesets waren bei gekonnter Anwendung schon immer kompatibel

Rein theoretisch betrachtet.

im Idealfall würde es dem Benutzer keine Nachteile bringen.

Diesen Fall gibt es nicht, schon allein deshalb, weil er doppelte Arbeit bedeutet - eine Frames- und eine gleichwertige No-Frames-Version.

Es lassen sich Nachladescripts und -links, noframes-Bereiche und Alternativnavigationen einbauen und framelose Versionen on-the-fly erzeugen, weiterhin lassen sich alle Unterseiten verlinkbar machen und so weiter.

Das ist doch absurd und steht in keiner Relation zum Nutzen. Auch im Intranet kann ich mir nichts sinnvolles vorstellen, ich glaube sogar, dass das mit dem Internet eine Art Disclaimer für den Fall, dass es tatsächlich irgendwann eine Spezialanwendung gibt, wo es vielleicht sinnvoll wäre, ist.

(Dazu könnte jemand einmal ein Feature-Artikel schreiben... *hüstel* <I>)

http://aktuell.de.selfhtml.org/artikel/phpasp/php-frames/index.htm

Das alles ist hinlänglich bekannt, erfährt aber, wie Andreas sagt, nur wenig Bekanntheit.

Schöner Satz, hässliche Realität. Frames machen große Teile des WWW für bestimmte Benutzer (nein, nicht nur Blinde) mit bestimmten Fenstergrößen und Browsern völlig oder fast unbenutzbar.

Beispiele aus dem steuerfinanziertem Bereich:
http://www.orf.at/
http://www.bmaa.gv.at/
http://www.bmi.gv.at/
und ein Beispiel, wo man sich zumindest bemüht hat, zugänglich zu sein, was nicht ganz gelungen ist: http://help.gv.at/ - immerhin.

Viel Spaß bei kleiner Bildschirmauflösung oder »falschem« Browser.

Ich halte daher XFrames für den größten Irrtum der neueren Geschichte des W3C, weil sie zwar ein paar Kleinigkeiten beseitigt, aber die Benutzung von Frames, die vollkommen sinnlos ist, legitimiert - und weiter werden kleine Bildschirmauflösungen nicht benutzbar sein und weiter wird man es mit nichtframefähigen Browsern nicht benutzen können. Und einen Sinn hat es trotz XFrames nicht.

emu
[...]

[molily]

Hallo, emu,

Framesets waren bei gekonnter Anwendung schon immer kompatibel

Rein theoretisch betrachtet.

Ja.

im Idealfall würde es dem Benutzer keine Nachteile bringen.

Diesen Fall gibt es nicht, schon allein deshalb, weil er doppelte Arbeit bedeutet - eine Frames- und eine gleichwertige No-Frames-Version.

Ja, dies benötigt natürlich ausreichende serverseitige Intelligenz.

Es lassen sich Nachladescripts und -links, noframes-Bereiche und Alternativnavigationen einbauen und framelose Versionen on-the-fly erzeugen, weiterhin lassen sich alle Unterseiten verlinkbar machen und so weiter.

Das ist doch absurd und steht in keiner Relation zum Nutzen.

Zweifellos.

Auch im Intranet kann ich mir nichts sinnvolles vorstellen, ich glaube sogar, dass das mit dem Internet eine Art Disclaimer für den Fall, dass es tatsächlich irgendwann eine Spezialanwendung gibt, wo es vielleicht sinnvoll wäre, ist.

http://www.teleportacia.org/war/war.html... ;)

(Dazu könnte jemand einmal ein Feature-Artikel schreiben... *hüstel* <I>)

http://aktuell.de.selfhtml.org/artikel/phpasp/php-frames/

Dieser Artikel behandelt nur den Aspekt der Nachladeskripte. Ich schreibt momentan einen umfassenden, welcher diesen verlinkt beziehungsweise zitiert.

Das alles ist hinlänglich bekannt, erfährt aber, wie Andreas sagt, nur wenig Bekanntheit.

Schöner Satz, hässliche Realität. Frames machen große Teile des WWW für bestimmte Benutzer (nein, nicht nur Blinde) mit bestimmten Fenstergrößen und Browsern völlig oder fast unbenutzbar.

Nichts weniger als das will ich ändern. ;)

Beispiele aus dem steuerfinanziertem Bereich:
http://www.orf.at/
http://www.bmaa.gv.at/
http://www.bmi.gv.at/
und ein Beispiel, wo man sich zumindest bemüht hat, zugänglich zu sein, was nicht ganz gelungen ist: http://help.gv.at/ - immerhin.

Oha, in Deutschland gibt es immerhin die BITV. Ich habe einigen Verantwortlichen von staatlichen de-Seiten auf den Zahn gefühlt, die gleiche Vorgehensweise würde ich dir auch raten, sofern du gedenkst, etwas dagegen zu tun. Vielleicht kann man die Aktionen auf W3C-WAI-DE und/oder W3C-AT koordinieren; zumeist lesen dort auch die Verantwortlichen mit. Die Problematik ist denen sicher bekannt, deshalb würde ich jedem dazu raten, ganz unverbindlich eine Nachricht an jeden Operator zu schreiben und die Probleme anzusprechen.
Obacht, was ich gefunden habe: http://www.cio.gv.at/egovernment/wai/Umsetzung.html, vergleiche auch die PDF-Dateien im Elternverzeichnis.

Ich halte daher XFrames für den größten Irrtum der neueren Geschichte des W3C, weil sie zwar ein paar Kleinigkeiten beseitigt,

Das sehe ich teilweise ähnlich, aber die Entwicklung ist glücklicherweise noch nicht abgeschlossen, vergleiche mein anderes Posting bzgl. XFrames im Thread.

aber die Benutzung von Frames, die vollkommen sinnlos ist, legitimiert

Ich finde das Konzept ebenfalls unpassend und in Zeiten von CSS (overflow:scroll, position:fixed etc.) überholt, aber nichtsdestoweniger werden Frames weiterexistieren und wir müssen weiterhin damit leben und die Autoren animieren, ihre Framesets, wenn sie sich nicht davon abhalten lassen, zumindest so benutzerfreundlich wie möglich zu gestalten.

und weiter werden kleine Bildschirmauflösungen nicht benutzbar sein und weiter wird man es mit nichtframefähigen Browsern nicht benutzen können.

Ja, »es ist kein Fehler im System, das System ist der Fehler«(TM), muuha.

Mathias

[Cheatah]

Hi,

Nenne mir einen solchen Ausnahmefall, in dem Frames sinnvoller sind als serverseitig zusammengebaute Seiten.

don't forget about the intranet. Bei einer geschlossenen Benutzergruppe ist es immer möglich, dass die Vorteile einer Technik ihre Nachteile überwiegen.

Das Problem ist doch eigentlich, daß Frames von genau den Leuten benutzt werden, die NICHT wissen, was sie tun.

Im Internet: ja, eindeutig. Da fällt mir momentan auch nichts ein, wo Frames wirklich Sinn machen.

Sieht man ja immer wieder an den Postings zum Thema Frames hier im Forum...

ACK...

Cheatah

[molily]

Hallo, Andreas,

[Frames]

Warum gibt es das Zeug aber auch immer noch...

Frames wird es auch weiterhin geben - du kennst XFrames? http://www.w3.org/TR/xframes/. Das, was uns momentan als Frames bekannt ist, ist hoffentlich in Bälde tot.

Mathias

[Sven Rautenberg]

Moin!

Frames wird es auch weiterhin geben - du kennst XFrames? http://www.w3.org/TR/xframes/. Das, was uns momentan als Frames bekannt ist, ist hoffentlich in Bälde tot.

Gib dich dieser Illusion nicht hin. Frames werden nie aussterben, weil Netscape 4 nicht ausstirbt, oder sonst irgendwelche uralt-Browser. Denn die DTD für HTML 4.01 Frameset existiert und ist gültig. Das W3C hat es bis jetzt noch nicht für notwendig gehalten, irgendeine vorhandene, aber veraltete DTD für ungültig zu erklären - das dürfte auch schwer werden, weil die Elemente meist nur erweitert wurden, ein HTML4-Browser wird also auch HTML 2.0 verstehen.

Trotzdem: XFrames sind eine schöne Sache (hab' mir das Dokument gerade mal durchgelesen). Insbesondere die 2-Frames-Frage wird nicht zur 2-XFrames-Frage werden können - das ist IMO der größte Vorteil des neuen Ansatzes.

Dummerweise wird XFrames durch die Idee des W3C, für gewisse Dinge einfach neue Tags zu erfinden, inkompatibel zu Frames. Und _das_ wird eben die Verbreitungsgeschwindigkeit enorm bremsen.

- Sven Rautenberg

[molily]

Hallo Sven,

Frames wird es auch weiterhin geben - du kennst XFrames? http://www.w3.org/TR/xframes/. Das, was uns momentan als Frames bekannt ist, ist hoffentlich in Bälde tot.

Gib dich dieser Illusion nicht hin. Frames werden nie aussterben, weil Netscape 4 nicht ausstirbt, oder sonst irgendwelche uralt-Browser.

Sicherlich - ich meinte auch eher, dass den HTML 4-Frames zunächst formal etwas Neues entgegensteht, welches offiziell die alten Frames ablöst und was eines Tages(tm) aufgrund seiner vielfältigeren Fähigkeiten stärker verwendet werden wird, sobald es die Browser unterstützen. Momentan sieht bezüglich der Unterstützung anderer im Web künftig Verwendung findenden XML-Sprachen auch nicht rosig aus - keine Frage.

Denn die DTD für HTML 4.01 Frameset existiert und ist gültig. Das W3C hat es bis jetzt noch nicht für notwendig gehalten, irgendeine vorhandene, aber veraltete DTD für ungültig zu erklären - das dürfte auch schwer werden, weil die Elemente meist nur erweitert wurden, ein HTML4-Browser wird also auch HTML 2.0 verstehen.

Ich würde nicht unterschätzen, wie schnell sich das Web entwickelt, denn in zwei bis drei Jahren, wenn XHTML 2 und CSS 3 gargekocht beziehungsweise schon etabliert sind, ist es durchaus möglich, dass XFrames mit Sicherheit breite Verwendung finden, wenngleich die HTML 4-Frames weiterhin genutzt werden.

(»In Bälde« war zugegebenermaßen etwas zu optimistisch von mir ausgedrückt. *smirk*)

Trotzdem: XFrames sind eine schöne Sache (hab' mir das Dokument gerade mal durchgelesen). Insbesondere die 2-Frames-Frage wird nicht zur 2-XFrames-Frage werden können - das ist IMO der größte Vorteil des neuen Ansatzes.

Naja, für den Anfang ganz akzeptabel. Ich warte gepsannt darauf, dass Björn Höhrmanns Papier zu XFrames öffentlich wird. Der momentane Working Draft löst viele Probleme meiner Meinung nach nicht oder nur unzureichend, dort wird sich, so hoffe ich, noch viel grundlegendes tun bis zur Verabschiedung.

Dummerweise wird XFrames durch die Idee des W3C, für gewisse Dinge einfach neue Tags zu erfinden, inkompatibel zu Frames. Und _das_ wird eben die Verbreitungsgeschwindigkeit enorm bremsen.

Natürlich, aber XFrames ist nunmal die erste offizielle offen entwickelte Technik für Frames, bei welcher man bewusst keine Kompatibilität anstrebt. Es wird mit Absicht das alte Konzept gänzlich in Frage gestellt.
(Ich schreibe übrigens an einer kleinen Zusammenstellung, welche ein paar Übergangslösungen für bekannte HTML 4-Probleme bietet. Denn falls man Frames benutzt, sollte man die Probleme zumindest minimieren, was meiner Meinung nach bis zu einem gewissen Punkt durchaus möglich ist, womit Frames zumindest einigermaßen erträglich werden.)

Grüße,
Mathias