Wegen aktueller Erfahrungen bei einem Kunden möchte ich ein Thema ansprechen, das man nicht oft genug betonen kann :

Wenn man eigene Web-Services wie z.B. Formulardienste oder Pflegeapplikationen mit PHP und dabei auch noch objektorientiert entwickelt, dann lohnt es sich unbedingt, hierbei so vorzugehen, dass die

• grundlegenden Datenbank-Strukturen (Tabellen, Felddefinitionen, Master-Detail-Relationen),
• essentielle Elemente der Datenprüfung/-Validierung,
• Objekte für die Repräsentation von Webformularen,
• Objekte der Datenbankinteraktions-Schicht und
• die darüber liegenden Pflegeapplikationen

auf der Basis von sog. zentralen “Datenschemata” quasi generiert werden. Dabei kann man sogar Vorgaben für die Repräsentation von Master-Detail-Relationen integrieren.

Natürlich ist der Aufbau entsprechender eigener Frameworks mühsam – aber es lohnt sich nach unserer Erfahrung schon ab dem zweiten Projekt.

Die zentrale Idee ist die, dass man sich ein “Framework” so aufbaut, dass durch die programmtechnische Auswertung von vorgegebenen “Datenfeld-” und “Validierungs-” Beschreibungen (“Schema”)

• sowohl die benötigten Datenbank-Tabellen generiert
• als auch zugehörige Pflegeapplikationen in einem “Rutsch” (durch reines Kopieren von Dateien) bereitgestellt werden können.

Die entsprechenden Objekte müssen so “intelligent” sein, dass sie aus der vorgegebenen Datenstruktur-Information des “Schemas” die richtigen Schlüsse ziehen : D.h., dass sie die benötigten SQL-Statements und Validierungsstatements innerhalb der Pflege- und Applikationslogik und die zugehörigen Web-Formulare dynamisch aufbauen, wobei Sie immer gleiche Klassendefinitionen heranziehen.

Salopp ausgedrückt folgt man dabei der Devise: “Gib mir deine Datenstruktur und ich gebe dir eine erste komplette Pflegeapplikation auf der Basis eines universellen Model-View-Controllers und einer universellen Datenbank-Interaktionsschicht an die Hand.” PHP ist für den Aufbau solcher Frameworks aus unserer Sicht seit PHP5.2 geradezu ideal geeignet.

Baut man die Pflegefunktionalität selbst modular in Funktionalklassen auf, so verschafft man sich gleichzeitig die Basis für komplexere und spezialiserte Business-Applikationen, denen man dann Schema-Objekte übergibt. Aus der Schema-Information werden dann nach Bedarf automatisch Objekte für die Repräsentation einzelner Datensätze oder ganzer Listen von Datensätzen generiert. Die Interaktion mit der Datenbank tritt dann für die Business-Logik in der Regel fast völlig in den Hintergrund.

Bei Erweiterungen um Felder ändert man primär das entsprechende “Schema” und schon läuft die erweiterte Applikation – vorbehaltlich inhaltlicher Erweiterungen der Business-Logik. Es liegt auf der Hand, dass sich die anfängliche Mühe bei der Erstellung “schemabasierter” Frameworks schnell lohnt.

Hier noch ein Nachtrag zu den letzten Beiträgen in dieser Kategorie:

Den vertikalen Abstand zwischen den LI-Elementen in vertikal orientierten Listen steuert man zumeist mit einer Vorgabe von “margin-top” und/oder “margin-bottom” für das LI-Element. Vergleicht man solche vertikal aufgebaute Listen anschließend bzgl. ihrer Darstellung im MS IE 7 und im Firefox, so fällt einem leider oftmals auf, dass der Internet Explorer um einige Pixel größere Abstände zwischen Listenelementen zeichnet als der FF.

Im Internet findet man hierzu vielfach den Tip mit

< li style =”clear:left; float:left; margin-bottom: …. ” >

zu arbeiten. Wir meinen, dass dies
1) einen künstlichen Missbrauch der float-Anweisung darstellt,
2) unerwünschte Nebenwirkungen haben kann (s. hierzu einen früheren Beitrag in dieser Kategorie)
3) keinesfalls immer hilft, das Problem zu lösen.

Wir empfehlen Ihnen dagegen, zunächst folgende Tipps auszuprobieren, um vertikale Abstände in Listen im FF und MS IE aneinander anzugleichen.

Tipp 1: Besondere Behandlung von Bildern in <LI>-Tags

Man prüfe, ob sich innerhalb der LI-Elemente <IMG>-Tags befinden. In diesem Fall dichtet der MS IE7 grundsätzlich mindestens 1 Pixel zum per CSS vorgegebenen Abstand zwischen den LI-Elementen hinzu. I.d.R. hilft es auch nichts, das <IMG>-Tag in einem <DIV>-Tag zu kapseln. Sehr wohl hilft dagegen aber eine Darstellung des <IMG>-Tags als “Block”-Element, z.B über eine CSS-Vorgabe für die IMGs der betroffenen Liste:

ul#mein_ul li img { display:block; }

Es war für uns ein regelrechtes Schlüsselerlebnis, nach diesem kleinen Trick feststellen zu dürfen, dass plötzlich die vertikalen Abstände zwischen LI-Elementen im MS IE7 und FF gleich wurden.

Tipp 2: Vorgbe von position:relative; vertical-align:top für das <LI>-Tag

Sind unabhängig von Bildern weiterhin unerklärliche Differenzen in den Abständen zwischen FF und MS IE festzustellen, so hilft sehr oft ein Hinzufügen folgender CSS-Vorgaben für das LI-Element:

li { position:relative; vertical-align:top; ….. }

In folgendem Beispiel mussten wir eine Liste mit Bildern unterschiedlicher Höhe formatieren und haben die Tipps 1 und 2 wie folgt kombiniert, um im MS IE und im FF auf gleiche Abstände zwischen den LI-Elementen zu kommen:

ul#img_list { position:relative; width:10.0em; list-style-type:none; margin-left:0.0em; margin-top:0.4em; padding:0.0em; }
ul#img_list li { position:relative; vertical-align:top; margin-top:0.0em; margin-bottom:2.0em; padding:0.0em;line-height:1.6em; min-height:8.0em; }
ul#img_list li img { display:block; }

Tipp 3: Korrekter Abschluss von float-Direktiven im <LI>-Tag

In einem der letzten Beiträge hatte ich diskutiert, dass man innerhalb eines <LI>-Tags durchaus Positionierungen mit float-Direktiven vornehmen kann. Typisch wäre etwa ein Konstruktion der Art

<li>
   <div style=”float:left; …. ” >DIV-Inhalt A</div>
   <div style=”float:left; margin-left:1.0em; … ” >DIV-Inhalt B</div>
   <div style=”float:right; … ” >DIV-Inhalt C</div>
</li>

oder noch Komplexeres. Das Manko am obigen Code ist natürlich, dass die Float-Befehle wieder aufgehoben werden müssen, damit beide Browser das umgebende und die nachfolgenden <LI>-Elemente korrekt und vor allem mit korrekter Höhe aufbauen. Zum “clear” der “float”-Anweisungen kann man folgende <P>-Tag-Anweisung verwenden:

<li>
   <div style=”float:left; …. ” >DIV-Inhalt A</div>
   <div style=”float:left; margin-left:1.0em; … ” >DIV-Inhalt B</div>
   <div style=”float:right; … ” >DIV-Inhalt C</div>
 &
nbsp; <p style=”clear:both; font-size:0px; line-height:0px; margin-top:20px; height:0px;”>&nbsp;</p>
</li>

Hierbei schließt das <P>-Tag nicht nur die “float”-Direktiven ab. Das Tag sebst soll in unserem Beispiel keine Höhe aufweisen, aber einen Abstand unterhalb der DIVs erzeugen (“margin-top” !) und damit auch die Höhe des umgebenden <LI>-Tags beeinflussen. Wir diskutieren diesen sehr allgemeinen Fall; natürlich steht es jedem frei, die margins anders zu setzen.

Essentiell ist hierbei im MS IE7 das “height:0px”. Ohne diese Anweisung wird leider unabhängig von den sonstigen Anweisungen der Schriftzug im MS IE7 mindestens 1px einnehmen.

Für den FF ist ferner die explizite Angabe von &nbsp; essentiell – im besonderen dann, wenn dass <P>-Tag auch noch die Rolle eines vertikalen Abstandshalters mit einem “margin-top:20px;” spielen soll. Die “margin-top”-Anweisung würde bei einem

<p …..> </p>

im FF schlicht ignoriert werden, während der MS IE 7 auch in diesem Fall die “margin-top”-Anweisung beachten würde !

Tipp 3: Bei verschachtelten Listen nach der inneren Liste ein <p>-Tag einfügen

Bei verschachtelten Listen der Art

<ul>
   <li>
      <ul>
      <li>
…..
…..
      </li>
   </ul>
<ul>

behandelt der MS IE 7 z.B. die Kombination von “margin-bottom”-Anweisungen für das letzte innere <LI> mit “margin-bottom”-Anweisungen für das äußere <LI> anders als der FF. Um den Firefox dazu zu zwingen, die LI-Elemente nicht zusammenzuschieben, kann es nützlich sein, im Anschluß an das innere </ul> ein künstliches <P>-Tag mit 0 Ausdehnung einzuführen (ähnlich wie in Tipp 3).

<ul>
   <li>
      <ul>
      <li>
…..
…..
      </li>
   </ul>
   <p style=”font-size:0px; line-height:0px; margin-top:20px; height:0px;”>&nbsp;</p>
<ul>

Tipp 4: Kapseln von Formularelementen in DIVs passender Höhe innerhalb von LI-Elementen mit ausreichender Höhe

Hat man die Abstände zwischen den LI-Elementen standardisiert, so kann es bei Listen mit Formularelementen auch innerhalb eines LI-Elementes zu Höhenunterschieden zwischen dem FF und dem MS IE kommen. Gerade der MS IE dichtet zu Formular-Elementen wie dem INPUT- und dem TEXTAREA-Feld gerne eigene Außenabstände hinzu, die im Ergebnis zu größeren Höhen des LI-Elementes im MS IE 7 im Gegensatz zum Firefox führen können.

Bei Formularelementen innerhalb von Listenelementen lohnt es sich deshalb, die Höhe des LI-Elementes so vorzugeben, dass das Formularelement inkl. einiger Pixel Außenabstand sicher in das LI-Element hineinpasst und das Textarea-Feld oder Input-Element zusätzlich in ein DIV einzubinden. Bei mit PHP dynamisch erzeugten Textarea oder Input-Feldern ist es also notwendig, die Höhe der LI-Elemente beim Generieren der Liste bereits passend zu berechnen und dem LI-Element danach eine hinreichende Höhe per “height”-Anweisung in einem “style”-Attribut mitzugeben.

Ausgangsbasis ist dabei aber immer eine “height”-Vorgabe für die Formularfelder selbst!

Bei Textarea-Elementen sollte man bei der Höhenformatierung eher mit einer CSS-height-Vorgabe anstelle des “row”-Attributs arbeiten, um Höhenwerte im MS IE 7 zu bekommen, die mit denen des FF identisch sind.

Mit Hilfe der Tipps 1 bis 3 haben wir es praktisch immer geschafft, vertikal orientierte Listen so hinzubekommen, dass sie im MS IE und FF bzgl. des (vertikalen) Zwischenraums zwischen den Listenelementen und auch bzgl. der Höhe der Listenelemente identisch aussahen.

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; ….&quot>graphisches Element</div>
        <div style="float:left; ….&quot><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; ….&quot>graphisches Element</div>
        <div style="float:left; ….&quot><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 !

Im Rahmen der Programmierung von Datenbank-Abfragen mit PHP ist man immer wieder mit der Frage konfrontiert, wie man die Ergebnisse in listenartiger Form darstellen soll. Hierbei können u.a. folgende Schwierigkeiten auftreten:

a) Die Länge oder Größe des Inhalts einzelner Felder aus der Datenbank ist zunächst unbekannt. Die einzelnen Listenelemente müssen daher in der Höhe variabel sein.

b) Innerhalb eines Listenelementes hat man oftmals komplexe Unterformatierungen vorzunehmen. So ist das Listen-Aufzählungszeichen darzustellen. Hinzu kommen evtl. Feldbezeichnungen, die vom eigentlichen Feldinhalt abgesetzt werden sollen.

c) Der einzelne Satz der Datenbankabfrage beinhaltet i.d.R. mehrere Felder und entsprechende Inhalte, die pro Satz untereinander aufgelistet werden sollen. Um ein komplettes Resultset einer Datenbank-Abfrage darzustellen, braucht man also mindestens eine zweifach geschachtelte Liste. Damit erschwert sich die Formatierung.

d) Die Darstellung der (geschachtelten) Listen erweist sich bzgl. der Formatierung oft als browserabhängig. Dies gilt im besonderen für die Behandlung von Abständen der Aufzählungszeichen zum linken Rand der Liste wie zum Inhalt des Listenpunktes. Hinzu kommen weitere Standardabstände, die ggf. mühsam korrigiert werden müssen.

Will man die Darstellung einer Datenbankabfrage also etwa nach dem Schema

formatieren, so erweist sich der simple Einsatz von “<UL><LI></LI></UL>” oft als unzureichend und – nicht zuletzt wegen der Browserabhängigkeit der Listenformatierung – auch als schwierig.

In vielen Fällen sind neben dem oben dargestellten Elementen pro Satz des Resultsets noch weitere schmuckvolle Bereiche darzustellen: etwa eine Leiste mit Buttons zum Auslösen von Pflegeoperationen für den Datenbank-Satzes oder zur Anzeige seines Status.

Gestern bin ich denn auch bei einem Kunden gefragt worden, ob wir zur Darstellung von solchen Resultsetlisten eigentlich Tabellen verwenden würden. Bzw.: Wie wir diese Probleme generell im Zusammenspiel mit serverseitigem PHP lösen würden.

Hierzu gibt es mehrere Antworten:

1. Wir verwenden zur Formatierung des HTML-Outputs grundsätzlich Templates – zumeist PEAR IT- oder ITX-Templates. (Smarty-Templates sind natürlich eine genauso gute Alternative). Hierdurch trennen wir die Datenbankinteraktion und evtl. Datensatzmanipulationen im PHP-Skript weitgehend von der Darstellung des Resultsets im Browser ab. (Das erleichtert im nachhinein auch den Schwenk von klassischer PHP-Interaktion mit HTML-Generierung zu moderneren Vorgehensweisen auf der Basis von Ajax-Technologien.)

   Alle nachfolgenden Hinweise zur Formatierung sind somit reine HTML- bzw. CSS-Hinweise für das Template.

2. Bei der Formatierung des listenartigen Outputs im IT-Template setzen wir in der Regel keine Tabellen mehr ein, da wir deren Handhabung inzwischen eher als unflexibel empfinden. Vielmehr verwenden wir sehr wohl Listentags (<UL>, <LI>).
3. Für die Listen schalten wir i.d.R. allerdings die Formatierung für linksseitige MARGINs und PADDINGs ab. Per CSS setzen wir solche “MARGINs” und “PADDINGs” auf 0, sowohl im <UL>-Tag wie auch im <LI>-Tag. Auch den “list-style-type” setzen wir i.d.R. auf “none”. Hiermit erzielen wir später eine Kompatibilität der Listendarstellung für praktisch alle gängigen Browser (s.u.).
4. Grundsätzliche Breiteneinstellungen der Liste nehmen wir im <UL>-Tag und wg. des MS IE auch im <LI>-Tag vor. (Das UL-Element verhält sich grundsätzlich wie ein Block. Nur sieht das das der MS IE nicht so.) Die Höhenvorgabe für die gesamte Liste und auch die einzelnen Listenelemente lassen wir dagegen offen.
5. Die Abstände zwischen den Listen-Elementen regeln “margin-bottom”-Anweisungen für die <LI>-Tags. Hintergrundsfarben für den gesamten Listenbereich regelt wir manchmal über ein DIV, das die Liste umfasst. Von der “normalen” Listenformatierung bleibt also bislang nur eine Breitenvorgabe und ein vorgegebener Abstand zwischen den Listenelementen übrig.
6. Die Formatierung innerhalb eines Listenelements gestalten wir grundsätzlich mit DIVs. In das <LI>-Tag der Hauptliste binden wir deshalb zunächst ein Container-DIV (“Satz-Container”) vorgegebener Breite ein. Die Höhe dieses Containers bleibt offen.
7. Innerhalb des “Satz-Container”-DIVs (in einem <LI>-Tag der Liste für die Sätze) positionieren wir nun ein weiteres DIV (“Header-Container”), das zusätzliche DIVs für den den satzspezifischen
   Header und das Aufzählungszeichen für den Satz aufnimmt. Die Positionierung dieser inneren DIVs im “Header-Container” erfolgt über float-Anweisungen; relative Abstände werden über “margin”-Anweisungen festgelegt. Wichtig ist hier noch, dass ein nachfolgendes Dummy-Element (z.B. ein <p>-Tag) das Floaten im Container wieder aufhebt. Breite und Höhe des Header-Containers können in der Regel fest vorgegeben werden. Zusätzlich dient ggf. eine “margin-bottom”-Anweisung zur Festlegung des minimalen Abstands zu weiteren nachfolgenden DIV-Elementen eines Satzes.

8. Unterhalb des Header-Containers des Satzes positionieren wir nun eine weiteres DIV (“Container Feldliste”). Der Container “Feldliste” wird relativ (!) zum Header-Container positioniert (ggf. ist ein zusätzl. margin-top festzulegen). Seine Breite ist beliebig vorgebbar, seine Höhe bleibt offen.

   Damit die Positionierung auch richtig erfolgen kann, sollte man diesem DIV (Container Feldliste) zur Sicherheit noch eine Style-Anweisung “clear:both;” mitgegeben. Damit werden die vorhergehenden float-Anweisungen für die Header-Elemente aufgehoben, wenn man dies dort vergessen hat.

9. Verschachtelte zweite Liste: In den “Container Feldliste” positionieren wir nun erneut eine <UL>-Liste, die dann der Darstellung der Feldelemente eines Satzes aus dem Resultset dient. Auch für diese Liste schalten wir evtl. intrinsische linksseitige margin- und padding-Vorgaben der Browser explizit ab und setzen den “list-style-type:none”. Zudem regeln wir den vertikalen Abstand der Listenelemente durch “margin-bottom”-Vorgaben.
10. Pro Listenelement der feldbezogenen Liste erstellen wir nun einen weiteren DIV-Container (“Container Einzelfeld”). Auch seine Breite und Margins geben wir vor. Die Höhe bleibt dagegen offen.
11. In den Container “Einzelfeld” werden nun weitere separate DIVs für ein evtl. Aufzählungszeichen, den Feldnamen und den Feldinhalt gesetzt. Die relative Positionierung der inneren DIVs zueinander erreichen wir erneut per CSS-float-Anweisungen. Die relative Positionierung der inneren DIVs zueinander regeln zusätzliche “margin”-Anweisungen. Auch hier heben wir die float-Anweisung wieder über ein abschliessendes Dummy-Element auf. Keines (!) der inneren DIVs wird also im Container über “position:absolute” positioniert. Es werden nur float- und margin-Anweisungen verwendet.
12. Die Breite der einzelnen inneren DIVs für den Feldbereich geben wir per CSS vor. Die Höhe des DIVs zur Aufnahme des Feldinhalts lassen wir dagegen im Falle von Textfeldern offen, da die Länge und Größe des Feldinhalts dann ja vorab nicht bekannt ist.
13. Um das Container-DIV “Einzelfeld” (wegen einer evtl. Rahmung oder Hintergrundsfarbe) an die vorab unbekannte Höhe der inneren DIVs – im besonderen des DIVs für den Feldinhalt anzupassen, ist folgender Schritt wichtig:

    Zusätzlich zu den inneren “gefloateten” DIVS bringen wir ein weiteres relativ positioniertes Dummy-Tag (z.B. ein P-Tag) an, das die “style”-Anweisung “clear:both;” enthält. Ohne diese Anweisung ist die Höhe des Container-DIVs “Einzelfeld” nur auf eine Minimum beschränkt und die gefloateten inneren DIVs ragen über den Minimalbereich des Containers weit hinaus. Das Dummy-Tag ermöglicht als reguläres Inhaltselement des Containers die Höhenbestimmung für das Elternelement, indem es die Float-Anweisungen aufhebt.

Durch diese zweifach verschachtelte Liste und die erwähnten Maßnahmen erreicht man eine sehr schöne und im nachhinein per CSS sehr einfach anpassbare Listendarstellung der Ergebnisse von Datenbankabfragen. Da die eigentliche Formatierung jedes Listenelements inkl. Aufzählungszeichen innerhalb
eines DIV-Containers erfolgt, wird man bzgl. der Listendarstellung der Sätze und der inneren Liste der Felder praktisch browser-unabhängig.

Natürlich lagert man die CSS-Anweisungen für die Listen und die inkludierten DIVs zur besseren Pflegbarkeit in eine separate Datei aus.