Runde Ecken mit <div>-Boxen?

[marcel]

Hallo Zusammen,
ich habe hier ein Beispiel, wie ich gerne meine Box gestalten möchte:
http://aktuell.de.selfhtml.org/tippstricks/css/runde_ecken/beispiel1.htm

Was mir an der Sache nicht so zusagt ist, dass sich die Grafiken nicht kacheln sondern einfach nur sehr groß sind und sich überschneiden.

hat jemand eine Idee, wie man es umsetzten kann, dass die Eck-Grafiken in den Ecken der Box dargestellt werden und sich die Grafiken zwischen den Eck-Grafiken jeweils horizontal und vertikal durchkacheln, so dass die Box beliebig in der Größe skalierbar bleibt?

Vielen Dank für jede Hilfe

[Joachim]

Hi,

hat jemand eine Idee, wie man es umsetzten kann, dass die Eck-Grafiken in den Ecken der Box dargestellt werden und sich die Grafiken zwischen den Eck-Grafiken jeweils horizontal und vertikal durchkacheln, so dass die Box beliebig in der Größe skalierbar bleibt?

Du koenntest die Box ralativ positionieren und die runden Ecken dann absolut ueber top, left, bottom und right positionieren. Entsprechende Abstaende oder Transparenzen muessten dafuer sorgen, das die Ecken nicht ueber den Inhalten liegen.

Gruesse, Joachim

[jup]

du musst mit mehrern div elementen arbeiten.

<div class="round">
  <div >-...
</div>

[Detlef G.]

Hallo marcel

Was mir an der Sache nicht so zusagt ist, dass sich die Grafiken nicht kacheln sondern einfach nur sehr groß sind und sich überschneiden.

Ohne überdeckende Grafiken funktioniert es nicht.
Auch bei gekachelten Kanten müssten die Ecken dann zusätzlich draufgesetzt
werden.

hat jemand eine Idee, wie man es umsetzten kann, dass die Eck-Grafiken in den Ecken der Box dargestellt werden und sich die Grafiken zwischen den Eck-Grafiken jeweils horizontal und vertikal durchkacheln, so dass die Box beliebig in der Größe skalierbar bleibt?

Du würdest doppelt so viele ineinandergeschachtelte Elemente benötigen und
doppelt so viele Grafiken.
Das halte ich aus mehreren Gründen für ungünstig:

• es werden noch mehr für den Inhalt unnötige Elemente verwendet
    (die Div-Suppe wäre endgültig perfekt)
• es müssen doppelt so viele Grafiken einzeln vom Server angefordert und
    geliefert werden (jeweils mit HTTP-Header)
• die größeren Grafiken, die selbst wiederholte Teile und große durchgehende
    Farbflächen enthalten, sind sehr gut komprimierbar, so dass die insgesamt
    übertragenen Datenmenge nicht größer sein muss, als bei vielen kleinen
    Einzelgrafiken
• manche Browser benötigen zur Anzeige vieler kleiner gekachelten Grafiken
    länger als für wenige große Grafiken
• inwieweit sich irgendwelche Browser bei zu vielen übereinandergelegten
    Hintergrundgrafiken verschlucken und mit Anzeigefehlern reagieren, habe
    ich noch nicht getestet (ich würde es auch nicht unbedingt drauf ankommen
    lassen)

Eine weitere _Un_lösung würde darin bestehen, die Kanten jeweils als
gekachelte Hintergrundbilder zu verwenden, die geschachtelten Elemente mit
position:relative zu versehen und die Eckgrafiken ins
HTML selbst zu schreiben und dann absolut zu positionieren.
Das sehe ich _nicht_ als Lösung an!
Der gröste Teil oben genannten Nachteile trifft hier auch zu, darüberhinaus
würden dann nicht nur bedeutungsleere Elemente zusätzlich ins HTLM
geschrieben sondern auch noch Grafiken, die nichts mit dem Inhalt des
Dokumentes zu tun haben, die nur Design sind.
In einem Browser, der CSS nicht vernünftig umsetzt, oder wenn die CSS-Datei
eventuell nicht ausgeleifert wird, hängen dann irgendwelche
zusammenhangslosen Ecken mitten im Browserfenster herum.

Auf Wiederlesen
Detlef

[Joachim]

Hi,

Eine weitere _Un_lösung würde darin bestehen, die Kanten jeweils als
gekachelte Hintergrundbilder zu verwenden, die geschachtelten Elemente mit
position:relative zu versehen und die Eckgrafiken ins
HTML selbst zu schreiben und dann absolut zu positionieren.

Ich glaube Du verwechselst hier was. Es geht nicht um Xml, sondern um html zur Erstellung von Websites. Websites dienen der Kommunikation, die _auch_ aus Design besteht. Wenn Daten und Design trennbar sind ist das gut. Wenn nicht, ist die Forderung nach Designverzicht nur um die Datenstruktur zu erhalten, Elfenbeinturmpolitik.

Wir bewegen uns hier schliesslich nicht in einem verlaesslichen Umfeld, sondern in einem, das von Webbrowesern mit mehr oder weniger unzulaenglichen Css-Faehigkeiten gepraegt wird. Nicht immer laesst sich da eine perfekte Struktur erreichen, wenn bestimmte Designvorgaben bestehen - und umgesetzt werden muessen.

Gruesse, Joachim

[Detlef G.]

Hallo Joachim

Ich glaube Du verwechselst hier was. Es geht nicht um Xml, sondern um html zur Erstellung von Websites.

Was soll das mit XML zu tun haben?
Oder meinst du HTML 2 kontra XML?  ;-)

Websites dienen der Kommunikation, die _auch_ aus Design besteht.

Durchaus, aber ...
(dazu gab es hier bereits viele Diskussionen)

Wenn Daten und Design trennbar sind ist das gut. Wenn nicht, ist die Forderung nach Designverzicht nur um die Datenstruktur zu erhalten, Elfenbeinturmpolitik.

Das ist in diesem Zusammenhang Nonsens.

1. Der OP fragte nach gekachelten Lösungen zu Runde Ecken mit CSS,
nicht allgemein zu runden Ecken.
Daraus schließe ich, dass es ihm um ein CSS-Lösung geht, nicht um HTML.
(man beachte auch die gewählte Rubrik)
2. Das Layout, welches der Browser bei vernünftig, logisch ausgezeichneten
HTML-Elementen ohne weitere autorenseitige Layout- oder Designvorgaben
als Standard verwendet, ist 100 mal besser, als ein total zerschossenes.
Das entsteht aber leicht, wenn verschiedenen Designelemente und
Layoutvorgaben, die sich gegenseiteig bedingen zum Teil im HTML und zum
anderen Teil im CSS definiert sind.

Den Teil dazu hast du ja nicht zitiert:

In einem Browser, der CSS nicht vernünftig umsetzt, oder wenn die CSS-Datei
eventuell nicht ausgeliefert wird, hängen dann irgendwelche
zusammenhangslosen Ecken mitten im Browserfenster herum.

Wir bewegen uns hier schliesslich nicht in einem verlaesslichen Umfeld, sondern in einem, das von Webbrowesern mit mehr oder weniger unzulaenglichen Css-Faehigkeiten gepraegt wird.

Genau darum geht es mir doch!
Voneinander abhängige Teile des Desing einer Seite sollten nicht auf
verschiedene Techniken aufgeteilt werden.

(Genauso, wie Links auf einer Seite, die ausschließlich Javascriptfunktionen
starten, auch nur bei aktiviertem Javascript angezeigt werden sollten.)

Entweder eine CSS- oder eine HTML-Lösung (wenn das Layout unbedingt in alten
Browsern eingehalten werden soll), nicht eine wilde Mischung zwischen
beiden.

Auf Wiederlesen
Detlef

[marcel]

Hallo und Danke für eure Posts.
Ich möchte nur einen Lösung finden, wie ich ein gleiches Ergebniss erziehle wie im Beispiel, nur dass ich keine übergroßen Grafiken verwende.
Die Grafiken für die Ecken sollen nicht gekachelt werden, sondern nur  eine Grafik für die obere Kante der Box, die zwischen den oberen Ecken kachelt.
Die untere Kante und die linke - und rechte Kante sollen entspechent auch gekachelt werden.

Ich hab sowas bis jetzt immer nur mit Tabellen gelöst, suche aber jetzt nach eine Lösung mit <div>'s.

Für ein Beispiel oder einen kurze Anleitung wäre ich sehr sehr dankbar.

Gruß Marcel

[Detlef G.]

Hallo marcel

Hallo und Danke für eure Posts.

Sorry, dass wir in dieser Grundsatzdiskussion landeten.

Ich möchte nur einen Lösung finden, wie ich ein gleiches Ergebniss erziehle wie im Beispiel, nur dass ich keine übergroßen Grafiken verwende.

Wie groß müssten diese übergroßen Grafiken werden?

Wie ich bereits schrieb, ist in einem großen Bereich die Veriante mit den
übergroßen Grafiken effektiver als eine mit vielen kleinen.

Die Grafiken für die Ecken sollen nicht gekachelt werden, sondern nur  eine Grafik für die obere Kante der Box, die zwischen den oberen Ecken kachelt.

Dazwischen kacheln geht nicht, du kannst für jedes Element nur _ein_
Hintergrundbild angeben, welches du dann ganz nach deinem Wunsch
positionieren und in die von dir gewünschte Richtung kacheln lassen kannst.

Du brauchst also vier inneinanderverschachtelte Elemente nur zur Anzeige der
Kanten.

Auf Wiederlesen
Detlef

[Joachim]

Hi,

Für ein Beispiel oder einen kurze Anleitung wäre ich sehr sehr dankbar.

Was genau hast Du denn an dem Loesungsvorschlag nicht verstanden, bei dem ein Div relativ, und die runden Eck-Bildchen absolut positioniert werden? Den Hintergrund Deines Divs kanst Du dann nach Belieben kacheln oder tapezieren, die Ecken sitzen immer da wo sie sollen, egal wie gross das Div ist

<div style="position:relative;background-image:url(alles_kacheln.gif)">
    <p>inhalt</p>
    <p>mehr Inhalt</p>
    <img src="ecke1" style="position:absolute:top:0;left:0">
    <img src="ecke2" style="position:absolute:top:0;right:0">
    <img src="ecke3" style="position:absolute:bottom:0;left:0">
    <img src="ecke4" style="position:absolute:bottom:0;right:0">
</div>

(Mein geschaetzter Diskussionspartner Detlef wuerde die Grafiken nicht direkt positionieren, sondern als Hintergrundgrafiken in containern anlegen, was technisch gesehen aehnlich aufgebaut ist.)

Gruesse, Joachim

[Joachim]

Hi,

Wenn Daten und Design trennbar sind ist das gut. Wenn nicht, ist die Forderung nach Designverzicht nur um die Datenstruktur zu erhalten, Elfenbeinturmpolitik.

Das ist in diesem Zusammenhang Nonsens.

Nein. Es ist im Gegenteil die zentrale Frage: soll/darf getrickst werden, um bestimmte Designziele zu erreichen.

Daraus schließe ich, dass es ihm um ein CSS-Lösung geht, nicht um HTML.

Weswegen er als Thema sicher "Html" gewaehlt hat ;-)

2. Das Layout, welches der Browser bei vernünftig, logisch ausgezeichneten
   HTML-Elementen ohne weitere autorenseitige Layout- oder Designvorgaben
   als Standard verwendet, ist 100 mal besser, als ein total zerschossenes.

Was sollen solche Allgemeinplaetze? Wer ist "der Browser"? Logisch ausgezeichnetes Html ist noch sehr lange kein Design, auch wenn Strukturfetischisten es bisweilen dafuer halten moegen. Zerschossenes Design ist _natuerlich_ schlecht - aber nicht automatisch die Folge von nicht perfekt ausgezeichnetem html.
Das Ergebniss von korrektem html und css kann in Folge mangelnder Css-Faehigkeit aber ebensogut zu zerschossenen Darstellung fuehren - auch bei neueren Browsern.

Entweder eine CSS- oder eine HTML-Lösung (wenn das Layout unbedingt in alten
Browsern eingehalten werden soll), nicht eine wilde Mischung zwischen
beiden.

Jetzt wirds wirr. Wie machst Du eine Css-Loesung _ohne_ html? Da gibt es fuer mich nichts zu trennen. Ich sehe hier lediglich einen Prozess der Annaeherung an das Ideal, zumal - wie erwaehnt - Css Loesungen nicht unbedingt in _allen_ neuen Browsern klaglos angezeigt werden. Hacks werden auch in Zukunft noetig sein. Das spricht aber nicht dagegen, wo immer moeglich mit Css zu arbeiten.
In keinem Falle lassen sich Fehldarstellungen zu 100% vermeiden. Lieber aber riskiere ich fehlplazierte runde Ecken (welcher moderne Browser kann nicht per Css positionieren?) als die Selbstbeschraenkung auf den kleinsten gemeinsamen Nenner Struktur pur.

Gruesse, Joachim

[Detlef G.]

Hallo Joachim

Das ist in diesem Zusammenhang Nonsens.

Ich glaube, wir reden etwas anneinander vorbei.
Mit "in diesem Zusammenhang" bezog ich mich weniger auf das grundsätzliche
Problem des OP. Ich meinte damit meinen Hinweis auf die oft ungünstige
Aufteilung von Designelementen und Formatangaben zwischen HTML und CSS.

Nein. Es ist im Gegenteil die zentrale Frage: soll/darf getrickst werden, um bestimmte Designziele zu erreichen.

Leider _muss_ oft getrickst werden. Auch das inneinanderschachteln mehrere
Elemente um das gewünschte Design zu erhalten ist bereits eine Trickserei.

Weswegen er als Thema sicher "Html" gewaehlt hat ;-)

Ups, wer lesen kann ... ;-)

Was sollen solche Allgemeinplaetze? Wer ist "der Browser"?

In diesem Fall jeder Browser, selbst Lynx.

Logisch ausgezeichnetes Html ist noch sehr lange kein Design, auch wenn Strukturfetischisten es bisweilen dafuer halten moegen.

Doch, es ist das Standarddesign bzw. -layout des verwendeten Browsers.
Das hat vielleicht keine Ähnlichkeit mit dem von mir Gewünschten, sorgt aber
bei vernünftig strukturiertem HTML dafür, dass zumindest die textlichen
Inhalte der Seite problemlos erfasst werden können und diese benutzbar ist.

Zerschossenes Design ist _natuerlich_ schlecht - aber nicht automatisch die Folge von nicht perfekt ausgezeichnetem html.

Natürlich nicht, es gibt noch viel mehr Fehlermöglichkeiten.

Das Ergebniss von korrektem html und css kann in Folge mangelnder Css-Faehigkeit aber ebensogut zu zerschossenen Darstellung fuehren - auch bei neueren Browsern.

Ja, sollte dies sollte ich aber versuchen zu vermeiden und nicht zusätzlich
provozieren.

Entweder eine CSS- oder eine HTML-Lösung (wenn das Layout unbedingt in alten
Browsern eingehalten werden soll), nicht eine wilde Mischung zwischen
beiden.
Jetzt wirds wirr. Wie machst Du eine Css-Loesung _ohne_ html?

Oh, ich glaube, hier _wolltest_ du mich falsch verstehen. ;-)

Ich meinte natürlich für das Design der Seite.
Selbsverständlich ist die Grundlage immer eine HTML-Seite.
Dann stellt sich aber die Frage, wieweit abwärskompatibel das Design sein
soll. Ist es nötig, dieses für ältere Browser vollständig umzusetzen, oder
reicht es, wenn die Seite in diesen les- und benutzbar ist.
Davon hängt es dann ab, wie die Seite aufgebaut wird,
ganz ohne CSS (hoffenlich wohl nie mehr) oder ob zu dem vollständigen
CSS noch ein light-CSS, einfacheres Design für ältere Browser, dazukommt.

Ich sehe hier lediglich einen Prozess der Annaeherung an das Ideal, zumal - wie erwaehnt - Css Loesungen nicht unbedingt in _allen_ neuen Browsern klaglos angezeigt werden. Hacks werden auch in Zukunft noetig sein. Das spricht aber nicht dagegen, wo immer moeglich mit Css zu arbeiten.

Habe ich etwas anderes behauptet?

In keinem Falle lassen sich Fehldarstellungen zu 100% vermeiden.

Leider, man muss sie aber nicht provozieren.

Lieber aber riskiere ich fehlplazierte runde Ecken ...

Riskieren und bewusst in Kauf nehmen sind aber noch zwei verschiedene
Sachen.

... (welcher moderne Browser kann nicht per Css positionieren?)

Wohl keiner, was ist aber mit älteren Browsern oder einem Fehler beim
Ausliefern der CSS-Datei?

... als die Selbstbeschraenkung auf den kleinsten gemeinsamen Nenner Struktur pur.

Habe ich das gesagt?

Zu unserem Beispiel:
Es soll ein Bereich mit runden Ecken und speziellen Bordern angezeigt
werden.

Entweder ich bastel eine Tabellenkonstruktion, die dies auch in
Uraltbrowsern so anzeigt, oder ich setze dies mittels CSS um.

Meine Meinung ist nun, wenn ich die CSS-Variante wähle, dann ist es dazu
zwar meist unvermeidlich, zusätzliche Elemente zu verwenden.
Diese Elemente sollten dann aber so sparsam wie möglich eingesetzt und ohne
CSS auch nicht sichtbar sein.

Nun nocheinmal zu deinem Vorschlag:
Wenn es in dieser Art umgesetzt werden sollte, dann würde ich statt der
Eckgrafiken eher noch ein paar leere <span> ins HTML schreiben.
Diese könnten dann mit display:block, den Maßen und der Eckgrafik als
Hintergrundbild versehen in die Ecken positioniert werden.

(Ich wollte eigentlich keine neue Grandsatzdiskussion anzetteln.)

Auf Wiederlesen
Detlef

[marcel]

Hallo nochmal,
ich bekomms einfach nicht gebacken.
Wäre denn einer so nett und würde mir mal kurz zeigen, wie ich folgendes  HTML mit <div>'s umsetzten kann, sodass sich die Box beliebig skalieren lässt?:

<table width="167" border="0" cellspacing="0" cellpadding="0">
  <tr>
    <td width="11" height="36" rowspan="2"><img src="oben_links.gif" width="11" height="36" alt="" /></td>
    <td width="145" height="18" align="center" valign="bottom" style="background-image:url(oben_mitte.gif)">Überschrift</td>
    <td width="11" height="36" rowspan="2"><img src="oben_rechts.gif" width="11" height="36" alt="" /></td>
  </tr>
  <tr>
    <td width="11" style="background-image:url(mitte_links.gif)"></td>
    <td width="145" bgcolor="#F9F9F9">Inhalt</td>
    <td width="11" style="background-image:url(mitte_rechts.gif)"></td>
  </tr>
  <tr>
    <td width="11" height="16"><img src="unten_links.gif" width="11" height="16" alt="" /></td>
    <td width="145" height="16" style="background-image:url(unten_mitte.gif)"></td>
    <td width="11" height="16"><img src="unten_rechts.gif" width="11" height="16" alt="" /></td>
  </tr>
</table>

Vielen Dank.