| M | D | M | D | F | S | S |
|---|---|---|---|---|---|---|
| « Jul | Sep » | |||||
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
- Allgemein (2)
- Apache (2)
- Blender (1)
- Cups, Druck (1)
- Eclipse für PHP-Projekte (7)
- Erfahrungsberichte (68)
- Firewall Netfilter Iptables (1)
- Hardware, Treiber (13)
- Impressum (1)
- KDE (41)
- Kontact - Kmail (11)
- LAMP / Webentwicklung (28)
- LibreOffice, OpenOffice (8)
- Linux 3D Desktop (8)
- MySQL (1)
- Netzwerk (8)
- Open Source (1)
- Open-Xchange (11)
- Open-Xchange 5 (9)
- Open-Xchange 6 (2)
- Opensuse 12.1 (2)
- Postfix, Cyrus, Kmail (7)
- Sound (8)
- Verschlüsselung (Mail, SSH) (4)
- VMware Workstation (12)
- Web - Browser und Co. (11)
- Xen und KVM (2)
- 4.2.2012: Kmail 4.8 - Suchfunktionalität weiterhin im Eimer
- 4.2.2012: Update KDE 4.8 - Nepomuks hohe CPU-Last
- 8.1.2012: Opensuse 12.1 - Erfahrungen mit einer Neuinstallation
- 3.1.2012: Opensuse 11.4 / 12.1 - Problem mit ssh -X
- 28.11.2011: Cyrus IMAP unter Opensuse auf die Schnelle
- 5.11.2011: Kontact 4.7 und OX 6 unter Opensuse 11.4 - Teil II
- 29.10.2011: Kann man KDE professionell nutzen ?
- 21.10.2011: Libreoffice 3.4, Scrollbar-Fehler, KDE 4.7
- 23.8.2011: Opensuse 11.4, samba, apparmor-Problem
- 21.8.2011: Kontact 4.7 und OX 6 unter Opensuse 11.4 - Teil I
homepages
- Februar 2012
- Januar 2012
- November 2011
- Oktober 2011
- August 2011
- Juli 2011
- Mai 2011
- April 2011
- März 2011
- Februar 2011
- Januar 2011
- Dezember 2010
- Oktober 2010
- September 2010
- August 2010
- Juli 2010
- Juni 2010
- Mai 2010
- April 2010
- März 2010
- Februar 2010
- Januar 2010
- Dezember 2009
- November 2009
- Oktober 2009
- September 2009
- August 2009
- Juli 2009
- Juni 2009
- Mai 2009
- April 2009
- Februar 2009
- Januar 2009
- Dezember 2008
- November 2008
- Oktober 2008
- September 2008
- August 2008
- Juli 2008
- Juni 2008
- Mai 2008
- Februar 2008
- Oktober 2007
- September 2007
- Juli 2007
Zur Höhe von Listen bei gefloatetem Inhalt
Wegen einer Nachfrage hier noch ein Kommentar zur Höhenberechnung von dynamisch (!) generierten Listen, in denen die Höhe der Listenelemente und ihrer Inhalte (also irgendwelcher Tags innerhalb der <li>-Tags) nicht vorab bekannt sind und variieren können. Dies betrifft indirekt auch den letzten Beitrag in dieser Blog-Kategorie zur Generierung dynamischer Listen aus Datenbank-Sätzen. Dort hatten wir beschrieben, wie man mit Listen und dem Floaten des Inhalts formatierten Output für Datenbank-Abfragen erzeugen kann.
Eine Kollegin hat nun auf Basis des Beitrags ausprobiert, eine solche Liste unbekannter Höhe zu erstellen, bei der innerhalb der <li> mehrere Elemente (u.a. <div>-Elemente) mit “float:left;” positioniert worden waren. Als sie sich Rahmen um die <li> und das <ul>-Tag zeichnen ließ, war sie sehr erschrocken darüber, dass im Firefox der Rahmen des <ul>-Elements auf einen Strich zusammengezogen erschien. Die Höhe des <ul>-Block-Elements erschien also völlig falsch berechnet.
Komischerweise war das Verhalten im MS IE 7 ganz anders: Hier erschien die Border des <ul>-Tags richtig gezeichnet - also die Höhe des <ul>-Elementes aus den Inhalten der <LI>-Tags richtig berechnet. Warum diese große Diskrepanz zwischen den Browsern? Hat Firefox hier eine Macke? Eine Analyse des Codes zeigt dann dagegen, dass sich der MS IE eigentlich falsch verhielt und Firefox im Wesentlichen richtig!
Ein kurzer Blick auf das <li>-Elemente und die zugehörigen CSS-Anweisungen zeigte (verkürzt) Folgendes:
<ul style="width:30.0em;………border: …… ">
<li style="width:30.0em; clear:left; float:left; border: ….. ; line-height:1.8em; ….">
<div style="float:left; ….">graphisches Element</div>
<div style="float:left; …."><p>mehrzeiliger Text unbekannter Höhe</p></div>
</li>
<li style="width:30.0em; clear:left; float:left; border: ….. ; line-height:1.8em; ….">
……
……
</ul>
Die Listenzeilen wurden schön untereinander dargestellt; leider z.T. mit etwas falschen Abständen, sobald mehrzeilige Elemente auftauchten.
Der erste grundsätzliche Fehler liegt hier zunächst einmal in dem überflüssigen und falschen “float:left” für das <li>-Tag. Dass die Listenelemente überhaupt untereinander dargestellt werden, liegt hier nur an der Breitenbegrenzung des <ul>-Elementes!
Eine Elimination der “float”-Anweisung aus dem <li>-Tag ergab denn schon mal als ersten Fortschritt einen vertikal ausgedehnten Bereich für das <ul>-Element.
Leider hatte das <ul>-Element aber immer noch eine falsche Höhe und auch die Abstände zwischen den <li>-Elementen waren immer noch nicht gleichmäßig. Es hatte also den Anschein, dass die Höhe der <li>-Elemente und damit auch die resultierende Summe für das <ul>-Element nach wie vor falsch berechnet wurden - nämlich so, als ob nur die “line-height” relevant wäre.
Hier kommt nun der interessante Punkt:
Eine “float”-Anweisung hebt den gefloateten Bereich aus dem normalen Inhaltsverlauf (Kontext) des umgebenden Elementes heraus ! Man kann das näherungsweise mit dem Verhalten von absolut positionierten Elementen (z.B. DIVs) in ihrem Parent-Tag (z.B. einem mit “position:relative;” positionierten Container-DIV) vergleichen. Legt man für das umgebende Container DIV eine Höhe und Breite fest, so wird diese im Firefox exakt beachtet; die inneren DIVs ragen aber je nach Position und Größe völlig aus dem umgebenden Bereich heraus. Gleiches gilt für den Inhalt von <p>-Tags: Ist dieser zu groß und ein Text-Umbruch nicht möglich, so ragt der Text im Firefox aus dem umgebenden Block-Element (DIV) heraus. Dies ist vollkommen CSS-konform. (Der alte MS IE 6 verhält sich hier bei P-Tags noch ganz anders - nämlich so, dass er das umgebende DIV-Tag mit dem<P>-Tag ausdehnt.)
Wo liegt also im obigen Beispiel der Fehler? Warum wird die Höhe der <li>-Elemente nicht richtig berechnet? Antwort: Weil die float-Anweisung nicht innerhalb des <li>-Tags wieder aufgehoben wird!
Das Hinzufügen eines Dummy-Elements zum “Clearen” der float-Anweisung innerhalb des <li>-Tags genügt hierfür! Im obigen Beispiel bringt ein zusätzliches <p style="clear:left; ….">-Tag im <li>-Element alles ins Lot:
<ul style="width:30.0em;………border: …… ">
<li style="width:30.0em; border: ….. ; line-height:1.8em; ….">
<div style="float:left; ….">graphisches Element</div>
<div style="float:left; …."><p>mehrzeiliger Text unbekannter Höhe</p></div>
<p style="clear:left; font-size:1px; line-height:1px; margin:0; "> </p>
</li>
……
……
</ul>
Natürlich wird dann auch die “clear”-Anweisung für das <li>-Element selbst überflüssig!
Merke also: Eine korrekte Höhenberechnungen von Elementen, die gefloateten Inhalt umschließen, setzt ein Aufheben der Float-Anweisung durch ein abschließendes (Dummy-) Element voraus.
Das gilt natürlich auch und vor allem für die im letzten Beitrag dieser Kategorie diskutierten dynamisch generierten Listen über PHP IT- oder ITX-Templates !
Antwort schreiben
Sie müssen als angemeldet sein, um einen Kommentar schreiben zu können.