3 divs... Probleme mit schließung!
Hendrik
- css
0 Der Martin0 Hendrik0 Hendrik0 Der Martin0 at
Hey!
Ich habe drei divs, die so aufgebaut sind:
<div id="alles">
<div id="oben">
<h2>Bla, bla...oben!<h2>
</div>
<div id="unten">
<h2>Bla, bla...unten!<h2>
</div>
</div>
Und eine CSS-Datei, in der definiert ist, wie <h2> aussehen soll.
Ich habe bei div#alles h2 eine bestimmte Größe zugewiesen, nur leider wird die nur bei id="oben" angenommen. Bei id="unten" wird die Standard-Größe für h2 genommen.
Jetzt vermute ich, dass das mit der Schließung zutun hat. Der Parser weiß ja auch nicht, was geschlossen werden soll. Ich will, dass id="oben" geschlossen wird, es wird aber wohl id="alles" geschlossen.
Wie kriege ich es hin, dass id="oben" geschlossen wird?
Falls das jetzt jemand kapiert hat und eine Antwort darauf weiß, so antworte er mir bitte!
Hendrik
Hallo Hendrik,
<div id="alles">
<div id="oben">
<h2>Bla, bla...oben!<h2>
</div>
<div id="unten">
<h2>Bla, bla...unten!<h2>
</div>
</div>
ich vermute, dass in div#oben und div#unten noch mehr Text außer der Überschrift hinein soll, richtig? Denn sonst wären die divs unnötig und du könntest ebensogut die h2-Elemente direkt formatieren.
Und dass du die Überschriften mit <h2> öffnest, aber auch mit <h2> wieder schließen willst, ist ein Tippfehler? Da sind wohl ein paar '/' auf der Strecke geblieben ...
> Und eine CSS-Datei, in der definiert ist, wie <h2> aussehen soll.
> Ich habe bei div#alles h2 eine bestimmte Größe zugewiesen
Wie sieht deine CSS-Regel genau aus?
> Jetzt vermute ich, dass das mit der Schließung zutun hat. Der Parser weiß ja auch nicht, was geschlossen werden soll.
Doch, das weiß er sehr genau: Immer das zuletzt geöffnete Element. Die Zuordnung ist eindeutig, weil Elemente zwar verschachtelt, aber nicht verzahnt werden dürfen.
Beispiel: <p><em>...<strong>...</strong></em></p> korrekt
<p><em>...<strong>...</em></strong></p> falsch
> Wie kriege ich es hin, dass id="oben" geschlossen wird?
Zeig mal das komplette Werk. So wie du es beschreibst, wäre es nämlich richtig. Bestimmt steckt noch irgendwo der Teufel im Detail.
Schönen Abend noch,
Martin
--
Schildkröten können mehr über den Weg berichten als Hasen.
Hey Der Martin,
Ich habe gerade einen Tippfehler entdeckt: Ich hatte die <h2>-Elemente mit </h4> geschlossen. Jetzt habe ich das korrigiert, aber es ändert sich trotzdem nichts!
Übrigens:
ich vermute, dass in div#oben und div#unten noch mehr Text außer der Überschrift hinein soll, richtig? Denn sonst wären die divs unnötig und du könntest ebensogut die h2-Elemente direkt formatieren.
Und dass du die Überschriften mit <h2> öffnest, aber auch mit <h2> wieder schließen willst, ist ein Tippfehler? Da sind wohl ein paar '/' auf der Strecke geblieben ...
Natürlich hast du in beiden Punkten Recht. Es soll selbstverständlich noch mehr Text hinein und mit <h2> statt mit </h2> zu schließen ist natürlich auch nur ein Tippfehler hier im Forum...
Zeig mal das komplette Werk. So wie du es beschreibst, wäre es nämlich richtig. Bestimmt steckt noch irgendwo der Teufel im Detail.
Hier mein komplettes Werk:
Die Dateien:
-seite.php
-erstes.inc
-zweites.inc
-styles.css
__________________________________________
seite.php
<div id="rechts">
<div id="Erstes">
<? include("erstes.inc") ?>
</div>
<div id="Zweites">
<? include("zweites.inc") ?>
</div>
</div>
__________________________________________
erstes.inc
<h2 style="text-align: center;">Erstes:</h2>
<p>Dies ist das Erste von den include-Dateien</p>
<p>Natürlich ist das nicht der tatsächliche Text; und die Dateinamen sind eigentlich auch anders, aber an dem wichtigen Element; nämlich <h2> habe ich nichts geändert...</p>
__________________________________________
zweites.inc
<h2 style="text-align: center;">Zweites:</h2>
<p>Dies ist das Zweite von den include-Dateien</p>
<p>Natürlich ist das nicht der tatsächliche Text; und die Dateinamen sind eigentlich auch anders, aber an dem wichtigen Element, nämlich <h2> habe ich nichts geändert...</p>
__________________________________________
styles.css
div#rechts h2 {
font-size: 2em;
margin: 0em 0;
}
div#rechts h3 {
font-size: 1.5em;
margin: 0em 0;
text-align: center;
}
div#rechts h4 {
font-size: 17em;
margin: 0em 0;
}
div#rechts h5{
font-size: 2em;
text-decoration: underline;
margin: 0em 0;
}
________________________________________________________
So, das war mein kompletter Code. Ich hoffe, du findest den Teufel im Detail; für mich sieht alles total korrekt aus!
Vielen Dank für eure (oder deine) Hilfe!
Hendrik
Oh, man!
Ich war gerade dabei, einfach auch in div#erstes und div#zweites definitionen von h2 hineinzukopieren (also div#erstes h2 und div#zweites h2), da fiel mir auf, dass unten eine weitere (und total veraltete) Definition von h2 stand, nämlich so:
div#zweites h2{
font-size: .....;
........;
........;
}
So ein simpler Fehler. Eigentlich toll, wie logisch Parser mit Anweisungen umgehen!
Hendrik
Hallo Hendrik,
Ich habe gerade einen Tippfehler entdeckt: Ich hatte die <h2>-Elemente mit </h4> geschlossen. Jetzt habe ich das korrigiert, aber es ändert sich trotzdem nichts!
Nee, da steckt *noch* ein kapitaler Bock drin. Zweimal derselbe sogar. ;-)
Aber erst noch ein guter Rat zum Einbinden von PHP-Code:
<? include("erstes.inc") ?>
<? include("zweites.inc") ?>
Du verlässt dich hier darauf, dass short_open_tags in der PHP-Konfiguration aktiviert ist. Das ist aber lange nicht bei jedem Hoster der Fall; gewöhne daher sicherheitshalber die nicht verkürzte Schreibweise <?php ... ?> an.
Und das sind die beiden Killer:
<p>Natürlich ist das nicht der tatsächliche Text; und die Dateinamen sind eigentlich auch anders, aber an dem wichtigen Element; nämlich <h2> habe ich nichts geändert...</p>
<p>Natürlich ist das nicht der tatsächliche Text; und die Dateinamen sind eigentlich auch anders, aber an dem wichtigen Element, nämlich <h2> habe ich nichts geändert...</p>
Schau mal genau hin ... merkst du was?
Wieso steht denn da mitten im Absatz ein öffnendes <h2>? Mach mal die spitzen Klammern weg oder codiere sie korrekt! Dann klappts's auch mit dem Nachbarn!
Du hast hier die Tag-Struktur (Attribute und Inhalte weggelassen):
<div><h2></h2><p></p><p><h2></p></div>
<div><h2></h2><p></p><p><h2></p></div>
Theoretich müsste zwar mit dem Auftreten des h2-Elements der Absatz (p) automatisch geschlossen werden, und das h2-Element seinerseits zwangsweise mit dem Schließen des div. Denn wie ich schon sagte, dürfen die Elemente ja nur "sauber" verschachtelt werden. Wenn also das äußere geschlossen wird, müsste das innere damit implizit auch geschlossen werden. Korrekterweise müsste der Browser das also intern so ergänzen:
<div><h2></h2><p></p><p></p><h2></p></h2></div>
^ ^ ^
| | +-- ergänzt
| +-------ignoriert
+---------------ergänzt
Aber das kapiert hier anscheinend der IE nicht so richtig, Firefox lässt sich dagegen nicht aus der Ruhe bringen.
Schönen Abend noch,
Martin
Hi Martin,
<? include("erstes.inc") ?>
<? include("zweites.inc") ?>Du verlässt dich hier darauf, dass short_open_tags in der PHP-Konfiguration aktiviert ist. Das ist aber lange nicht bei jedem Hoster der Fall; gewöhne daher sicherheitshalber die nicht verkürzte Schreibweise <?php ... ?> an.
Du hast natürlich Recht - aber das wirklich wichtige hast du doch vergessen zu sagen ;-)
Hendrik, in deinen Include-Dateien steht kein PHP-Code - aus diesem Grund solltest du aus Sicherheitsgründen nicht include() sondern readfile() verwendne - ersteres führt PHP-Code der in der Include-Datei enthalten ist aus, letzteres gibt einfach nur den Inhalt aus. Die Gefahr ist, dass über Manipulation der Include-Datei Code eingeschleust werden kann und somit zur Ausführung gebracht wird.
MfG, Dennis.
Hallo,
Hendrik, in deinen Include-Dateien steht kein PHP-Code - aus diesem Grund solltest du aus Sicherheitsgründen nicht include() sondern readfile() verwendne - ersteres führt PHP-Code der in der Include-Datei enthalten ist aus, letzteres gibt einfach nur den Inhalt aus. Die Gefahr ist, dass über Manipulation der Include-Datei Code eingeschleust werden kann und somit zur Ausführung gebracht wird.
guter Hinweis. Ich habe das nicht übersehen - aber solange der Name der eingebundenen Datei als Konstante notiert wird, so wie in Hendriks Beispiel, sehe ich keine Gefahr. Und ebensowenig sehe ich eine Veranlassung, jemand darauf hinzuweisen, dass der Dateiname beim include auch ein dynamischer Ausdruck bzw. eine Variable sein könnte (was ich für eine Konzeptschwäche von PHP halte).
Keine schlafenden Hun^WWebprogrammierer wecken.
Ciao,
Martin
Hi Martin,
Und ebensowenig sehe ich eine Veranlassung, jemand darauf hinzuweisen, dass der Dateiname beim include auch ein dynamischer Ausdruck bzw. eine Variable sein könnte (was ich für eine Konzeptschwäche von PHP halte).
Nein, das Leuten zu verschweigen halte ich nicht für eine gute Idee - du weiß doch, sobald etwas verboten ist, wirds immer erst richtig interessant ;-)
Aber ich wollte eigehtlich mehr auf die "Konzeptschwäche" eingehen - ich halte das nämlich überhaupt nicht für eine Konzeptschwäche. Oder wie willst du ein Plugin-System realisieren, bei dem bestimmte Plugin-Dateien (z.B. aus einer Konfigurations-Datei) nachgeladen werden sollen? Wenn du jeden Dateinnamen hardkodieren müsstest, kämst du nie ans Ziel. [1]
MfG, Dennis.
[1] Jetzt sag mir nicht, dass du exec("php /path/to/file") verwenden und die Rückgabe auswerten willst *fg*
Hallo Dennis,
Nein, das Leuten zu verschweigen halte ich nicht für eine gute Idee - du weiß doch, sobald etwas verboten ist, wirds immer erst richtig interessant ;-)
eben deshalb: Was ich nicht weiß, macht mich nicht heiß. Anstatt jemanden zu warnen, "Bloß nicht die Sicherung überbrücken, das kann gefährlich sein", halte ich lieber meinen Mund und bringe denjenigen gar nicht erst auf solche Ideen.
Aber ich wollte eigehtlich mehr auf die "Konzeptschwäche" eingehen - ich halte das nämlich überhaupt nicht für eine Konzeptschwäche. Oder wie willst du ein Plugin-System realisieren, bei dem bestimmte Plugin-Dateien (z.B. aus einer Konfigurations-Datei) nachgeladen werden sollen?
Dafür ist das include-Prinzip nach meinem Verständnis sowieso der falsche Ansatz. Vielleicht liegt das an dem Weg, den ich in meiner Programmierer-Laufbahn genommen habe: Ich bin zunächst mit Sprachen wie Pascal, C und Assembler groß geworden. Da gibt es auch Includes, aber das spielt sich alles *vor* dem Compiler- bzw. Assemblerlauf ab. Das Ergebnis ist ein in sich abgeschlossenes Programmmodul, dessen Umfang der Programmierer exakt vorherbestimmt hat. Möchte ich während der Laufzeit weitere Module dynamisch dazuladen und ausführen, muss ich andere Techniken verwenden.
Aus der Compiler-Fraktion kommend, finde ich das liberale und dadurch komplexere Include-Prinzip von Scriptsprachen wie PHP zunächst mal bedenklich und werde tunlichst an meinen Gewohnheiten festhalten, nur Konstanten in den include-Anweisungen zu notieren - obwohl sie eigentlich bei der gebotenen Vorsicht ähnlich mächtig sind wie z.B. unter Windows das dynamische Nachladen von DLLs. Und ähnlich böse Stolperfallen produzieren können.
Im Gegensatz zu Windows-DLLs haben includierte Scripte in PHP allerdings leider keinen eigenen Adress- bzw. Namensraum. Eine saubere Modularisierung, wie sie für ein Plugin-Konzept wünschenswert wäre, ist dadurch IMHO sowieso nicht möglich.
So long,
Martin
Hi Martin,
[In C] gibt es auch Includes, aber das spielt sich alles *vor* dem Compiler- bzw. Assemblerlauf ab. Das Ergebnis ist ein in sich abgeschlossenes Programmmodul, dessen Umfang der Programmierer exakt vorherbestimmt hat. Möchte ich während der Laufzeit weitere Module dynamisch dazuladen und ausführen, muss ich andere Techniken verwenden.
Das z.B. in C die Includes vor dem Compile-Vorgang ablaufen war mir bewusst, aber über das Nachladen von Programm-Code habe ich mir noch keine Gedanken gemacht - muss man sich dann da selber über das Einlesen von Dateien etwas basteln und die Inhalte der Dateien interpretieren, oder wie läuft das ab bzw. könnte das ablaufen?
Im Gegensatz zu Windows-DLLs haben includierte Scripte in PHP allerdings leider keinen eigenen Adress- bzw. Namensraum. Eine saubere Modularisierung, wie sie für ein Plugin-Konzept wünschenswert wäre, ist dadurch IMHO sowieso nicht möglich.
Wofür gibt es den Klassen? Wenn man alles schön in diverse Klassen trennt (was man ja eigentlich IHMO sowieso machen sollte) gibt es mit den Namensräumen doch keine Probleme mehr. Abgesehen davon meine ich mich zu erinnern in den Plänen für PHP6 gelesen zu haben, dass Namensräume eingeführt werden sollen oder es zumindest versucht werden soll.
MfG, Dennis.
Hallo Dennis,
Das z.B. in C die Includes vor dem Compile-Vorgang ablaufen war mir bewusst, aber über das Nachladen von Programm-Code habe ich mir noch keine Gedanken gemacht - muss man sich dann da selber über das Einlesen von Dateien etwas basteln und die Inhalte der Dateien interpretieren, oder wie läuft das ab bzw. könnte das ablaufen?
Die Sprache an sich sieht nichts derartiges vor. Als C-Programmierer bist du also darauf angewiesen, dass das jeweilige Zielsystem (Betriebssystem) etwas in der Art bietet. Wie ich schon erwähnte, gibt es unter Windows dafür das DLL-Konzept (Linux kennt AFAIK sogenannte shared objects, was aber im Endeffekt dasselbe ist), wobei auch jede DLL ein in sich abgeschlossenes Modul ist, das auch getrennt übersetzt wurde.
Früher, in der guten alten DOS-Zeit, hat man da gelegentlich noch mit sogenannten "Overlays" getrickst - zwar hat DOS als Betriebssystem das dynamische Nachladen von Programmcode nicht unterstützt, dafür aber die Runtime-Bibliotheken diverser Compiler. Das war allerdings meistens ein Flickwerk.
Wofür gibt es den Klassen?
Das würde ich auch gern wissen. Ich mag zwar das Konzept objektorientierter Programmierung, aber ich mag es nicht, wenn eine Programmiersprache zu viel von dieser Technik vor mir verbirgt. Deswegen ist mir C++ unsympathisch und ich bilde lieber ähnliche Strukturen mit reinem C nach - da habe ich dann wenigstens die volle Kontrolle und weiß genau, was abläuft, anstatt mich auf mystische Tricks von C++ verlassen zu müssen. Und Klassen in PHP sind mir aus ganz ähnlichen Gründen suspekt.
Abgesehen davon meine ich mich zu erinnern in den Plänen für PHP6 gelesen zu haben, dass Namensräume eingeführt werden sollen oder es zumindest versucht werden soll.
Sowas in der Art habe ich auch schon aufgeschnappt. Ich bin gespannt. :-)
Schönen Abend noch,
Martin
Hi Martin,
Die Sprache an sich sieht nichts derartiges vor. Als C-Programmierer bist du also darauf angewiesen, dass das jeweilige Zielsystem (Betriebssystem) etwas in der Art bietet. Wie ich schon erwähnte, gibt es unter Windows dafür das DLL-Konzept (Linux kennt AFAIK sogenannte shared objects, was aber im Endeffekt dasselbe ist), wobei auch jede DLL ein in sich abgeschlossenes Modul ist, das auch getrennt übersetzt wurde.
Ja, z.B. der Apache verwendet ja für seine Module auch diese shared object - wobei ich mir nicht so genau vorstellen kann wie so etwas abläuft. Wenn ich dich richtig verstanden habe ich es Sache des OS das zu implementieren und nicht Sache der Programmiersprache... Vielleicht sollte ich mein Wissen in diese Richtung mal etwas erweitern, wenn ich zu viel Zeit übrig habe *g*
Ich mag zwar das Konzept objektorientierter Programmierung, aber ich mag es nicht, wenn eine Programmiersprache zu viel von dieser Technik vor mir verbirgt. Deswegen ist mir C++ unsympathisch und ich bilde lieber ähnliche Strukturen mit reinem C nach - da habe ich dann wenigstens die volle Kontrolle und weiß genau, was abläuft, anstatt mich auf mystische Tricks von C++ verlassen zu müssen. Und Klassen in PHP sind mir aus ganz ähnlichen Gründen suspekt.
Auf was für "Tricks" spielst du an? Z.B. in PHP so Sachen wie eine Funktion namens __construct(), die bei der initialisierung des Objekts aufgerufen wird? Sogenannte magische Funktionen? Gerade so etwas finde ich etwas finde ich eigentlich praktisch, erspart Arbeit =) und außerdem sind diese Sachen ja auch alle dokumentiert und überall nachzulesen.
Wie du aber bereits gesagt hast ist dieser grundliegene Unterschied in der Vorgehensweise wohl darauf zurück zu führen, mit welcher Sprache man angefangen hat zu programmieren. Ich habe einst mit PHP angefangen (nach Javascript natürlich, aber das zählt IHMO nicht richtig *g*), später kam dann (gezwunger Maßen - d.h. Schule) noch Visual Basic hinzu. Zwischendurch dann noch ein paar eher kurze Ausflüge in die Theorie von Perl und C kam dann dieses Jahr in der Schule noch ein bisschen Java dran. Das wars aber auch schon.
Ach ja - ich glaube dich so verstanden zu haben, dass du unter Windows das ein oder andere programmierst, erstellst du da auch Programme mit grafischen Oberflächen? Wenn ja, womit erstellst du diese? Mit anderen Worten: Welche guten(!) Alternativen gibt es zu Visual Basic?
MfG, Dennis.
n'Abend Dennis,
Ja, z.B. der Apache verwendet ja für seine Module auch diese shared object - wobei ich mir nicht so genau vorstellen kann wie so etwas abläuft. Wenn ich dich richtig verstanden habe ich es Sache des OS das zu implementieren und nicht Sache der Programmiersprache...
ja, das hast du richtig verstanden.
Ich mag zwar das Konzept objektorientierter Programmierung, aber ich mag es nicht, wenn eine Programmiersprache zu viel von dieser Technik vor mir verbirgt. Deswegen ist mir C++ unsympathisch und ich bilde lieber ähnliche Strukturen mit reinem C nach - da habe ich dann wenigstens die volle Kontrolle und weiß genau, was abläuft, anstatt mich auf mystische Tricks von C++ verlassen zu müssen. Und Klassen in PHP sind mir aus ganz ähnlichen Gründen suspekt.
Auf was für "Tricks" spielst du an?
Eigentlich auf alles, was "automatisch" abläuft, ohne das ich es im Detail verfolgen kann. Wenn ich in einer OO-Programmiersprache etwas wie new Object() schreibe, dann wird ohne mein Zutun (und ohne dass ich eingreifen könnte!) Speicher für das neue Objekt reserviert, dieser Speicher mit der Struktur des Objekts initialisiert, sein Konstruktor aufgerufen, evtl. implizit noch der Konstruktor der Basisklasse(n) usw. Und sowas mag ich nicht. Ich möchte lieber jeden Schritt einzeln sehen und kontrollieren können.
Sicher sind diese Automatismen praktisch, solange man den normalen Standard-Ablauf haben will. Aber wehe, man möchte mal in einzelnen Details aus diesem Schema ausbrechen. Dann bricht man sich schier einen ab - während ich in meiner Plain-C-Nachbildung (oder meinetwegen auch in Assembler) einfach eine Sprungtabelle ändere oder einen kleinen Funktionsaufruf überspringe oder ergänze.
Wie du aber bereits gesagt hast ist dieser grundliegene Unterschied in der Vorgehensweise wohl darauf zurück zu führen, mit welcher Sprache man angefangen hat zu programmieren.
Ja, davon gehe ich aus. Bei mir war's ganz am Anfang C64-Basic, damit war kein Blumentopf zu gewinnen. Dann bin ich in Assembler eingestiegen und fühlte mich wie im Programmierer-Paradies. Später war auch C nicht zu verachten, während mir, wie gesagt, C++ schon nicht mehr maschinennah genug war.
Ach ja - ich glaube dich so verstanden zu haben, dass du unter Windows das ein oder andere programmierst,
Richtig. :-)
erstellst du da auch Programme mit grafischen Oberflächen? Wenn ja, womit erstellst du diese?
Selbstverständlich. Und mein favorisiertes Entwicklungssystem für Win32 ist nach wie vor Borland C in der Version 5 aus dem Jahr 1996. Seitdem hat mich nichts wieder so überzeugen können. Die Entwicklungsumgebung ist in weiten Grenzen anpassbar, die Projektverwaltung nicht zu aufgebläht, man kann auch ohne großen Aufwand mal ein Modul in Assembler mit einbinden ...
Aber wenn du weniger maschinennah, weniger "fummelig" arbeiten möchtest, kann ich dir MS Visual C++ ans Herz legen. Mir gefällt's nicht so, weil mich diese Software schon wieder zu sehr bevormundet. Aber wir haben ja schon festgestellt, dass die Ansichten da unterschiedlich sind.
Schönen Abend noch,
Martin
Ebenfalls n'Abend Martin, ;-)
Aber wenn du weniger maschinennah, weniger "fummelig" arbeiten möchtest, kann ich dir MS Visual C++ ans Herz legen. Mir gefällt's nicht so, weil mich diese Software schon wieder zu sehr bevormundet. Aber wir haben ja schon festgestellt, dass die Ansichten da unterschiedlich sind.
Ich habe sogar MS Visual C++ 6.0 hier irgendwo rumliegen - habe ich von der Schule aus mal zusammen mit VB 6.0 bekommen. Bin gestern auf diese VC++ Einführung gestoßen von der Uni-Trier, welche mir sehr gut erscheint.
Mal schauen, vielleicht arbeite ich mich da mal ein. Wobei mir der Teil der sich mit der Erzeugung von Programmen mit grafischer Oberfläche (also richtiger Software[tm] *g*) auseinandersetzt schon recht schwierig erscheint. Interssiert wäre ich vor allem daran, Software zu erstellen, die Daten aus lokalen oder Remote-MySQL-Datenbanken abruft oder im Netzwerk tätig ist, also z.B. POST-Requests an bestimmte Websites absetzt.
MfG, Dennis.
Hallo.
-seite.php
-erstes.inc
-zweites.inc
-styles.css
In diesem Fall war es ja noch gut nachzuvollziehen, aber veröffentliche bitte bei Schwierigkeiten mit der Darstellung nur den Code, der tatsächlich beim Nutzer ankommt. Denn dort muss der Fehler liegen, und sich durch server-seitigen Code zu wühlen kostet nur Arbeit, bringt aber in diesen Fällen nichts.
MfG, at