Tobald: Tabellenlayout

Hallo Leute,

ich versuche grad eine hp mit tabellenlayout zu erstellen.

code:

<body>
<table border="2" cellpadding="0" cellspacing="0">

<tr>
    <td rowspan="2"><img src="images/logo.gif" width="200"></td>
    <td>
 <?PHP
 include('menu.php');
 ?>
    </td>
  </tr>

<tr>
    <td></td>
    <td rowspan="2">
        <?PHP
 include('inhalt.php');
 ?>
    </td>
  </tr>
  <tr>
    <td>
 <?PHP
 include('menu2.php');
 ?>
    </td>
    <td></td>
  </tr>
</table>
</body>

und zum veranschaulichen hab ich noch ein bild (http://img396.imageshack.us/img396/5789/hpsv3.jpg) gemalt in dem dass problem gut beschrieben ist.
ich hoffe jemand sieht meinen fehler, ich tus nicht.
danke schonmal und gruß.t.

  1. hallo,

    ich versuche grad eine hp mit tabellenlayout zu erstellen.

    Laß es lieber. Tabellen sind für tabnellarische Daten da, aber auf gar keinen Fall für irgendwas, was du dir eventuell als Layout vorstellst.

    Grüße aus Berlin

    Christoph S.

    --
    Visitenkarte
    ss:| zu:) ls:& fo:) va:) sh:| rl:|
    1. Christoph S.

      Hallo Christoph. Etwas OT: weißt du, wann man erreichen kann, auch ein CSS Layout für dynamische Menüs zu erstellen, deren Breite man nicht kennt, sodass man kein festes margin vergeben kann, weil der Inhalt dynamisch generiert wird?

      1. hallo,

        weißt du, wann man erreichen kann, auch ein CSS Layout für dynamische Menüs zu erstellen, deren Breite man nicht kennt, sodass man kein festes margin vergeben kann, weil der Inhalt dynamisch generiert wird?

        Ich bin mir nicht sicher, ob ich dich richtig verstehe. Wie soll denn der Inhalt generiert werden? Über PHP? Über Javascript? In beiden Fällen kennst du aber die Maximalbreite, die erreicht werden könnte.

        Grüße aus Berlin

        Christoph S.

        --
        Visitenkarte
        ss:| zu:) ls:& fo:) va:) sh:| rl:|
        1. hallo,

          weißt du, wann man erreichen kann, auch ein CSS Layout für dynamische Menüs zu erstellen, deren Breite man nicht kennt, sodass man kein festes margin vergeben kann, weil der Inhalt dynamisch generiert wird?

          Ich bin mir nicht sicher, ob ich dich richtig verstehe. Wie soll denn der Inhalt generiert werden? Über PHP?

          Zum Beispiel.

          In beiden Fällen kennst du aber die Maximalbreite, die erreicht werden könnte.

          Erstens nein und zweitens: selbst wenn, was hat das damit zu tun? Das Design der Seite hat nichts mit meinem PHP Code zu tun. Absolut _nichts_ in meinem PHP Code darf etwas mit Design zu tun haben. PHP ist für das Verarbeiten und Ausgeben von Daten zuständig, die Content sind. Mit Design hat PHP nix zu tun.
          Bei Javascript gilt das gleiche.
          Abgesehen davon. Wieso muss ich mir das ganze so kompliziert machen, wieso nicht ganz einfach mit CSS? Wie wäre es denn damit, dass man in CSS automatisch Variablen der Werte anderer Elemente mit einer ID hat.

          Z.B. so:

          ------------ (CSS)
          #content
          {
              width: 100% - #navigation.width;
          }
          ------------ (HTML)
          <div id="navigation">
              ...
          </div>

          <div id="content">
              ...
          </div>
          ------------

          Naja, es wird wohl ein Traum bleiben und ich werde weiterhin Code und Design vermischen müssen oder mit einer ggf. zu kleinen oder zu großen Navigation leben müssen.

          1. hallo,

            PHP ist für das Verarbeiten und Ausgeben von Daten zuständig, die Content sind. Mit Design hat PHP nix zu tun.
            Bei Javascript gilt das gleiche.

            Richtig - allerdings weißt du, wieviele Buchstabem der längstmögliche Eintrag hat. Also kannst du ausrechnen oder eventuell mit einem Pixellineal nachmessen, welche Maxiamlbreite aufgrund deiner CSS erreichbar ist.

            Wie wäre es denn damit, dass man in CSS automatisch Variablen der Werte anderer Elemente mit einer ID hat.

            Mir ist nicht bekannt, daß es in CSS Variablen gäbe.

            Ich löse das Ganze über mehrere PHP-Arrays. Das siehst du an meiner Seite zwar nicht, aber die CSS kannst du dir anschauen.

            Grüße aus Berlin

            Christoph S.

            --
            Visitenkarte
            ss:| zu:) ls:& fo:) va:) sh:| rl:|
            1. hallo,

              PHP ist für das Verarbeiten und Ausgeben von Daten zuständig, die Content sind. Mit Design hat PHP nix zu tun.
              Bei Javascript gilt das gleiche.

              Richtig - allerdings weißt du, wieviele Buchstabem der längstmögliche Eintrag hat. Also kannst du ausrechnen oder eventuell mit einem Pixellineal nachmessen, welche Maxiamlbreite aufgrund deiner CSS erreichbar ist.

              Ja, das kann ich ausrechnen. Bewirke ich mit dieser Rechnung eine Änderung am Inhalt? Nein? Dann darf ich es nicht tun. Für die Darstellung ist _ausschließlich_ CSS zuständig und sonst nichts. Einfach gar nichts. Außer vielleicht Flash, damit kenn ich mich nicht aus, das ist ja aber auch eine Welt für sich.

              Wie wäre es denn damit, dass man in CSS automatisch Variablen der Werte anderer Elemente mit einer ID hat.

              Mir ist nicht bekannt, daß es in CSS Variablen gäbe.

              Ja, deswegen nutzte ich Konjunktiv. Würde ich dem W3C angehören, würde ich so etwas vorschlagen. Ich weiß allerdings nicht, ob es da Probleme gäbe, z.B. in der Performance, sodass es nicht möglich ist. Deswegen habe ich hier gefragt. Ich wäre auch dafür, das selektieren von Elementen oberhalb im DOM zu erlauben (Also das Gegenteil von "#element:hover #kindelement{}"), was aber zu rechenlastig wäre, laut Mozilla.

              1. Ich wäre auch dafür, das selektieren von Elementen oberhalb im DOM zu erlauben (Also das Gegenteil von "#element:hover #kindelement{}"), was aber zu rechenlastig wäre, laut Mozilla.

                was kommt als nächster, bsp-trees oder octree verkehrtherum auslesen?

                ich kann mir gut vorstellen, dass das zu performancelastig ist - ein baum wirde grade deshalb verwendet WEIL er performance spart und man die einzelnen äste getrennt berechnen kann

                durch "eltern > kind" und "kind < eltern"-selektoren könnte man quasi endlosschleifen produzieren, diese müsste der parser/browser erstmal vermeiden - und logiken um gewollte und nicht gewollte rekursionen zu erkennen und zu vermeiden sind meisten sehr performancelastig

                1. Ich wäre auch dafür, das selektieren von Elementen oberhalb im DOM zu erlauben (Also das Gegenteil von "#element:hover #kindelement{}"), was aber zu rechenlastig wäre, laut Mozilla.

                  was kommt als nächster, bsp-trees oder octree verkehrtherum auslesen?

                  ich kann mir gut vorstellen, dass das zu performancelastig ist - ein baum wirde grade deshalb verwendet WEIL er performance spart und man die einzelnen äste getrennt berechnen kann

                  durch "eltern > kind" und "kind < eltern"-selektoren könnte man quasi endlosschleifen produzieren, diese müsste der parser/browser erstmal vermeiden - und logiken um gewollte und nicht gewollte rekursionen zu erkennen und zu vermeiden sind meisten sehr performancelastig

                  Wie gesagt, das kann sein, damit habe ich mich nicht näher beschäftigt. Mein Vorschlag mit den Variablen innerhalb von CSS wäre allerdings imho klasse, weil man damit viele momentan nicht zu lösende Probleme bewältigen könnte.
                  Z.B. ein Footer, der immer ganz unten auf einer Seite ist, egal wieviel Inhalt es gibt und wie groß das Browserfenster ist. Oder auch zwei Spalten, die gleich lang sind, wie bei einer Tabelle eben.

                  Denn: für mich bedeutet HTML eben die Auszeichnung des Inhalts. Das bedeutet, dass bestimmte Teile des inhalts unterschiedlich klassifiziert werden. Nicht mehr und nicht weniger. Wenn man gutes HTML schreibt, sollte die Faustregel imho sein, dass man einem Fremden erklären kann, welches Element bzw. welche Attribute welchen Inhalt wie hervorheben oder klassifizieren.

                  Leere <div> Elemente darf es deshalb imho auch nicht geben.

                  1. Leere <div> Elemente darf es deshalb imho auch nicht geben.

                    man kann mit css fürchterlich viel machen - feststehende footer am seitenende usw sind kein problem - das problem sind leider immer wieder nicht standardkonforme browser - auch leere elemente sind ansich nicht nötig

                    zum thema variablen: jein, für farben und allgemeine defintionen wärs zb praktisch

                    solche "schreibweisen" wären in manchen fällen sehr praktisch:
                    //variable1// = red
                    h1 { color: //variable1//; }
                    h2 { border: //variable1//; }
                    h2 { background: //variable1//; }

                    1. Leere <div> Elemente darf es deshalb imho auch nicht geben.

                      man kann mit css fürchterlich viel machen - feststehende footer am seitenende usw sind kein problem - das problem sind leider immer wieder nicht standardkonforme browser - auch leere elemente sind ansich nicht nötig

                      Echt? Hast du da mal einen Link? Ich kenne nur Varianten mit mindestens einem leeren Element.

                      zum thema variablen: jein, für farben und allgemeine defintionen wärs zb praktisch

                      solche "schreibweisen" wären in manchen fällen sehr praktisch:
                      //variable1// = red
                      h1 { color: //variable1//; }
                      h2 { border: //variable1//; }
                      h2 { background: //variable1//; }

                      Ich behelfe mir dabei normalerweise so, dass ich meine CSS Datei immer mit solchen Variablen schreibe und diese Variablen vor dem Upload von einem kleinen Script ersetzen lasse.

                    2. @@suit:

                      zum thema variablen: jein, für farben und allgemeine defintionen wärs zb praktisch

                      solche "schreibweisen" wären in manchen fällen sehr praktisch:
                      //variable1// = red
                      h1 { color: //variable1//; }
                      h2 { border: //variable1//; }
                      h2 { background: //variable1//; }

                      Wir können auch anders.

                      Live long and prosper,
                      Gunnar

                      --
                      Erwebsregel 208: Manchmal ist das einzige, was gefährlicher als eine Frage ist, eine Antwort.
                      1. Wir können auch anders.
                        das ist mir durchaus klar - darum habe ich ja das obrige beispiel gewählt (und mich vertippt ;)

                        h1, h2, h3 {
                          color: red;
                          border: red;
                          background: red;
                        }

                        ist etwas anderes wie

                        h1 { color: red; }
                        h2 { border: red; }
                        h3 { background: red; }

                        je zerpflückter farbgemeinsamkeiten in einem design werden, desto schwieriger ist es, noch vernünftig gemeinsam mit css zu formatieren

                        da hilft dann oft nur noch find & replace in einem editor oder das serverseitige generieren von css-files - praktisch wären variablen in css dadurch trotzdem, aber notwendig wahrscheinlich nicht, da es ja workarounds gibt

                        phpbb3 nutzt zb ein derartiges system - ein art mini template-parser fürs css-file um grafikpfade oder farben zu definieren

                  2. Hi,

                    Mein Vorschlag mit den Variablen innerhalb von CSS wäre allerdings imho klasse, weil man damit viele momentan nicht zu lösende Probleme bewältigen könnte.

                    Die da waeren?

                    Z.B. ein Footer, der immer ganz unten auf einer Seite ist, egal wieviel Inhalt es gibt und wie groß das Browserfenster ist.

                    Wie suit schon sagte, eigentlich kein Argument.

                    Oder auch zwei Spalten, die gleich lang sind, wie bei einer Tabelle eben.

                    Ebenfalls moeglich - display kennt diverse "table-"-Auspraegungen.

                    Denn: für mich bedeutet HTML eben die Auszeichnung des Inhalts. Das bedeutet, dass bestimmte Teile des inhalts unterschiedlich klassifiziert werden. Nicht mehr und nicht weniger. Wenn man gutes HTML schreibt, sollte die Faustregel imho sein, dass man einem Fremden erklären kann, welches Element bzw. welche Attribute welchen Inhalt wie hervorheben oder klassifizieren.

                    Schoen und gut, erklaert aber nicht, wofuer man in CSS "Variablen" brauchen sollte.
                    Damit wuerdest du naemlich CSS von einer Formatierungs- zu einer (rudimentaeren) Programmiersprache machen wollen. Das ist aber bloedsinnig, weil es solche erstens bereits zur Genuege gibt, und diese zweitens sehr gut mit CSS "zusammenarbeiten". Sowohl serverseitig (dynamische Generierung von CSS-Code, wenn erforderlich), als auch clientseitig (Manipulation von CSS-Eigenschaftswerten per style-Objekt, dynamische Generierung/Manipulation von CSS-Regeln, ...)

                    MfG ChrisB

                    --
                    "The Internet: Technological marvel of marvels - but if you don't know *what* you're lookin' for on the Internet, it is nothing but a time-sucking vortex from hell."
                    1. Hi,

                      Mein Vorschlag mit den Variablen innerhalb von CSS wäre allerdings imho klasse, weil man damit viele momentan nicht zu lösende Probleme bewältigen könnte.

                      Die da waeren?

                      Z.B. ein Footer, der immer ganz unten auf einer Seite ist, egal wieviel Inhalt es gibt und wie groß das Browserfenster ist.

                      Wie suit schon sagte, eigentlich kein Argument.

                      Oder auch zwei Spalten, die gleich lang sind, wie bei einer Tabelle eben.

                      Ebenfalls moeglich - display kennt diverse "table-"-Auspraegungen.

                      Achja? Auch wenn diese Spalten in keinerlei logischem Zusammenhang stehen? Ganz sicher nicht.

                      Denn: für mich bedeutet HTML eben die Auszeichnung des Inhalts. Das bedeutet, dass bestimmte Teile des inhalts unterschiedlich klassifiziert werden. Nicht mehr und nicht weniger. Wenn man gutes HTML schreibt, sollte die Faustregel imho sein, dass man einem Fremden erklären kann, welches Element bzw. welche Attribute welchen Inhalt wie hervorheben oder klassifizieren.

                      Schoen und gut, erklaert aber nicht, wofuer man in CSS "Variablen" brauchen sollte.

                      Nein, das soll es auch nicht erklären. Und es soll auch nicht den Ursprung des Universums oder den Sinn des Lebens erklären.

                      Damit wuerdest du naemlich CSS von einer Formatierungs- zu einer (rudimentaeren) Programmiersprache machen wollen.

                      Das wird schon das W3C für mich machen. Guck mal in den CSS Spezifikationen.

                      1. Achja? Auch wenn diese Spalten in keinerlei logischem Zusammenhang stehen? Ganz sicher nicht.

                        dann gehts aber mit tabellen auch nicht - der logische zusammenhang von gleich langen tabellenspalten IST das gemeinsame elternelement <tr /> und dessen gemeinsames eltern element <table />

                        zwischen
                        <table>
                          <tr>
                            <td></td>
                            <td></td>
                          </tr>
                        </table>

                        und

                        <div>
                          <div style="display: table-row;">
                            <div style="display: table-cell;"></div>
                            <div style="display: table-cell;"></div>
                          </div>
                        </div>

                        ist ansich nicht viel unterschied (mit ausnahme der semantik hinter einer tabelle und thead/tbody/tfoot)

                        Nein, das soll es auch nicht erklären. Und es soll auch nicht den Ursprung des Universums oder den Sinn des Lebens erklären.

                        warum sollte man das auch - die frage nach dem leben, dem universum und dem ganzen rest wird schon klar durch "42" beantwortet

                        Damit wuerdest du naemlich CSS von einer Formatierungs- zu einer (rudimentaeren) Programmiersprache machen wollen.
                        Das wird schon das W3C für mich machen. Guck mal in den CSS Spezifikationen.

                        eine deklaratiosnsprache ist eine programmiersprache, wenn auch sehr sehr einfach gestrickt - die frage ist aber, wo man grenzen zieht

                        ist ein nachfahren-selektor ausreichen, oder pseudoklassen die auf benutzer"eingaben" reagieren  wie etwa :hover oder ist :nth-child schon zu kompliziert für eine style-sheet-sprache?

                        1. Mahlzeit suit,

                          ist ein nachfahren-selektor ausreichen, oder pseudoklassen die auf benutzer"eingaben" reagieren  wie etwa :hover oder ist :nth-child schon zu kompliziert für eine style-sheet-sprache?

                          Diese Pseudoklassen reagieren in keinster Weise auf irgendwas. Sie definieren nur, wie ein Browser Elemente, die bestimmte Eigenschaften haben oder sich in einem bestimmten Kontext oder Zustand befinden, darstellen soll.

                          MfG,
                          EKKi

                          --
                          sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|
                          1. auf benutzer"eingaben" reagieren

                            Diese Pseudoklassen reagieren in keinster Weise auf irgendwas. Sie definieren nur, wie ein Browser Elemente, die bestimmte Eigenschaften haben oder sich in einem bestimmten Kontext oder Zustand befinden, darstellen soll.

                            das ist mir nach dem abschicken auch klar geworden, dass die hochkommas um "reagieren" gehört hätten ;D

                        2. Achja? Auch wenn diese Spalten in keinerlei logischem Zusammenhang stehen? Ganz sicher nicht.

                          dann gehts aber mit tabellen auch nicht - der logische zusammenhang von gleich langen tabellenspalten IST das gemeinsame elternelement <tr /> und dessen gemeinsames eltern element <table />

                          Nur weil Tabellen (wie kommst du überhaupt darauf?) das nicht können, sollte es mit CSS auch nicht gehen? ôO

                          eine deklaratiosnsprache ist eine programmiersprache, wenn auch sehr sehr einfach gestrickt - die frage ist aber, wo man grenzen zieht

                          ist ein nachfahren-selektor ausreichen, oder pseudoklassen die auf benutzer"eingaben" reagieren  wie etwa :hover oder ist :nth-child schon zu kompliziert für eine style-sheet-sprache?

                          Ich finde schon. Und ich finde es gut so, denn um zu Designen muss man auch rechnen und Bedingungen stellen, etc.

                          1. Nur weil Tabellen (wie kommst du überhaupt darauf?) das nicht können, sollte es mit CSS auch nicht gehen? ôO

                            deine aussage war folgende

                            Achja? Auch wenn diese Spalten in keinerlei logischem Zusammenhang stehen? Ganz sicher nicht.

                            wenn du zwei voneinander getrennte tabellen hast, deren spalten in keinem logischen zusammehang stehen, ist es auch mit tabellen nicht möglich, gleich-lange spalten zu erzeugen

                            wenn diese in einer beziehung zueinander stehen ist es sowohl mit css alsauch mit tabellen möglich, wobei tabellen fürs layout die schlechter wahl sind

                            Ich finde schon. Und ich finde es gut so, denn um zu Designen muss man auch rechnen und Bedingungen stellen, etc.

                            sagt ja auch keiner, aber die möglichkeiten sind imho ausreichend, lediglich die browser sind zu dämlich

                          2. Hi,

                            [...] denn um zu Designen muss man auch rechnen und Bedingungen stellen, etc.

                            Noch mal: Clienseitige Scriptsprachen existieren.

                            MfG ChrisB

                            --
                            "The Internet: Technological marvel of marvels - but if you don't know *what* you're lookin' for on the Internet, it is nothing but a time-sucking vortex from hell."
                            1. Hi,

                              [...] denn um zu Designen muss man auch rechnen und Bedingungen stellen, etc.

                              Noch mal: Clienseitige Scriptsprachen existieren.

                              Noch mal: diese sollten nicht zum Designen verwendet werden.

                              1. Yerf!

                                Noch mal: Clienseitige Scriptsprachen existieren.

                                Noch mal: diese sollten nicht zum Designen verwendet werden.

                                Sondern was? Pinsel und Farbe? Dann zieh mal los und beschmier die Monitore deiner Besucher, du wirst schon sehen was du davon hast...

                                Das was du forderst *ist* eine clientseitige Scriptsprache, egal ob du sie jetzt css oder irgendwie anders nennst...

                                Gruß,

                                Harlequin

                                --
                                <!--[if IE]>This page is best viewed with a webbrowser. Get one today!<![endif]-->
                                1. Yerf!

                                  Noch mal: Clienseitige Scriptsprachen existieren.

                                  Noch mal: diese sollten nicht zum Designen verwendet werden.

                                  Sondern was? Pinsel und Farbe? Dann zieh mal los und beschmier die Monitore deiner Besucher, du wirst schon sehen was du davon hast...

                                  Das was du forderst *ist* eine clientseitige Scriptsprache, egal ob du sie jetzt css oder irgendwie anders nennst...

                                  Mit den clientseitigen Skriptsprachen war z.B. Javascript gemeint - nicht aber CSS. Da das Design aber ausschließlich über CSS definiert werden soll, darf Javascript nicht verändert werden.

                                  Oder mal konkret:
                                  Nur weil man zwei unabhängige Spalten nicht mittels CSS gleich groß machen kann, sollte man nicht Javascript zweckentfremden sondern CSS erweitern.

                              2. @@Tannenbaum:

                                Noch mal: Clienseitige Scriptsprachen existieren.

                                Noch mal: diese sollten nicht zum Designen verwendet werden.

                                Äh, wie bitte? Wie willst du auf clientseitige Gegebenheiten (Viewportgröße, Schriftgröße etc.) reagieren, wenn nicht mit einer clientseitigen Scriptsprache – also JavaScript?

                                Dass damit „nur“ Feinschliff vorgenommen werden sollte und die Seite auch ohne diesen recht ansehnlich sein sollte, steht natürlich außer Frage.

                                Live long and prosper,
                                Gunnar

                                --
                                Erwebsregel 208: Manchmal ist das einzige, was gefährlicher als eine Frage ist, eine Antwort.
                                1. @@Tannenbaum:

                                  Noch mal: Clienseitige Scriptsprachen existieren.

                                  Noch mal: diese sollten nicht zum Designen verwendet werden.

                                  Äh, wie bitte? Wie willst du auf clientseitige Gegebenheiten (Viewportgröße, Schriftgröße etc.) reagieren, wenn nicht mit einer clientseitigen Scriptsprache – also JavaScript?

                                  CSS hat gefälligst darauf zu reagieren, solange es nur eine Änderung im Design ist und nichts mit einer Änderung des Inhalts zu tun hat. Daher muss die Funktionalität von CSS auch noch stark erweitert werden, sodass es nicht mehr notwendig ist, Javascript zu verwenden.

                                  1. Hallo.

                                    CSS hat gefälligst darauf zu reagieren, solange es nur eine Änderung im Design ist und nichts mit einer Änderung des Inhalts zu tun hat. Daher muss die Funktionalität von CSS auch noch stark erweitert werden, sodass es nicht mehr notwendig ist, Javascript zu verwenden.

                                    Am Ende hat man dann einen Teil von Javascript in CSS 4.0 umgetauft und nichts ist gewonnen, außer natürlich deiner Genugtuung, kein Javascript eingesetzt zu haben.
                                    MfG, at

                                    1. Hi,

                                      Am Ende hat man dann einen Teil von Javascript in CSS 4.0 umgetauft und nichts ist gewonnen

                                      Im Gegenteil, das waere "Back to the roots" ...

                                      http://aktuell.de.selfhtml.org/archiv/doku/7.0/tfbd.htm

                                      MfG ChrisB

                                      --
                                      "The Internet: Technological marvel of marvels - but if you don't know *what* you're lookin' for on the Internet, it is nothing but a time-sucking vortex from hell."
                                      1. Hallo.

                                        Am Ende hat man dann einen Teil von Javascript in CSS 4.0 umgetauft und nichts ist gewonnen

                                        Im Gegenteil, das waere "Back to the roots" ...

                                        Und das hieltest du für erstrebenswert? Oder verstehst du unter dem "Gegenteil" etwas anderes als das Gegenteil?
                                        MfG, at

                                        1. Hi,

                                          Am Ende hat man dann einen Teil von Javascript in CSS 4.0 umgetauft und nichts ist gewonnen

                                          Im Gegenteil, das waere "Back to the roots" ...

                                          Und das hieltest du für erstrebenswert?

                                          Natuerlich nicht - das Konzept war ziemlicher Murks.

                                          Oder verstehst du unter dem "Gegenteil" etwas anderes als das Gegenteil?

                                          Mir ging's nur darum, dass das kein "Fortschritt" waere, was eine von dir gewaehlte Versionsnummer CSS 4.0 irgendwie andeutet - sondern viel frueher schon mal ein Rohrkrepierer war ...

                                          MfG ChrisB

                                          --
                                          "The Internet: Technological marvel of marvels - but if you don't know *what* you're lookin' for on the Internet, it is nothing but a time-sucking vortex from hell."
                                  2. CSS hat gefälligst darauf zu reagieren, solange es nur eine Änderung im Design ist und nichts mit einer Änderung des Inhalts zu tun hat. Daher muss die Funktionalität von CSS auch noch stark erweitert werden, sodass es nicht mehr notwendig ist, Javascript zu verwenden.

                                    Wird CSS jemals Javascript ersetzen?

                                    Ein Vergleich:
                                    Perl kann ^^alles^^.
                                    Verzichten Autoren deshalb auf Module?

                                    So wird es mit CSS 7.0, das alles kann, sein. Javascript wird verwendet werden, weil niemand diese Komplexität ernstlich selbst schreiben will. Statt dessen setzt man auf dynamische Bibliotheken.

                                    Ich sehe allerdings Bedarf für Erweiterungen.
                                    Zum Beispiel wird kaum jemand den Sinn von rem bezweifeln.
                                    Auch :target wird uns verlässliche Popups geben.

                                    Aber alles ist wiederum relativ, wenn man bedenkt, dass man immer auch ältere Useragents (Ich spreche nicht nur von Browser) unterstützen soll.
                                    In einem Raum, wo man mit einer Sprache unendlich viele Interpreter bedienen muss, herrschen andere Regeln als etwa in Perl oder PHP.
                                    Und darum werden uns rem und :target zu Beginn gar nicht so viel nützen.

                                    Ein Vergleich:
                                    Perl6 wird nicht abwärtskompatibel sein.

                                    Für CSS oder Javascript ist ein solcher Sprung undenkbar. CSS hat alle Fehler der Vergangenheit aufrecht zu erhalten. Und genau das wird eine logische Entwicklung in Zukunft stark verhindern.
                                    Darum glaube ich nicht, dass es die Mehrzahl der jetzt vorgeschlagenen CSS Module Standard werden.

                                    Alle Ausgaben ausser Screen haben im CSS ein Stiefmütterchen-Dasein. Die Screen-Orientierung macht uns blind dafür, was CSS eigentlich soll.
                                    Aber Umsetzungen anderer Medien ist gleichwohl problematisch. Ich weiss ja noch nicht einmal, wie ich für einen Bildschirm ^^designen^^ soll, der grösser als der meinige ist. Ich kann nur schreiben, was ich auch kontrollieren kann.
                                    Selbst wenn wir andere Lösungen wie grid in CSS haben, kann dies diesen spezifischen Mangel nicht aufheben.

                                    Aus dem gesamten kann ich nur schliessen:
                                    Keep it simple stupid.

                                    mfg Beat

                                    --
                                    Selber klauen ist schöner!
                                    1. Hallo.

                                      CSS hat alle Fehler der Vergangenheit aufrecht zu erhalten.

                                      Das bezweifele ich, denn zum einen fehlen schon heute Teile von CSS 2.0 in CSS 2.1, und zum zweiten ist auch analog zu @media eine Erweiterung der Art @version in Verbindung mit @import denkbar. Damit ließe sich CSS unter der Bedingung einbinden, dass der Browser mit dieser Version umgehen kann, während ansonsten einfach der Rest der CSS-Ressource verarbeitet würde. -- Und das ist natürlich nur eine von zahlreichen Möglichkeiten.

                                      Alle Ausgaben ausser Screen haben im CSS ein Stiefmütterchen-Dasein.

                                      Das hat aber zunächst wenig mit CSS zu tun, sondern mit der Unterstützung durch die Software-Industrie.

                                      Ich weiss ja noch nicht einmal, wie ich für einen Bildschirm ^^designen^^ soll, der grösser als der meinige ist. Ich kann nur schreiben, was ich auch kontrollieren kann.

                                      Es verlangt dem Designer sicher viel ab, sich in die Lage anderer Nutzer zu versetzen, aber genau diese Fähigkeit ist sicher einer der wichtigen Unterschiede zwischen Designern und "Designern".

                                      Aus dem gesamten kann ich nur schliessen:
                                      Keep it simple stupid.

                                      Das würde ich gern erweitern: Mache es so einfach wie möglich, aber keinesfalls einfacher.
                                      MfG, at

                                2. Hallo Gunnar,

                                  Äh, wie bitte? Wie willst du auf clientseitige Gegebenheiten (Viewportgröße, Schriftgröße etc.) reagieren, wenn nicht mit einer clientseitigen Scriptsprache – also JavaScript?

                                  Media Queries? ;)

                                  Tim

                    2. Hallo,

                      Schoen und gut, erklaert aber nicht, wofuer man in CSS "Variablen" brauchen sollte.

                      Ganz banal für Styleguides, Farben aus einer Palette, die man nicht immer wieder wiederholen will, etc. Sieh's nicht als Variablen sondern als Konstanten, die im Präprozessor eingesetzt werden.

                      Dieser Vorschlag fliegt derzeit in der CSS WG rum und soll wohl „mit Vorzug“ behandelt werden. Es soll auch schon Implementierungen dazu geben.

                      Damit wuerdest du naemlich CSS von einer Formatierungs- zu einer (rudimentaeren) Programmiersprache machen wollen.

                      Variablen machen noch keine Programmiersprache.

                      Tim

                      1. Hi,

                        Schoen und gut, erklaert aber nicht, wofuer man in CSS "Variablen" brauchen sollte.

                        Ganz banal für Styleguides, Farben aus einer Palette, die man nicht immer wieder wiederholen will, etc. Sieh's nicht als Variablen sondern als Konstanten, die im Präprozessor eingesetzt werden.

                        Das kann, wie schon erwaehnt wurde, bspw. auch der bekannte HyperText PreProcessor (a.k.a. PHP), bzw. jede andere serverseitige Technik, erledigen.

                        MfG ChrisB

                        --
                        "The Internet: Technological marvel of marvels - but if you don't know *what* you're lookin' for on the Internet, it is nothing but a time-sucking vortex from hell."
                        1. Hallo Chris,

                          Das kann, wie schon erwaehnt wurde, bspw. auch der bekannte HyperText PreProcessor (a.k.a. PHP), bzw. jede andere serverseitige Technik, erledigen.

                          Trotz der Vielzahl an Hauptschülern steht damit nicht jeder auf gutem Fuss, manmuß es kennen. Insofern ist eine vereinheitlichte Syntax – denk an eine DSL - durchaus sehr praktisch, egal, ob die nun im Browser oder auf dem Server ausgeführt wird. Ich bevorzuge Browser, da nicht immer eine Server-Umgebung für alle Anwendungsfälle von CSS bereit steht.

                          Auf dem Server gibt es schon eine (leicht erweiterte) Lösung und in aktuellen WebKit Nightlies kann man das ganze mit -webkit-Präfixen schon ausprobieren. Der Großteil der Tests klappt wunderbar.

                          Tim

              2. hallo,

                allerdings weißt du, wieviele Buchstabem der längstmögliche Eintrag hat. Also kannst du ausrechnen oder eventuell mit einem Pixellineal nachmessen, welche Maxiamlbreite aufgrund deiner CSS erreichbar ist.
                Ja, das kann ich ausrechnen. Bewirke ich mit dieser Rechnung eine Änderung am Inhalt?

                Natürlich nicht, aber jetzt trittst du dir selber in den Hintern: du willst eine ganz bestimmte "Layout"-Vorgabe einrichten - nämlich die Maximalbreite deines Menüs - und verkriechst dich jetzt hinter "Inhalte", die du selbstverständlich mit CSS nur in sehr geringem Maß beeinflussen kannst (ein _bißchen_ geht das mit :bevor und :after schon). Also eine Retourkutsche: eine "Änderung am Inhalt" kannst du derzeit nicht wirklich zuverlässig mit CSS realisieren, aber das ist ja auch nicht seine Aufgabe. Und falls ich dich bisher richtig verstanden habe, gehts dir doch gar nicht um Änderungen der Inhalte, das machst du ja eh schon mit einer anderen Technik. Mein Vorschlag war, den "Inhalten" eine Maximalbreite zuzuweisen, was mit CSS sehr wohl möglich ist. Auch wenn es nicht alle Browser wirklich verstehen.

                Dann darf ich es nicht tun.

                Doch, selbstverständlich darfst du die Zahl der maximal möglichen Buchstaben ermitteln.

                Für die Darstellung ist _ausschließlich_ CSS zuständig und sonst nichts. Einfach gar nichts.

                Laß das mal beiseite. In der Theorie, die du hier so vehement ansprichst, stehen wir schließlich auf derselben Seite.

                Mir ist nicht bekannt, daß es in CSS Variablen gäbe.
                Ja, deswegen nutzte ich Konjunktiv. Würde ich dem W3C angehören, würde ich so etwas vorschlagen.

                Solche Vorschläge gibt es bereits.

                Grüße aus Berlin

                Christoph S.

                --
                Visitenkarte
                ss:| zu:) ls:& fo:) va:) sh:| rl:|
                1. hallo,

                  allerdings weißt du, wieviele Buchstabem der längstmögliche Eintrag hat. Also kannst du ausrechnen oder eventuell mit einem Pixellineal nachmessen, welche Maxiamlbreite aufgrund deiner CSS erreichbar ist.
                  Ja, das kann ich ausrechnen. Bewirke ich mit dieser Rechnung eine Änderung am Inhalt?

                  Natürlich nicht, aber jetzt trittst du dir selber in den Hintern: du willst eine ganz bestimmte "Layout"-Vorgabe einrichten - nämlich die Maximalbreite deines Menüs - und verkriechst dich jetzt hinter "Inhalte", die du selbstverständlich mit CSS nur in sehr geringem Maß beeinflussen kannst (ein _bißchen_ geht das mit :bevor und :after schon). Also eine Retourkutsche: eine "Änderung am Inhalt" kannst du derzeit nicht wirklich zuverlässig mit CSS realisieren, aber das ist ja auch nicht seine Aufgabe. Und falls ich dich bisher richtig verstanden habe, gehts dir doch gar nicht um Änderungen der Inhalte, das machst du ja eh schon mit einer anderen Technik. Mein Vorschlag war, den "Inhalten" eine Maximalbreite zuzuweisen, was mit CSS sehr wohl möglich ist. Auch wenn es nicht alle Browser wirklich verstehen.

                  Nein, dann hast du mich leider falsch verstanden. Angenommen ich habe auf meiner Seite zwei Listen, die absolut gar nichts miteinander zu tun haben, außer, dass sie im selben Dokument stehen. Sie haben aber inhaltlich keine Verbindung, sind kein Kindelement eines anderen Elements oder ähnliches.

                  Nun ich möchte ich (weil ich es schön finde), dass beide Listen immer gleich groß sind. Und zwar soll die Kleinere in der Höhe und der Breite immer so groß sein wie die Größere. Das ist momentan mittels HTML und CSS nicht möglich. Es geht nur, wenn man mittels Javascript die Größe ausliest und dann jeweils entsprechend reagiert. Meiner Meinung war nun, dass man dies nicht tun sollte, sondern stattdessen CSS erweitern sollte, was ja auch unentwegt getan wird.
                  Da aber (afaik) ein solches "Feature" auch in CSS 3 nicht möglich sein wird, wollte ich (dich) einfach mal fragen, wie das in Zukunft wohl aussieht, weil es Leute gibt (z.B. du), die sich damit sicherlich schon mehr beschäftigt haben und ich zugegeben zu faul bin, erst groß danach zu suchen.

          2. Mit Design hat PHP nix zu tun.
            Bei Javascript gilt das gleiche.

            ah ja, und html hat schon etwas mit design zu tun oder?

            ich war bisher der meinung, dass man css fürs layout/design verwendet und html für die strukur - dank deiner ausführungen sollten wir alle vielleicht doch wieder mal mit tabellenlayouts (= layout/design mit html) beginnen :p

            1. Mit Design hat PHP nix zu tun.
              Bei Javascript gilt das gleiche.

              ah ja, und html hat schon etwas mit design zu tun oder?

              Nein, warum fragst du? Ich habe das weder explizit noch implizit geschrieben.

              ich war bisher der meinung, dass man css fürs layout/design verwendet und html für die strukur

              Richtig. Und PHP für Datenverarbeitung und Datenausgabe. Und zwar Inhaltliche Daten. Wer mit PHP seine Seite "designed", macht etwas falsch.

              dank deiner ausführungen sollten wir alle vielleicht doch wieder mal mit tabellenlayouts (= layout/design mit html) beginnen :p

              Nein, HTML ist nicht für die Darstellung sondern ausschließlich für den Inhalt zuständig.

              1. Nein, warum fragst du? Ich habe das weder explizit noch implizit geschrieben.

                na warum frage ich ;) du hast ursprünglich indirekt nach einer alternative für tabellenlayouts gesucht (dynamische breite von spalten, obs da eine alternative gibt) https://forum.selfhtml.org/?t=172803&m=1133051 das ist mit tabellen "kein problem", darum hatte ich angenommen, du bist pro-tabellenlayout

                Nein, HTML ist nicht für die Darstellung sondern ausschließlich für den Inhalt zuständig.

                na dann ist ja gut ;)

              2. Hallo.

                Wer mit PHP seine Seite "designed", macht etwas falsch.

                CSS ist egal, ob es durch dich oder ein Script geschrieben wird. Die Trennung von Struktur, Inhalt und Gestaltung bleibt gewahrt.
                MfG, at

                1. Hallo.

                  Wer mit PHP seine Seite "designed", macht etwas falsch.

                  CSS ist egal, ob es durch dich oder ein Script geschrieben wird. Die Trennung von Struktur, Inhalt und Gestaltung bleibt gewahrt.

                  Ja, für den Browser oder den Besucher ist das egal. Nicht aber für denjenigen, der die Website erstellt oder verwaltet. In dessen Kopf wird dann Funktionalität und Design vermischt.

                  1. Hallo.

                    Ja, für den Browser oder den Besucher ist das egal. Nicht aber für denjenigen, der die Website erstellt oder verwaltet. In dessen Kopf wird dann Funktionalität und Design vermischt.

                    Dann muss er vorher aber sehr beschränkt gewesen sein, denn was ändert sich überhaupt?

                    • Der Server wird konfiguriert, CSS-Ressourcen immer oder in bestimmten Fällen durch den PHP-Parser zu schicken.
                    • Die CSS-Ressource bekommt die Variablen, die du dir von CSS wünschst.
                    • Die Werte für die Variablen werden an beliebiger Stelle abgelegt, was ja auch geschehen müsste, wenn CSS sie irgendwo zentral verwalten sollte.
                    • Ein Script fügt die Komponenten auf Anfrage des Servers zusammen und liefert sie aus.
                      Wo soll da jetzt das Problem liegen? Bibliotheken wie GDlib oder Imagemagick machen doch kaum etwas anderes.
                      MfG, at
          3. Erstens nein und zweitens: selbst wenn, was hat das damit zu tun? Das Design der Seite hat nichts mit meinem PHP Code zu tun. Absolut _nichts_ in meinem PHP Code darf etwas mit Design zu tun haben. PHP ist für das Verarbeiten und Ausgeben von Daten zuständig, die Content sind. Mit Design hat PHP nix zu tun.
            Bei Javascript gilt das gleiche.

            PHP kann auch CSS- oder JavaScript-Code generieren.

            --
            Reden ist Silber, Schweigen ist Gold, meine Ausführungen sind Platin.
            Self-Code: sh:( ch:? rl:( br:> n4:( ie:{ mo:) va:) de:> zu:} fl:| ss:| ls:~ js:|
  2. Hellihello,

    lass doch den PHP-Code weg und bau die Tabelle auf. Oder lass das mit der Tabelle, und schau hier unter den mehrspaltigen Layouts.

    Nimm eine Kopfzeile, das Logo links, dann das menu folgend.

    Nimm ein Menu-Div, dass du rechts floaten lässt. Nimm in Inhaltsdiv, dass du links den Margin gibst, den das Menu-Div breit ist. Vom Prinzip her. CSS findest Du in der Anleitung hier.

    Dank und Gruß,

    frankx

    --
    tryin to multitain  - Globus = Planet != Welt
  3. <html>
    <head>
    <title></title>
    </head>
    <body text="#000000" bgcolor="#FFFFFF" link="#FF0000" alink="#FF0000" vlink="#FF0000">
    <table >
    <tr>
     <td rowspan="2" ><img src="images/logo.gif" width="200"> </td>
     <td><?PHP  include('menu.php');?> </td>
    </tr>
    <tr>

    <td rowspan="2"><?PHP  include('inhalt.php');  ?></td>
    </tr>
    <tr>
     <td><?PHP include('menu2.php'); ?>  </td>

    </tr>
    </table>
    </body>
    </html>

    probier mal des

    1. Mahlzeit isi,

      [Antiker Code gelöscht]

      probier mal des

      Nein, lieber Tobald, probier das nicht. Befolge lieber frankx' Rat und erstelle ein zeitgemäßes Layout, anstatt Dich mit Methoden des letzten Jahrtausends herumzuschlagen - Du selbst wirst es Dir sehr bald danken.

      MfG,
      EKKi

      --
      sh:( fo:| ch:? rl:( br:> n4:~ ie:% mo:} va:) de:] zu:) fl:{ ss:) ls:& js:|