chris_blues: generierte Inhalte einbinden

Hallo, ich mal wieder!

Ich flipp bald aus, seit Stunden durchforste ich das Netz und finde keine gescheiten Informationen, oder genauer gesagt, ich weiß mal wieder nicht, wonach ich suche... :-/

ScreenShot
Wie man auf obigem Screenie sehen kann, steckt da ein furchtbar häßlicher Scrollbalken mitten im Bild.

Ich finde keine Alternative zum iframe! Also, schön wär ein iframe, der mit dem Inhalt mitwächst!
Wär blöd, wenn ich die komplette Mutter-Html ersetzen müßte. Ist schon klar, daß ich über ein include(); die iframes einbinden könnte. Ist aber doof, weil ich gerne für den Shop ein eigenständiges CSS-file betreiben würde. Ich habs gerade den Nachmittag über probiert mit include(); aber die CSS-files passen nicht so ganz zusammen. Angefangen bei verschiedenen Standard font Größen, über <h1> & Co bis hin zu link-Farben... irgendwie doof halt...
Außerdem, besteht der Shop aus 2 php-files (shop_content.php und kart.php) die getrennt voneineinander zusammenarbeiten. Das dürfte ganz schön kniffelig werden, das zu einer php zu machen!!! 8-\

Also um es kurz zu machen, ich würde mich riesig über Stichwörter, Hinweise, Schubser in eine Richtung freuen!!! Falls mehr Info nötig ist, laßt es mich wissen!

Ach ja; zu finden in freier Wildbahn unter:
http://folkadelic.de/baustelle/neubau/index.php?page=store

Schönen Dank im Voraus und schöne Grüße!
chris

  1. Om nah hoo pez nyeetz, chris_blues!

    <es_wird_dir_nicht_gefallen>

    Ich finde keine Alternative zum iframe! Also, schön wär ein iframe, der mit dem Inhalt mitwächst!

    imho gibts den nicht. section wäre ein passendes Element.

    Wär blöd, wenn ich die komplette Mutter-Html ersetzen müßte.

    Aus Bequemlichkeit akzeptierst du eine deutlich suboptimale Lösung?

    Also um es kurz zu machen, ich würde mich riesig über Stichwörter, Hinweise, Schubser in eine Richtung freuen!!!

    Dein HTML ist grausig!
     - einzelne Bilder in einem div-Element
     - zusätzliche Elemente aus Gesatltungsgründen (div schatten, li *, ...)
     - veraltete und fehlerhaft verwendete Elemente (br, font)
     - Tabellenlayout
     - feste Breitenangaben

    </es_wird_dir_nicht_gefallen>

    Lektüre: http://blog.selfhtml.org/c/html/html5-serie/

    Je länger ich jetzt hier davor sitze, um so zögerlicher werde ich, den Beitrag abzusenden, aber ich denke, diese schonungslose Ehrlichkeit ist hilfreicher als freundliche Augenwischerei.

    Matthias

    --
    Der Unterschied zwischen Java und JavaScript ist größer als der zwischen Canna und Cannabis.

    1. Je länger ich jetzt hier davor sitze, um so zögerlicher werde ich, den Beitrag abzusenden, aber ich denke, diese schonungslose Ehrlichkeit ist hilfreicher als freundliche Augenwischerei.

      Wem gefällt schon ehrliche Kritik?? :) Aber ich freu mich trotzdem über Anregungen! Und Du hast Recht! Lieber ne harte Wahrheit als ne softe Lüge!

      Dein HTML ist grausig!

      • einzelne Bilder in einem div-Element
      • zusätzliche Elemente aus Gesatltungsgründen (div schatten, li *, ...)
      • veraltete und fehlerhaft verwendete Elemente (br, font)

      Ist da immer noch ein font drin??? Ich dachte ich hätte die ausgerottet... Bin allerdings noch im Prozess den shop aufzuräumen...

      • Tabellenlayout
      • feste Breitenangaben

      Autsch! Das muß ich erstmal kapieren, wovon Du redest! Laß mich Deinen Link studieren! :)
      Aber zum Thema feste Breitenangaben - irgendwie muß ich doch ein konsistentes Design erreichen... Für weiterführende Tips dazu wär ich auch dankbar...

      Zu meiner Verteidigung, die optische Gestaltung liegt nicht in meiner Hand! Ich versuche nur die Entwürfe technisch umzusetzen... ;)
      Was aber mein "grausiges" HTML nicht entschuldigen kann... *grübel, grummel*

      Danke trotzdem!
      chris

      1. Om nah hoo pez nyeetz, chris_blues!

        Aber zum Thema feste Breitenangaben - irgendwie muß ich doch ein konsistentes Design erreichen...

        Definiere konsistent.

        Für weiterführende Tips dazu wär ich auch dankbar...

        Sorge für ein Layout, das sich an sein Ausgabemedium anpasst. Das geht, indem man auf Breitenangaben verzichtet oder prozentuale Abmessungen angibt.

        Matthias

        --
        Der Unterschied zwischen Java und JavaScript ist größer als der zwischen Spinne und Spinner.

        1. Om nah hoo pez nyeetz, chris_blues!

          Aber zum Thema feste Breitenangaben - irgendwie muß ich doch ein konsistentes Design erreichen...

          Definiere konsistent.

          z.Bsp.
          * daß die Navi-Leiste in einer Reihe bleibt und nicht mehrspaltig daherkommt
          * daß eine etwas breitere Bildergalerie nicht das ganze Layout sprengt/rausspringt

          Ist ja alles kein Problem, solange es nur um Text geht, aber was darüber hinaus geht, bringt meiner Erfahrung nach nur herausstehende Ecken und Kanten etc mit sich...
          Die Idee, mit prozentualen Breitenangaben klingt schon mal relativ plausibel.

          ----------

          Ich würde an dieser Stelle, fürs Protokoll, durchaus einräumen, daß ich HTML-mäßig weder weit bewandert noch großartig erfahren wäre. Wäre ich ein HTML-Guru hätte ich diesen Thread nicht eröffnet. Absoluter Anfänger bin ich, glaube ich, aber auch nicht mehr. Ich bin schon ganz froh, die Umstellung auf CSS, nach meinem letzten Thread hier, halbwegs bewerkstelligt zu haben. Nur mit dem Shop hakts meiner Ansicht nach massiv. Je mehr ich lerne, umso mehr werde ich umsetzen können. Daß der Banner z.Bsp. ein eigenes <div> hat, liegt wahrscheinlich an meinem Unwissen zum Thema CSS. Ich hoffe, das wird besser werden! ;)

          Hab schonmal kurz in diesem Blog geschmökert. Sehr aufschlußreich!!! Da bringt html5 wohl viel neues mit! Da muß ich mich wohl mal ausführlicher belesen!
          Bin am Ball!

          -----------

          Back to topic:
          Du schriebst zum Thema:

          Wär blöd, wenn ich die komplette Mutter-Html ersetzen müßte.
          Aus Bequemlichkeit akzeptierst du eine deutlich suboptimale Lösung?

          Was meinst Du damit? Natürlich kann man da von Bequemlichkeit sprechen, daß ich jetzt nicht die gesamte Struktur von diesem Shop von Anfang an neu bauen will. Aber wie würdest Du denn das machen? Also so grob strukturell?
          Jetzt habe ich ja 2 frames mit jeweils einem php-file dahinter, welches mir die Daten ausspuckt.
          Ich habe heute angefangen rumzuprobieren, das ganze in 1 php-file zu quetschen und dann zu includieren, damit am Ende keine iframes mehr auftauchen. Wäre aber halt ein gigantischer Arbeitsaufwand das umzusetzen.

  2. Hallo,

    Also, schön wär ein iframe, der mit dem Inhalt mitwächst!

    Gilt der Wunsch noch? Da hätte ich eine Lösung, sofern du auch Herr über die html-Datei im iframe bist.

    Parent-Seite www.example.com/parent.htm und Child-Seite www.beispiel.de/child.htm im iframe können sich nicht gegenseitig sehen oder beeinflussen.

    Aber die child.htm im iframe kann ihre Gesamthöhe per Javascript in Pixel messen und das Ergebnis per Ajax an ihren eigenen Server www.beispiel.de melden. Der generiert davon eine beliebige (leere) Grafik mit dieser Höhe.

    Etwas zeitversetzt liest Javascrpt in parent.htm diese Grafik vom fremden Server und weiss, wie die Höhe des iframe einzustellen ist.

    Guckst du HIER

    Linuchs

    1. Hallo,

      Also, schön wär ein iframe, der mit dem Inhalt mitwächst!

      Gilt der Wunsch noch? Da hätte ich eine Lösung, sofern du auch Herr über die html-Datei im iframe bist.

      Parent-Seite www.example.com/parent.htm und Child-Seite www.beispiel.de/child.htm im iframe können sich nicht gegenseitig sehen oder beeinflussen.

      Aber die child.htm im iframe kann ihre Gesamthöhe per Javascript in Pixel messen und das Ergebnis per Ajax an ihren eigenen Server www.beispiel.de melden. Der generiert davon eine beliebige (leere) Grafik mit dieser Höhe.

      Etwas zeitversetzt liest Javascrpt in parent.htm diese Grafik vom fremden Server und weiss, wie die Höhe des iframe einzustellen ist.

      Guckst du HIER

      Linuchs

      Super! Das muß ich mal näher studieren. Hab alles Seiten auf meiner Domain, also fest in der Hand, also sollte das ja kein Problem darstellen...
      Werd ich mich morgen mal ranmachen...
      Danke
      chris

    2. Also, wenn ich mir das so ansehe, bräuchte ich nicht mal ein gif erzeugen, sondern mir nur irgendwie die Zahl hinterlegen oder? Es befindet sich ja alles auf der selben Domain. Also, im JS-Bereich:
      var hoehe = document.getElementById('ganzunten').offsetTop +65;
      und das Ganze 'onload' abgefragt. (Wobei ich mit diesem offsetTop noch ein bißchen spielen müßte)

      Das liefert mir ja die Höhe, wobei das <div id="ganzunten"> entsprechend als letztes Element im Dokument verbaut ist. Damit habe ich innerhalb des [shop_content] schonmal im JS-Bereich die Variable "hoehe". Diese könnte ich mir dann im nächsten Schritt ganz einfach per POST an ein kleines php-script schicken, was die Zahl in eine Datei schreibt. Z.Bsp. in dem Moment, wenn ich einen neuen Artikel in den Shop stelle, sich diese Größe also ändert.

      Wenn ich dann beim Aufruf des Shops diese Datei auslese, kann ich dem iframe die entsprechende Größe mitteilen.

      Fehlt hier was? Hab ich was übersehen oder falsch verstanden?

      Vielen Dank nochmals für diesen überaus nützlichen Hinweis!!!
      chris

      1. Hallo,

        du brauchst weder ein GIF noch eine Datei erzeugen. Die Höhenberechnung und das Setzen der Höhe können clientseitig erfolgen.

        <iframe src="iframe.html" onload="[code lang=javascript]this.height = this.[link:https://developer.mozilla.org/en-US/docs/Web/API/HTMLIFrameElement@title=contentDocument].[link:https://developer.mozilla.org/en-US/docs/Web/API/document.documentElement@title=documentElement].[link:https://developer.mozilla.org/en-US/docs/Web/API/element.offsetHeight@title=offsetHeight]"></iframe>[/code]

        (Einfachste Lösung.)

        Grüße,
        Mathias

        1. <iframe src="iframe.html" onload="[code lang=javascript]this.height = this.[link:https://developer.mozilla.org/en-US/docs/Web/API/HTMLIFrameElement@title=contentDocument].[link:https://developer.mozilla.org/en-US/docs/Web/API/document.documentElement@title=documentElement].[link:https://developer.mozilla.org/en-US/docs/Web/API/element.offsetHeight@title=offsetHeight]"></iframe>[/code]

          (Einfachste Lösung.)

          Grüße,
          Mathias

          Ha! Genial! Danke!
          http://folkadelic.de/baustelle/neubau/index.php?page=store

  3. Hallo,

    Wär blöd, wenn ich die komplette Mutter-Html ersetzen müßte. Ist schon klar, daß ich über ein include(); die iframes einbinden könnte. Ist aber doof, weil ich gerne für den Shop ein eigenständiges CSS-file betreiben würde.

    Die Höhe des Iframes ließe sich automatisch mit JavaScript anpassen. Dazu ist ein bisschen Event-Handling und Cross-Document-Getrickse nötig.

    Langfristig ist es sinnvoller, mit einem modularen und flexibel CSS zu arbeiten, sodass du auf Iframes verzichten kannst. So umfangreich scheint mir die Site und das zugehörige CSS nicht zu sein.

    Die unterschiedlichen Formatierungen sauber zu trennen ist bloß eine Frage von passenden Selektoren und Angriffspunkten im HTML (Elemente, IDs, Klassen…). Damit ist es möglich, in einer CSS-Datei (oder mehreren aufeinander aufbauenden, darauf kommt es nicht an) die gesamte Site zu formatieren.

    Außerdem, besteht der Shop aus 2 php-files (shop_content.php und kart.php) die getrennt voneineinander zusammenarbeiten. Das dürfte ganz schön kniffelig werden, das zu einer php zu machen!!!

    Die Organisation des PHP wird tatsächlich knifflig und erfordert einige Umbauten. Aber auch hier ist es langfristig sinnvoller, den PHP-Code zu modularisieren und wiederverwendbar zu machen, sodass du serverseitig *ein*  Dokument mit sämtlichen Inhalten generieren kannst. Der Lerneffekt wird höher sein. Es sei denn, du stehst unter Zeitdruck oder willst dich aus anderen Gründen nicht weiter in die Materie vertiefen.

    Grüße,
    Mathias

    1. Langfristig ist es sinnvoller, mit einem modularen und flexibel CSS zu arbeiten, sodass du auf Iframes verzichten kannst.

      Nur wie kann man das anstellen? Also ich habe den Ordner / . darin befindet sich die "index.php". Diese includiert "header.html", "kopf.php", "content/seite.php" und "fuss.php".
      Der Shop allerdings liegt im Verzeichnis "/shop/shop.php". Ich habe jetzt einige Zeit damit rumgespielt, und versucht das ganze ohne iframe direkt in das index.php einzubinden. Und bis auf jede Menge zerbrochener Pfade ist da nicht viel bei herausgekommen. Ja, ich kann im php-Bereich ein chdir() absetzen, aber das berührt den html-Bereich wieder nicht. Jetzt habe ich innerhalb des Shops noch ein paar Verzeichnisse, z.Bsp. "shop/conf/items_conf.php" usw. Das ist ein furchtbarer Kreislauf. Ich könnte jetzt die Pfade absoluter machen, das wäre aber eine schöne Katastrophe, wenn ich den ganzen Kram vom Verz "baustelle" in die Wurzel verschiebe!!!

      So umfangreich scheint mir die Site und das zugehörige CSS nicht zu sein.

      An sich nicht, nur der Shop ist doch etwas komplexer geworden...

      Die unterschiedlichen Formatierungen sauber zu trennen ist bloß eine Frage von passenden Selektoren und Angriffspunkten im HTML (Elemente, IDs, Klassen…). Damit ist es möglich, in einer CSS-Datei (oder mehreren aufeinander aufbauenden, darauf kommt es nicht an) die gesamte Site zu formatieren.

      Ja, das habe ich auch gehofft, zumal der Name "Kaskadierend" ja auch suggeriert, daß ich trotz alledem eine separate "/shop/shop.css" betreiben kann. Nur konnte ich noch nicht herausfinden, wie ich diese "einkaskadieren" kann. Sämtliche Dokus, Wikis etc schreiben nur davon, daß ich in ein "file.css" ein anderes einbinden kann. Aber wie kann ich diese halbwegs separat betreiben? Also, daß header, kopf, content und fuss die "folkadelic.css" benutzen, und NUR im content_shop die /shop/shop.css genutzt wird? Während auf dieser Seite immer noch header, kopf und fuss die folkadelic.css nutzen? Ist mir irgendwie rätselhaft...

      Außerdem, besteht der Shop aus 2 php-files (shop_content.php und kart.php) die getrennt voneineinander zusammenarbeiten. Das dürfte ganz schön kniffelig werden, das zu einer php zu machen!!!
      Die Organisation des PHP wird tatsächlich knifflig und erfordert einige Umbauten. Aber auch hier ist es langfristig sinnvoller, den PHP-Code zu modularisieren und wiederverwendbar zu machen, sodass du serverseitig *ein*  Dokument mit sämtlichen Inhalten generieren kannst. Der Lerneffekt wird höher sein. Es sei denn, du stehst unter Zeitdruck oder willst dich aus anderen Gründen nicht weiter in die Materie vertiefen.

      Die Entscheidung, 2 php's zu betreiben, lag vor allem darin, daß ich nicht bei jedem Klick einen riesigen Wust an Daten wälzen muß, diese auswerten, und dann am Ende noch ein maßgeschneidertes html ausspucken zu lassen. Es ist doch viel ressourcen-schonender einen separaten Warenkorb zu haben, der nichts weiter macht, als die Waren vom shop_content entgegenzunehmen mit den wichtigsten Daten; und am Ende die Bestellung einzuleiten. Nichts weiter. Während der shop_content die kompletten Waren-Daten auslesen muß, oggs suchen und audio-Playlisten erzeugen muß, Bilder zusammensuchen etc. und alle links auf den Warenkorb zeigen lassen. Das braucht der nur einmal beim ersten Aufruf des shops zu machen.
      Alles das jetzt bei jedem einzelnen Klick zu veranstalten erscheint mir "Energieverschwendung" zu sein... Aber hier wirds langsam aber sicher philosophisch, bekomm ich das Gefühl...

      Danke für Deinen Input, und laß mich bitte Deine Meinung zu meinen Punkten wissen (wenn du magst)! :)
      chris

      1. Hallo,

        Ich könnte jetzt die Pfade absoluter machen, das wäre aber eine schöne Katastrophe, wenn ich den ganzen Kram vom Verz "baustelle" in die Wurzel verschiebe!!!

        Absolute Pfade sind schon der richtige Ansatz. Eine andere (Sub-)Domain hilft hier, damit du nicht mit der aktuellen Site in Konflikt kommst.

        Webframeworks benutzen i.d.R. zentrale Funktionen, um die URLs in Links, Formularen usw. generieren. Wenn die URLs zentral generiert werden, ist es kein Problem, ein Präfix wie »/baustelle/« vor jede URL zu setzen.

        Aber wie kann ich diese halbwegs separat betreiben? Also, daß header, kopf, content und fuss die "folkadelic.css" benutzen, und NUR im content_shop die /shop/shop.css genutzt wird? Während auf dieser Seite immer noch header, kopf und fuss die folkadelic.css nutzen? Ist mir irgendwie rätselhaft...

        Das ist eine Frage der sinnvollen Verwendung von Selektoren und Regeln.

        Im Allgemeinen:

        Erzeuge wiederverwendbare HTML/CSS-Module, die auf verschiedenen Seiten / in verschiedenen Kontexten verwendet werden:

        .modul {}  
        .modul .teil-vom-modul {}
        

        Im Kontext von gewissen Seiten oder Seitenelementen kannst du diese umformatieren, beispielsweise:

        .kontext .modul {}  
        .kontext .teil-vom-modul {}
        

        Konkret:

        Formatiere den Header und darüber seine Nachfahrenelemente durch Vererbung von CSS-Eigenschaften:

        #header {}

        Formatiere gewisse Elemente im Header:

        #header h1 {}

        Formatiere den Shop und seine Nachfahrenelemente:

        .shop {}  
        .shop .foo {}
        

        Die shop-Klasse kann hier entweder an einem div, section oder direkt am body-Element hängen. Im letzten Fall lassen sich die Formatierungen für sämtliche Seitenelemente ergänzen/überschreiben:

        .shop #header {} /* Besondere Styles für den Header auf der Shop-Seite */

        Wenn du HTML & CSS so anlegst, dass es allgemeine und spezielle, überschreibende Regeln gibt, so kannst du sämtliche Formatierungen gleichzeitig laden, ohne dass sie sich in die Quere kommen. (So würde ich erst einmal arbeiten, nicht mit unterschiedlichen Dateien, die sich ausschließen.)

        Die Entscheidung, 2 php's zu betreiben, lag vor allem darin, daß ich nicht bei jedem Klick einen riesigen Wust an Daten wälzen muß, diese auswerten, und dann am Ende noch ein maßgeschneidertes html ausspucken zu lassen. Es ist doch viel ressourcen-schonender einen separaten Warenkorb zu haben, der nichts weiter macht, als die Waren vom shop_content entgegenzunehmen mit den wichtigsten Daten

        Ja, es ist in dieser Hinsicht ressourcenschonenend, in einer anderen Hinsicht vergeudet es Ressourcen. Die serverseitige Komplexität ist geringer, wenn du einfache PHP-Dateien hast, die genau für *eine* Funktion zuständig sind (»Single Responsibility Principle«). Allerdings braucht es genauso Ressourcen, diese verschiedenen Teile sauber zusammenzubringen – mit Iframes, vielen HTTP-Anfragen, mit JavaScript, redundanten CSS-Dateien usw.

        Es ist nicht falsch, Iframes zu verwenden, um nicht immer riesige Dokumente auf dem Server zusammenfügen und übertragen zu müssen. Der Ajax-Ansatz geht in dieselbe Richtung und ist mittlerweile etabliert. Letztlich ist das Erzeugen von immer neuen, großen HTML-Dokumente auf dem Server einfacher und robuster als clientseitige Magie mit Iframes, JavaScript/Ajax. Das sage ich als jemand, der hauptsächlich JavaScript-Anwendungen entwickelt.

        Grüße,
        Mathias

        1. Erstmal sorry, daß ich erst jetzt wieder hierher zurückkomme. Das echte Leben hat wieder zugeschlagen! :)
          Und Danke für Deine ausführliche Antwort!

          Wenn die URLs zentral generiert werden, ist es kein Problem, ein Präfix wie »/baustelle/« vor jede URL zu setzen.

          Ok, das versteh ich! Die URL besteht ja auch aus mehreren Teilen, die ich dann irgendwie passend erzeugen kann. ( $_SERVER["PHP_SELF"] und Kollegen )

          .modul { … }
          .modul .teil-vom-modul { … }

          Das HTML-mäßige Gegenstück wäre dann z.Bsp.:  
          <div class="modul" class="teil-vom-modul">...</div> ???  
          Kann man das machen? Mehrere class-Kennungen in einem Tag? Oder müßte ich das dann verschachteln? Also:  
          <div class="modul"><div class="teil-vom-modul">...</div></div>  
            
            
          
          > Wenn du HTML & CSS so anlegst, dass es allgemeine und spezielle, überschreibende Regeln gibt, so kannst du sämtliche Formatierungen gleichzeitig laden, ohne dass sie sich in die Quere kommen. (So würde ich erst einmal arbeiten, nicht mit unterschiedlichen Dateien, die sich ausschließen.)  
          
          Ok, macht durchaus Sinn. Jetzt muß ich es nur noch umsetzen! :)  
          Das habe ich auch schon des Öfteren gelesen, dieses Überschreiben von Regeln, Vererben etc. Jetzt wird mir erst deutlich wozu das Ganze gut sein soll!  
            
          Vielen Dank für Deine Ausführungen und Beispiele!  
            
          Schöne Grüße  
          chris
          
          1. Hallo,

            Mehrere class-Kennungen in einem Tag? Oder müßte ich das dann verschachteln?

            Weder noch. Einem Klassenattribut mehrere Klassen zuweisen.

            Gruß
            Kalk

            1. Weder noch. Einem Klassenattribut mehrere Klassen zuweisen.

              Laut http://de.selfhtml.org/css/formate/zentrale.htm#klassen@title=selfhtml.org wäre das dann eher so etwas?

              CSS:
              .modul .teil-vom-modul { … }
              HTML:
              <div class="modul teil-vom-modul">...</div>

              Mehrere Definitionen mit Leerzeichen getrennt. Korrekt?

              1. Hallo,

                Weder noch. Einem Klassenattribut mehrere Klassen zuweisen.
                Laut http://de.selfhtml.org/css/formate/zentrale.htm#klassen@title=selfhtml.org wäre das dann eher so etwas?

                CSS:
                .modul .teil-vom-modul { … }
                HTML:
                <div class="modul teil-vom-modul">...</div>

                Mehrere Definitionen mit Leerzeichen getrennt. Korrekt?

                nein, sowohl dein CSS-Beispiel, als auch dein HTML-Beispiel sind syntaktisch korrekt. Aber sie passen nicht zueinander.

                In CSS ist das Leerzeichen der Nachfahrenselektor (richtiger: "Kombinator"). Dein Beispiel ...

                .modul .teil-vom-modul {}

                ... passt also auf ein Element mit der Klasse "teil-vom-modul", das sich irgendwo innerhalb eines anderen Elements mit der Klasse "modul" befindet. Willst du ein Element selektieren, das beiden Klassen angehört, darfst du kein Leerzeichen dazwischen notieren.

                Im Markup sieht das wieder anders aus: Soll ein Element mehreren Klassen angehören, werden die Klassennamen einfach durch Leerzeichen getrennt als Wert des class-Attributs aufgezählt.

                Was in deinem Fall richtig bzw. richtiger ist, weiß ich nicht; ich habe den Threadanfang nicht intensiv gelesen. Ich kann dich nur ermutigen: Lerne und verstehe die Grundlagen - sowohl in HTML, als auch in CSS.

                Ciao,
                 Martin

                --
                Es gibt Tage, da gelingt einem einfach alles.
                Aber das ist kein Grund zur Sorge; das geht vorbei.
                Selfcode: fo:) ch:{ rl:| br:< n4:( ie:| mo:| va:) de:] zu:) fl:{ ss:) ls:µ js:(
              2. Die ausführliche Erläuterung von Der Martin habe ich mal schnell in ein Beispiel gepackt.
                Ich hoffe das trägt zum besseren Verständnis des Nachfahrenselektors bei!

                1. Die ausführliche Erläuterung von Der Martin habe ich mal schnell in ein Beispiel gepackt.
                  Ich hoffe das trägt zum besseren Verständnis des Nachfahrenselektors bei!

                  Sehr informativ! Danke Martin und Martin!
                  Da fang ich langsam an zu kapieren, wieso das "kaskadierend" heißt... :)

                  Schöne Grüße
                  chris