nicht angemeldet
Rahmen mit abgerundeten Ecken
Hallo,
ich kämpfe mich hier schon seit Stunden ab und kriege irgendwie keine richtige Idee. Wie kann ich einen Rahmen mit abgerundeten Ecken um eine Webseite legen? Einfach nur ne blaue linie mit 2pt Stärke?
Am besten wäre es, ihn oben auch noch offen zu haben, also wie ein U, weil von oben ein Frame kommen soll. Man könnte auch ohne Frame auskommen, wenn es eine Möglichkeit gäbe, am oberen Bildschirmrand einen Streifen von ca 70px Höhe zu fixieren. Da sollen auch Buttons rein. Geht das auch mit einen DIV mit fester/absoluter Position? Das darf aber nicht mitscrollen.
Irgendwie weiß ich jetzt gar nicht mehr, was eigentlich in den Browsern funktioniert. Ich hatte gehofft position:fixed wäre richtig.
LG
Chris
-
Hallo, Chris,
ich kämpfe mich hier schon seit Stunden ab und kriege irgendwie keine richtige Idee. Wie kann ich einen Rahmen mit abgerundeten Ecken um eine Webseite legen? Einfach nur ne blaue linie mit 2pt Stärke?
CSS2 sieht so etwas nicht vor, du müsstest also die konventionelle Variante verwenden, welche vorsieht, dass eine Tabelle mit drei Zeilen a drei Spalten in den Zellen an den Ecken Grafiken enthält, welche den Effekt der Abrundung erzielen, siehe http://www.drweb.de/html/tabellen_7.shtml.
Für NS6+/Mozilla könntest du die CSS-Eigenschaft -moz-border-radius verwenden, siehe http://selfsuche.teamone.de/cgi-bin/such.pl?suchausdruck=moz-border-radius&lang=on&feld=alle&index_4=on&hits=50 oder Google oder Google Groups oder (...). Das müsste sich AFAIK auf das html- oder body-Element anwenden lassen, nur in nicht geckoiden Browsern wird halt ein Rahmen mit gewöhnlichen 90°-Ecken angezeigt.Übrigens ist die Einheit pt nur für den Druckbereich, nicht aber für auf Bildschirmpräsentation hin gestylten Hypertext passend.
Am besten wäre es, ihn oben auch noch offen zu haben, also wie ein U, weil von oben ein Frame kommen soll. Man könnte auch ohne Frame auskommen, wenn es eine Möglichkeit gäbe, am oberen Bildschirmrand einen Streifen von ca 70px Höhe zu fixieren. Da sollen auch Buttons rein. Geht das auch mit einen DIV mit fester/absoluter Position? Das darf aber nicht mitscrollen.
Ja.
.oO(Och, was ich mich freue, dass ein Benutzerstylesheet position:fixed wunderbar einfach aufheben kann. Das wird ja zum richtigen Dauerbrenner hier, wo man endlich begriffen hat, dass man Frames nicht gewachsen ist; jetzt wechselt man einfach von Frames auf position:fixed, als wäre es der Nonplusultraersatz, ohne sich mit dem Grundlegenden auseinandergesetzt zu haben...)Irgendwie weiß ich jetzt gar nicht mehr, was eigentlich in den Browsern funktioniert. Ich hatte gehofft position:fixed wäre richtig.
Ja, der MSIE/Win versteht position:fixed nicht. Das Thema wird hier mehrmals täglich durchgekaut (in der Hitliste der FAQ kurz hinter "soll man noch für alte Browser schreiben?????").
Schau mal nebenan </?m=151660&t=27934>, da werden gerade einmal wieder die Links zu IE-Workarounds gepostet.
Oder im Archiv... http://forum.de.selfhtml.org/archiv/2002/10/26068/#m142604.Mathias
-
Hi Mathias,
Danke, das hilft mir schon ein gaaanzes Stück weiter. Irgendwie hätte ich mit den Tabellen ja auch selbst drauf kommen können. Man wird alt.
Ja, der MSIE/Win versteht position:fixed nicht. Das Thema wird hier mehrmals täglich durchgekaut (in der Hitliste der FAQ kurz hinter "soll man noch für alte Browser schreiben?????").
Schau mal nebenan </?m=151660&t=27934>, da werden gerade einmal wieder die Links zu IE-Workarounds gepostet.
Oder im Archiv... http://forum.de.selfhtml.org/archiv/2002/10/26068/#m142604.Na, das funktioniert ja eben nicht. Ich hatte das auch mitgelesen.
LG
Chris-
Hallo.
Schau mal nebenan </?m=151660&t=27934>, da werden gerade einmal wieder die Links zu IE-Workarounds gepostet.
Na, das funktioniert ja eben nicht. Ich hatte das auch mitgelesen.Ich würde dir gerne weiterhelfen, wenn du vielleicht ein wenig näher ausführen würdest, *was* du genau probiert hast und *welche* *Fehler* aufgetreten sind, ob du schon Versuche unternommen hast, die Fehlerquelle zu lokalisieren; und bitte liefere alle relevanten Daten mit (z.B. verwendete Browser), sodass ich/wir/man das Problem untersuchen können, am besten poste ein kleines Stück Code, in welchem du den Fehler vermutest oder du lädst eine Testseite hoch, auf welcher der Fehler auftritt.
"Warum sollte ich eine möglichst exakte Problembeschreibung vornehmen?" - </faq/#Q-07b>
Mathias
-
Hi,
na so ungefähr der Reihenfogle nach.
Ich heb ein DIV mit einem Rahmen versehen. Das klappt ja.
Dann habe ich versucht, vier Gifs in den Ecken des Rahmens zu verankern. mit position:absolute; top:ypx; left:xpx;Nun ist das ja aber so, dass der Text im Rahmen mehr oder weniger werden kann und das DIV dadurch länger wird. Die GiFS unten sind dann aber stehen geblieben. Und eine Relative Positionierung vom unteren Rand habe ich nicht gefunden, oder geht das?
Die Sache mit der Tabelle gefällt mir noch am besten. Da kenn ich mich wenigstens einigermaßen aus.
LG
Chris
-
Hi Chris,
Ich heb ein DIV mit einem Rahmen versehen. Das klappt ja.
Dann habe ich versucht, vier Gifs in den Ecken des Rahmens zu verankern. mit position:absolute; top:ypx; left:xpx;mit absoluter Positionierung nimmst du die Bilder aus dem Dokumentenfluss und brockst dir damit...
Nun ist das ja aber so, dass der Text im Rahmen mehr oder weniger werden kann und das DIV dadurch länger wird. Die GiFS unten sind dann aber stehen geblieben.
...dieses Problem ein.
Und eine Relative Positionierung vom unteren Rand habe ich nicht gefunden, oder geht das?
Nicht mit absoluter Positionierung, wie der Name schon sagt ;) Aber du kannst die Bilder ja an das Ende der Seite (im Quelltext!) setzen und dort dann links und rechts positionieren.
Die Sache mit der Tabelle gefällt mir noch am besten. Da kenn ich mich wenigstens einigermaßen aus.
Tabellen sind *pfui*, wenn sie für das Layout missbraucht werden. Hier findest du eine saubere CSS-Lösung für dein Problem:
http://albin.net/CSS/roundedCorners/
http://albin.net/CSS/roundedCorners/examples.htmlLG Orlando
-
Hi Orlando,
http://albin.net/CSS/roundedCorners/
http://albin.net/CSS/roundedCorners/examples.htmlDer Tipp ist gut. Danke
Chris
-
-
-
-
-
hi molily
.oO(Och, was ich mich freue, dass ein Benutzerstylesheet position:fixed wunderbar einfach aufheben kann. Das wird ja zum richtigen Dauerbrenner hier, wo man endlich begriffen hat, dass man Frames nicht gewachsen ist; jetzt wechselt man einfach von Frames auf position:fixed, als wäre es der Nonplusultraersatz, ohne sich mit dem Grundlegenden auseinandergesetzt zu haben...)
das ging schnell. grad vor ner stunde hab ichs eingebaut, und schon ist es out :)
schö stefan -
Hallo,
keine "ich-will-jetzt-eine-Grundsatzdiskusion"-Frage sondern ein wirkliche "hab-ich-was-bisher-übersehen?"-Frage ;-): auf was beziehen sich Deine Bedenken bei:
.oO(Och, was ich mich freue, dass ein Benutzerstylesheet
position:fixed wunderbar einfach aufheben kann.(...)
jetzt wechselt man einfach von Frames
auf position:fixed, als wäre es der Nonplusultraersatz, ohne sich
mit dem Grundlegenden auseinandergesetzt zu haben...)Chräcker
-
Hi Chräcker,
auf was beziehen sich Deine Bedenken bei:
jetzt wechselt man einfach von Frames
auf position:fixed, als wäre es der Nonplusultraersatz, ohne sich
mit dem Grundlegenden auseinandergesetzt zu haben...)position:fixed sollte nicht nur als Frame-Ersatz angesehen werden. Es gilt dabei zu beachten, dass die fixierten Bereiche nicht zu groß werden und zu viel Platz in der Seite einnehmen.
LG Orlando
-
Hallo, Chräcker,
keine "ich-will-jetzt-eine-Grundsatzdiskusion"-Frage sondern ein wirkliche "hab-ich-was-bisher-übersehen?"-Frage ;-)
Grundsätzlich ist die Diskussion schon, in einer bestimmten Art und Weise...
auf was beziehen sich Deine Bedenken bei:
.oO(Och, was ich mich freue, dass ein Benutzerstylesheet
position:fixed wunderbar einfach aufheben kann.(...)
jetzt wechselt man einfach von Frames
auf position:fixed, als wäre es der Nonplusultraersatz, ohne sich
mit dem Grundlegenden auseinandergesetzt zu haben...)Im Grunde genommen ;) ist es mit der richtigen Verwendung von position:fixed nicht anders als mit der richtigen Verwendung von Frames - sie muss nachvollziehbar sein und es muss ein tatsächlicher Bedienungsvorteil für den Benutzer offensichtlich sein, erst dann ist sie sinnvoll - wo die Anwendung von Frames/position:fixed gerechtfertigt ist, beurteilt jeder natürlich anders, mir würde es ausreichen, wenn der Netzautor überhaupt darüber reflektieren würde. Ich freue mich, dass Frames zugunsten von CSS-Layout aufgegeben werden, weil damit schlagartig viele Probleme aus der Welt geschafft werden, da CSS-Layout immer eine Trennung von Inhalt und Präsentation zur Folge hat, womit die Diskussion um die Zugänglichkeitsbarrieren durch Frames ein Ende hat, da das Dokument ohne CSS vollwertig ist. Mir macht es jedoch Angst, dass die jetzige schon vorhandene zweifelhafte Anwendung von Frames eins zu eins mit position:fixed nachgebaut wird, ohne dass man sich die (ja, grundsätzliche ;)) Frage stellt, warum man etwas fest positionieren will und ob das Layoutelement überhaupt von seiner Funktion her dazu prädestiniert ist. Ich finde weiterhin "konventionell" mitscrollende Bedienelemente nicht weniger benutzbar als eine fest positionierte Navigation, welche womöglich ein Viertel des Bildschirms einnimmt. Dem Benutzer ist die Webseite als "Montagefläche", die wie ein Bild gescrollt werden kann, gut bekannt, aus diesem Grund gilt es abzuwägen, ob man diese verständliche Darstellung und die daraus erwachsene intuitive Bedienung zugunsten eines "Gucklochs" bzw. Sichtfensters auf den scrollenden Inhalt aufgibt.
Wenn man also position:fixed als Ersatz für Frames einsetzen möchte, hieße das in vielen Fällen, erst einmal die schrottigen, überflüssigen und hochkomplexen Framelayouts zu destruieren, um eine benutzbare, völlig neue Seitenstruktur zu erstellen, welche durchaus position:fixed sinnvoll einsetzen kann. Nur wenn man schon Frames nicht sparsam und mit Bedacht eingesetzt hat, hat eine zweifelhafte Anwendung von position:fixed im Vergleich zu einer zweifelhaften Anwendung von Frames nur wenige Vorteile...
Wie Orlando schon sagt, können fest positionierte Bereiche den Benutzer auch ungemein einschränken, siehe auch http://www.jendryschik.de/wsdev/css/fixed/#abneigung.IMHO kommen die meisten Netzautoren nicht umhin, eine völlig neue Navigation sich auszudenken, wenn sie von Frames auf CSS-Layout umsteigen, ob position:fixed oder nicht ist in dem Falle erst einmal irrelevant. Ich habe mich schon oft zu den Navigationsdefiziten von Frames geäußert und wie man sie "immanent" kompensieren könnte, in Anbetracht eines frametypischen Projektaufbaus, welcher - wenn man von JavaScript-Lösungen absieht - immer nur eine statische Primärnavigation bieten kann, ist es unmöglich, die Navigationsstruktur unverändert in ein CSS-Layout umzuwandeln.
Unter dem Strich wollte ich nur sagen, dass jede Technik einer gewissenhaften Anwendung bedarf, es ist ganz trivial... ;) Mit anderen Layouttechniken kann man genauso viele Fehler machen, nur position:fixed taucht hier in letzter Zeit sooft als der hochmoderne und modische "Ersatz von Frames" auf, aber eigentlich haben Frames und position:fixed nur eine einzige Gemeinsamkeit, nämlich dass sich Bereiche fest positionieren lassen.
Bitte nicht falsch verstehen, ich nicht nicht "FÜR" oder "GEGEN" position:fixed. ;) "Legen Sie Ihr Geld in dada an!" http://www.peak.org/~dadaist/Deutsch/Graphiken/legen.html... oder wahlweise http://home.t-online.de/home/dj5nu/lit-nonsens.html... ich komme vom Thema ab.
Mathias
-
Hallo,
und Danke! ....und eigendlich vollkommen Deiner Meinung. (Die "Diferenzen" sind dann eben eher Wertungsnuancen....)
Chräcker
-
-
-