CSS Problem

[Lux]

Hallo,

gibt es die Möglichkeit, in einer Bilderliste die Bildüberschrift in den Bildrahmen zu integrieren?

Beispiel:

HTML:

<figure>
<a href="showimage.php?id=563e23a4482a9" target=blank><img class="my_image" src="pfad/zu/image/th_563e23a447faf_4438.jpg" alt="thumb" /></a>
<figcaption>sea takimata sanctus est Lorem ipsum dolor sit amet. Loremo.</figcaption>
</figure>

CSS:

.my_image {
background: #f5f5f5;
border-top: 8px solid #FFF;
border-right: 8px solid #FFF;
border-bottom: 40px solid #FFF;
border-left: 8px solid #FFF;
border-radius: 5px;
-moz-border-radius: 5px;
-webkit-border-radius: 5px;
box-shadow: 1px 2px 4px rgba(0,0,0,.4);
margin-top:10px; 
margin-left:0px; 
margin-bottom:10px; 
margin-right:10px;
}

Gruß, Lux

[MrMurphy1]

Hallo,

deine Informationen sind leider noch recht mager. Außerdem schreibst du von einer Bilderliste, dein Quelltext enthält aber nur ein Bild. Deshalb ist nicht ersichtlich wie du mehrere Bilder in den Quelltext einfügen möchtest.

Aus dem Bauch raus würde ich erst mal vorschlagen, die Klasse my_image statt auf img auf figure anzuwenden und zusätzlich ein display:block hinzuzufügen.

figcaption wird per text-align:center zentriert.

Fertig.

Gruss

MrMurphy

[Gunnar Bittersmann]

@@Lux

gibt es die Möglichkeit, in einer Bilderliste die Bildüberschrift in den Bildrahmen zu integrieren?

Dan Rahmen nicht img geben, sondern figure.

figcaption absolut positionieren. Damit sich die Positionierung auf figure bezieht, dieses relativ positionieren.

Beispiel:

Nächstes Mal: Online-Beispiel, bitte.

LLAP 🖖

[Lux]

@@Lux

gibt es die Möglichkeit, in einer Bilderliste die Bildüberschrift in den Bildrahmen zu integrieren?

Dan Rahmen nicht img geben, sondern figure.

figcaption absolut positionieren. Damit sich die Positionierung auf figure bezieht, dieses relativ positionieren.

Hm, ich habs jetzt genau umgekehrt gemacht. Den Rahmen habe ich beim image gelassen, dann figure relative positioniert und figcapture absoilut. So steht die Schrift innerhalb des Rahmens und sobald es mehr Schrift wird, wandert sie nach oben, notfalls bis ins Bild hinein.

Sieht im moment gut aus, gibt es hiergegen Einwände (z.b. das es in manchen Browsern nicht läuft oder so)?

Relatively position the figure so we can absolutely position the caption over the photo

.my_image {
background: #f5f5f5;
border-top: 8px solid #FFF;
border-right: 8px solid #FFF;
border-bottom: 60px solid #FFF;
border-left: 8px solid #FFF;
border-radius: 5px;
-moz-border-radius: 5px;
-webkit-border-radius: 5px;
box-shadow: 1px 2px 4px rgba(0,0,0,.4);
margin-top:10px; 
margin-left:0px; 
margin-bottom:10px; 
margin-right:10px;
}


figure {
  position: relative;

}

figcaption {
  position: absolute;
  bottom: 15px;
  left: 8px;
  padding: 20px;

}

[MrMurphy1]

Hallo

gibt es hiergegen Einwände (z.b. das es in manchen Browsern nicht läuft oder so)?

Es ist schlicht schlechter Stil position:absolute ohne zwingenden zu verwenden.

Die Probleme kommen meist später wenn die Seite komplexer oder responsive wird.

Gruss

MrMurphy

[Lux]

Es ist schlicht schlechter Stil position:absolute ohne zwingenden zu verwenden.

Na aber das hat Gunnar doch auch vorgeschlagen.

Die Probleme kommen meist später wenn die Seite komplexer oder responsive wird.

Genau daher meine Nachfrage...

[MrMurphy1]

Hallo,

hast du deine Lösung mal mit verschiedenen Bildgrößen (deutlich kleiner und deutlich größer) ausprobiert? Und mit responsive Design?

Hast du dir überhaupt mal Gedanken gemacht, was es für Auswirkungen hat, wenn Elemente mittels position:absolute "aus dem Textfluss" genommen werden?

Viel Spaß dabei.

Gruss

MrMurphy

[Lux]

Hallo,

hast du deine Lösung mal mit verschiedenen Bildgrößen (deutlich kleiner und deutlich größer) ausprobiert? Und mit responsive Design?

Die Bilder durchlaufen allesamt ImageMagick und werden dort auf dieselbe Größe gebracht. In Sachen Responsive Design habe ich bisher nur verschiedene Viewportgrößen ausprobiert.

Lux

[Sara]

Hallo,

Na aber das hat Gunnar doch auch vorgeschlagen.

Nur weil Gunnar das sagt, muss es nicht die beste Lösung sein :))

[Gunnar Bittersmann]

@@Sara

Nur weil Gunnar das sagt, muss es nicht die beste Lösung sein :))

:-) Natürlich nicht.

Und genauso, wie ich nicht-beste (lies: schlechte) Lösungen von anderen anpr^W kritisiere, erwarte ich das andersrum auch.

LLAP 🖖

[Gunnar Bittersmann]

@@Lux

border-top: 8px solid #FFF;
border-right: 8px solid #FFF;
border-bottom: 40px solid #FFF;
border-left: 8px solid #FFF;

Die viermalige Wiederholung von border-style und border-color ist nicht das, was man tun sollte, sondern jede Angabe genau einmal tätigen.

Besser:

border: 8px solid #FFF;
border-bottom-width: 40px;

oder

border-style: solid;
border-color: #FFF;
border-width: 8px 8px 40px 8px;

(Reihenfolge: oben–rechts–unten–links)

border-radius: 5px;
-moz-border-radius: 5px;
-webkit-border-radius: 5px;

Die Präfixe sind Unsinn. Sämtliche relevanten Browser haben border-radius präfixfrei.

box-shadow: 1px 2px 4px rgba(0,0,0,.4);

Schatten erfordern einigen Rechenaufwand. Wenn da noch Transparenz hinzukommt …

Transparenz sollte bei gut gewählten Werten für blur radius und spread distance (3. und 4. Längenangabe) aber nicht erforderlich sein.

margin-top:10px; 
margin-left:0px; 
margin-bottom:10px; 
margin-right:10px;

Kurz:

margin: 10px 0 10px 10px;

(Reihenfolge: oben–rechts–unten–links)

LLAP 🖖

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Schatten erfordern einigen Rechenaufwand. Wenn da noch Transparenz hinzukommt …

Transparenz ist bei Schatten (wenn’s keine harten sind) aber wohl schon längst da, so dass eine Farbangabe in RGBA das womöglich auch nicht mehr schlimmer macht.

LLAP 🖖

[Orlok]

Hallo Gunnar

Schatten erfordern einigen Rechenaufwand. Wenn da noch Transparenz hinzukommt …

Transparenz ist bei Schatten (wenn’s keine harten sind) aber wohl schon längst da, so dass eine Farbangabe in RGBA das womöglich auch nicht mehr schlimmer macht.

Ich glaube, wenn hier hinsichtlich der Performance etwas problematisch werden könnte, dann eher die Verbindung von box-shadow mit border-radius.

Schatten in Verbindung mit Transparenz werden meines Wissens nach eigentlich erst dann wirklich zum Problem, wenn die Schatten in Abhängigkeit von einer Lichtquelle dynamisch auf mehreren Objekten abgebildet werden sollen.

Allgemein gesprochen ist der Grund dafür, dass korrektes Blending zunächst einmal erfordert, dass die Objekte in einer bestimmten Reihenfolge gerendert, sprich, in den Drawing Buffer geschrieben werden, nämlich von hinten nach vorne.

Die Berechnung der Schatten wiederum erfolgt (zumindest in der Regel) durch Multi Pass Rendering, das heißt es wird in einem ersten Schritt analog zur klassischen Verdeckungsberechnung mit der Lichtquelle als point of view die Entfernung zu einem Objekt auf der Z-Achse ermittelt.

Diese wird dann in einer sogenannten Shadow Map zwischengespeichert, bevor schließlich beim eigentlichen Zeichnen anhand der so hinterlegten Werte geprüft wird, ob und wenn ja welche Teile der Oberfläche eines Objektes im Schatten liegen.

Dabei ist dann natürlich ebenfalls die Reihenfolge von Bedeutung, in welcher die Objekte gerendert werden, weshalb letztlich die Verbindung dieser beiden Techniken aufwändige Rechenoperationen erforderlich machen kann.

Im Gegensatz dazu werden mit box-shadow erzeugte Schatten aber wohl als eigenständige Objekte gerendert, deren Eigenschaften nicht durch die relative Position zu einer Lichtquelle sondern durch die angegebenen und berechneten Werte bestimmt werden, so dass die beschriebene Problematik hier eigentlich keine Rolle spielen dürfte.

Die Darstellung eines border-radius andererseits erfordert eine Menge Vertices, sowohl bei der eigentlichen Box als auch beim Schatten, weshalb ich mir vorstellen könnte, dass großvolumige und vor allem weiche Schatten in Verbindung mit dieser Eigenschaft und bei entsprechendem Reflow, sich im Hinblick auf die Performance durchaus negativ bemerkbar machen könnten…

Ist aber natürlich alles pure Spekulation, denn ich bin ja kein Fachmann. ;-)

Gruß,

Orlok