Frames
callidus
- javascript
Hi Leute...
schaut mal auf meine Website:
http://sebkl.de.vu
ihr könnt dort sehen, das auf der rechten seite ein Weißer Balken ist.
Das kommt daher, dass nicht 9 Frames angezeigt werden können (3x3).
Nun wollte ich den Mittleren Frame mit Javascript einfügen
also ein Frame im Frame...
Nun wollte ich wissen, wie ich das Einprogrammieren kann, sodass auch kein Rand zu sehen ist, wo die Grenze der Frames ist.
Hallo,
schaut mal auf meine Website:
http://sebkl.de.vu
meinst du nicht etwa http://de.geocities.com/seb_kl/?
ihr könnt dort sehen, das auf der rechten seite ein Weißer Balken ist.
Das kommt daher, dass nicht 9 Frames angezeigt werden können (3x3).
Richtig. Und das kommt wiederum daher, dass du in jeder Spalte nur zwei Frames definierst, anstatt drei:
<frameset cols="100px,*,100px" border="0" scroll=no>
<frame src="sites/o_links.html" name="o_links">
<frame src="sites/o_mitte.html" name="o_mitte"
<frame scr="sites/o_rechts.html" name="o_rechts">
</frameset>
Schau dir die Konstruktion nochmal ganz genau und kritisch an.
Davon abgesehen hat die Einheit "px" in HTML-Attributen nichts verloren - sie ist da nicht nur überflüssig, sondern sogar falsch!
Und außerdem sieht das irgendwie blöd aus, wenn in allen Randframes Scrollbalken auftauchen; vor allem, wenn man wirklich mal an diesen Scrollbalken rumspielt und den Inhalt (und damit auch das Hintergrundbild) verschiebt (siehe Screenshot, 28k PNG).
Hier wäre es günstiger, wenn du schon unbedingt Frames einsetzen willst, in den leeren Randframes kein HTML-Dokument einzusetzen, sondern nur das Bild.
Nun wollte ich den Mittleren Frame mit Javascript einfügen
Du liebe Güte, warum das denn?
Korrigiere mal den bestehenden Code, dann bist du schon einen gewaltigen Schritt weiter. Und wenn du dir und vor allem deinen Besuchern dann noch etwas Gutes tun willst, dann versuche das Frameset zu eliminieren.
So long,
Martin
Hi,
Und wenn du dir und vor allem deinen Besuchern dann noch etwas Gutes tun willst, dann versuche das Frameset zu eliminieren.
sind es wirklich "vor allem" die Besucher, die vom Verzicht auf Frames profitieren? Ein Großteil davon wird - ordentlichen Code[1] vorausgesetzt - entweder nur wenig von Frames merken (zumindest solange bis ihnen die Site gefällt), oder aber sofort wieder verschwinden, weil sie nicht dem entspricht, was sie erwartet haben. Meiner Ansicht nach ist es vor allem der Webmaster bzw. Besitzer, der unter Frames zu leiden hat:
Müsste es also nicht "Und wenn Du Deinen Besuchern und vor allem Dir etwas Gutes tun willst" heißen?
Cheatah
[1] Soweit "ordentlicher Code" bei Frames möglich ist.
Hi,
Und wenn du dir und vor allem deinen Besuchern dann noch etwas Gutes tun willst, dann versuche das Frameset zu eliminieren.
sind es wirklich "vor allem" die Besucher, die vom Verzicht auf Frames profitieren? Ein Großteil davon wird - ordentlichen Code[1] vorausgesetzt - entweder nur wenig von Frames merken (zumindest solange bis ihnen die Site gefällt), oder aber sofort wieder verschwinden, weil sie nicht dem entspricht, was sie erwartet haben.
Nein, ich finde Frames auch als Nutzer schrecklich:
Wenn man z.B. http://www.computerbild.de/ mit einer 800x600-er Auflösung besucht, sind die Frames dort einfach schrecklich. Ich finde Frames vor allem immer dann doof, wenn irgendwo Scrollbalken gekürzt werden.
Versuch mal mit 800x600 durch dem Inhalt zu scrollen, einfach schrecklich!
Einen schönen Sonntag noch!
Hi Cheatah,
Und wenn du dir und vor allem deinen Besuchern dann noch etwas Gutes tun willst, ...
ich hatte diese Rangfolge durchaus mit Bedacht gewählt. Denn aus der Sicht des Webautors sehe ich durchaus den Vorteil von Frames, solange er keine Möglichkeit hat, auf Technologien wie SSI oder serverseitige Scriptsprachen zurückzugreifen. Und ich weiß aus eigener Erfahrung, dass das bei den Gratisangeboten, die die Zugangsprovider oft anbieten, und die der angehende Webdesigner meistens für die ersten Gehversuche nutzt, ein Wunschtraum bleibt. Viele bleiben dann bei Frames als Einstiegsdroge hängen, weil sie es eben nicht anders ken^H^Hönnen.
Nein, ich sehe die Nachteile von Frames tatsächlich in erster Linie auf Seiten der Nutzer.
* Gezieltes Setzen von Bookmarks wird erschwert
* Gezieltes Verlinken auf einzelne Inhalte wird erschwert (da Navi fehlt)
* Drucken der Seite wird erschwert (Alle Frames nacheinander? Nur aktiven
Frame? Bildschirmansicht?)
* Orientierung wird verschleiert, weil immer nur URL des Framesets in der
Adressleiste steht
* usw. usw.
sind es wirklich "vor allem" die Besucher, die vom Verzicht auf Frames profitieren?
Und selbst wenn nicht - die wären mir am wichtigsten. Um die Akzeptanz der Seite beim Publikum zu verbessern, sollte man IMHO ruhig selbst ein wenig seine eigene Bequemlichkeit hinten anstellen.
Ein Großteil davon wird - ordentlichen Code[1] vorausgesetzt - entweder nur wenig von Frames merken (zumindest solange bis ihnen die Site gefällt), oder aber sofort wieder verschwinden, weil sie nicht dem entspricht, was sie erwartet haben.
Zweifellos, ja.
Meiner Ansicht nach ist es vor allem der Webmaster bzw. Besitzer, der unter Frames zu leiden hat:
- Frames machen die Arbeit unnötig schwer.
"Schwer" im Sinne von "schwerer zu überblicken", ja. Aber sie fördern andererseits die Faulheit des Autors. Immer vorausgesetzt, er hat nicht die Möglichkeit, auf elegantere Lösungen (siehe oben) zurückzugreifen.
- Frames erhöhen den Traffic, teilweise auf ein Vielfaches.
- Durch Frames wird die Site nicht vernünftig gefunden.
- Um die Nachteile von Frames Stück für Stück auszugleichen, sind erhebliche Aufwände nötig. Die Folge davon verstärkt die meisten weiteren Nachteile noch weiter.
- Und letztlich geht jedes Leiden, das ein Besucher mit Frames hat, ein Stück weit auch an den Site-Besitzer zurück, weil er den Besucher verliert.
Ack.
Müsste es also nicht "Und wenn Du Deinen Besuchern und vor allem Dir etwas Gutes tun willst" heißen?
Nö, schon aus psychologischen Gründen nicht. Das würde unterstellen, dass ich meine eigenen Flitzen für wichtiger halte als die Wünsche meiner Besucher.
Ciao,
Martin
Hallo Martin,
Davon abgesehen hat die Einheit "px" in HTML-Attributen nichts verloren - sie ist da nicht nur überflüssig, sondern sogar falsch!
Ergänzung: Davon abgesehen hat die Einheit "px" in *den* HTML-Attributen *cols und rows* nichts verloren - sie ist da nicht nur überflüssig, sondern sogar falsch! In anderen Attributen schon. ;-)
freundl. Grüsse aus Berlin, Raik
Hallo Raik,
Ergänzung: Davon abgesehen hat die Einheit "px" in *den* HTML-Attributen *cols und rows* nichts verloren - sie ist da nicht nur überflüssig, sondern sogar falsch! In anderen Attributen schon. ;-)
nein, das stimmt nicht.
In CSS-Angaben *muss* eine Einheit, beispielsweise px, angegeben werden.
Bei Größenangaben in HTML-Attributen (die man, wenn immer möglich, sowieso zugunsten von CSS vermeiden sollte) ist px dagegen die Default-Einheit, wenn nicht '%' angegeben ist. Die *explizite* Angabe von px z.B. in width- oder height-Attributen ist schlicht falsch. Hier muss dann der reine Zahlenwert ohne Einheit stehen.
Ciao,
Martin
Hi,
nein, das stimmt nicht.
In CSS-Angaben *muss* eine Einheit, beispielsweise px, angegeben werden.
nein, das stimmt nicht.
In CSS-Längenangaben *muss* eine Einheit, beispielsweise px, angegeben werden, sofern es sich bei dem Längenwert nicht um 0 handelt.
Cheatah ;-)
Hallo,
In CSS-Längenangaben *muss* eine Einheit, beispielsweise px, angegeben werden, sofern es sich bei dem Längenwert nicht um 0 handelt.
Einverstanden. :-)
Ich vergesse oft, diesen Sonderfall zu erwähnen, weil ich selbst ihn nicht ausnutze. Auch beim Wert 0 (Null) setze ich immer dieselbe Einheit, die ich den restlichen Werten im gleichen Kontext auch gebe, also z.B. 'margin: 12px 0px;' anstatt 'margin: 12px 0'. Mir kommt das "ordentlicher" vor.
Ciao,
Martin
Hi,
Ich vergesse oft, diesen Sonderfall zu erwähnen,
es ging mir nicht nur um den Sonderfall, sondern auch darum, dass das Gesagte nur für <length> gilt. Bei z-index beispielsweise sind Einheiten aller Art falsch.
weil ich selbst ihn nicht ausnutze. Auch beim Wert 0 (Null) setze ich immer dieselbe Einheit, die ich den restlichen Werten im gleichen Kontext auch gebe, also z.B. 'margin: 12px 0px;' anstatt 'margin: 12px 0'. Mir kommt das "ordentlicher" vor.
Jupp, mache ich genauso.
Cheatah
Hallo, Der!
Ergänzung: Davon abgesehen hat die Einheit "px" in *den* HTML-Attributen *cols und rows* nichts verloren - sie ist da nicht nur überflüssig, sondern sogar falsch! In anderen Attributen schon.
nein, das stimmt nicht.
doch, dass es andere attribute gibt, in denen eine einheitsangabe _nicht_ falsch ist, das stimmt. und dass somit deine aussage sich zunächst mal nur auf "cols" und "rows" beziehen kann, auch.
In CSS-Angaben *muss* eine Einheit, beispielsweise px, angegeben werden.
Bei Größenangaben in HTML-Attributen (die man, wenn immer möglich, sowieso zugunsten von CSS vermeiden sollte) ist px dagegen die Default-Einheit, wenn nicht '%' angegeben ist. Die *explizite* Angabe von px z.B. in width- oder height-Attributen ist schlicht falsch. Hier muss dann der reine Zahlenwert ohne Einheit stehen.
nein, bei strict ist eine einheit vorgeschrieben. ohne funktioniert die wertzuweisung mit javascript garnicht.
deine aussage "Davon abgesehen hat die Einheit "px" in HTML-Attributen nichts verloren - sie ist da nicht nur überflüssig, sondern sogar falsch!" ist schlicht falsch, weil sie sich auf ALLE attribute bezieht.
freundl. Grüsse aus Berlin, Raik
Hi,
Ergänzung: Davon abgesehen hat die Einheit "px" in *den* HTML-Attributen *cols und rows* nichts verloren - sie ist da nicht nur überflüssig, sondern sogar falsch! In anderen Attributen schon.
nein, das stimmt nicht.
Nenne ein HTML-Attribut außer style, in dem die Maßeinheit px als solche zulässig ist.
nein, bei strict ist eine einheit vorgeschrieben. ohne funktioniert die wertzuweisung mit javascript garnicht.
Für CSS-Eigenschaften im style-Objekt.
Aber nicht für HTML-Attribute.
deine aussage "Davon abgesehen hat die Einheit "px" in HTML-Attributen nichts verloren - sie ist da nicht nur überflüssig, sondern sogar falsch!" ist schlicht falsch, weil sie sich auf ALLE attribute bezieht.
s.o. Nenne ein HTML-Attribut ...
cu,
Andreas