backbone: /CSS: kleine darstellungs problem meines tabellen-ramens

moin folks,

hab nen kleines problem bei der darstellung der rahmen farbe. vielleicht schaut ihr euch mal bitte die seite an: http://139.30.17.201:5531/index3.php. mein problem befindet sich am rechten rahmen. dort ist - im vergleich zur gegenüberligenden seite - die rahmen innenseite weiß obwohl ich sie eigentlich als grau definiert habe. kann mir vielleicht jemand sagen wo mein fehler liegt?

thx im voraus.

tschau

  1. hi,

    mein problem befindet sich am rechten rahmen. dort ist - im vergleich zur gegenüberligenden seite - die rahmen innenseite weiß obwohl ich sie eigentlich als grau definiert habe. kann mir vielleicht jemand sagen wo mein fehler liegt?

    du vermischst du ganz lustig html und css - kein wunder, dass da nichts gutes bei rauskommt.

    z.b. im <table>-tag hast du border="1px" definiert - als html-attribut! die einheit "px" hat dort aber gar nichts zu suchen.

    danach kommt dann, z.b. bei der ersten <td>, eine style-angabe "border-style:solid;border-color:#939393;" - wo bitte ist hier die rahmenbreite definiert?

    gruss,
    wahsaga

  2. Hallo backbone,

    http://139.30.17.201:5531/index3.php. mein problem befindet sich am rechten rahmen. dort ist - im vergleich zur gegenüberligenden seite - die rahmen innenseite weiß obwohl ich sie eigentlich als grau definiert habe. kann mir vielleicht jemand sagen wo mein fehler liegt?

    Tja, ich find's auch ziemlich chaotisch, dem, was wahsaga geschrieben hat, schließe ich mich weitestgehend an - ich finde auch die "px" in den html-Angaben etwas ungewöhnlich, aber wenn's der Validator durchgehen läßt...

    Aber ich glaube, der Fehler liegt in der leeren <td></td> in der 6. und 7. Zeile von unten, die dir rechts noch eine Zelle reinhaut.

    Schöne Grüße aus Köln-Ehrenfeld,

    Elya

    --
    Wikipedia: Die freie Enzyklopädie http://de.wikipedia.org
    1. moin!

      Aber ich glaube, der Fehler liegt in der leeren <td></td> in der 6. und 7. Zeile von unten, die dir rechts noch eine Zelle reinhaut.

      danke schön, das war das problem. hatte ich ganz übersehen.

      Tja, ich find's auch ziemlich chaotisch,

      was findest du an der ganzen sache denn chaotisch?

      tschau

      1. Hallo backbone,

        Tja, ich find's auch ziemlich chaotisch,
        was findest du an der ganzen sache denn chaotisch?

        die Mischung von Maßangaben in html und css, die inline-Formatierungen, statt den Elementen class= oder id= zuzuweisen; ich glaube Du kannst es wesentlich übersichtlicher gestalten, wenn Du die css Angaben in den head oder eine externe Datei auslagerst und inline-Styles nur benutzt, wenn du eine Ausnahme von einer Regel definierst. So findest du auch leichter Fehler.

        Schöne Grüße aus Köln-Ehrenfeld,

        Elya

        --
        Wikipedia: Die freie Enzyklopädie http://de.wikipedia.org
        1. moin!

          die Mischung von Maßangaben in html und css, die inline-Formatierungen, statt den Elementen class= oder id= zuzuweisen; ich glaube Du kannst es wesentlich übersichtlicher gestalten, ...

          jo, da muss ich dir irgendwie recht geben. werd ich wohl mal anstreben das in ne css-datei auszulagern.

          tschau und danke fürn tipp.

          so long - marcus

    2. Hi,

      ich finde auch die "px" in den html-Angaben etwas ungewöhnlich, aber wenn's der Validator durchgehen läßt...

      Es gibt Einschränkungen für Attributwerte, die in einer DTD nicht ausgedrückt werden können.
      Dazu gehört, daß es keinen Datentyp "Integer" gibt.
      width und length haben daher den Datentyp CDATA (also mehr oder weniger beliebige Texte).
      15px ist also für den Validator, der gegen die DTD prüft, formal korrekt.

      Die Einschränkung auf eine Zahl steht nur im Kommentar in der DTD.
      15px ist also formal korrekt, aber inhaltlich falsch...

      cu,
      Andreas

      --
      Der Optimist: Das Glas  ist halbvoll.  - Der Pessimist: Das Glas ist halbleer. - Der Ingenieur: Das Glas ist doppelt so groß wie nötig.
      http://mud-guard.de/? http://www.andreas-waechter.de/ http://www.helpers.de/
      1. Hallo Forum,

        ich finde auch die "px" in den html-Angaben etwas ungewöhnlich, aber wenn's der Validator durchgehen läßt...

        Dazu gehört, daß es keinen Datentyp "Integer" gibt.
        width und length haben daher den Datentyp CDATA (also mehr oder weniger beliebige Texte).
        15px ist also für den Validator, der gegen die DTD prüft, formal korrekt.

        Die Einschränkung auf eine Zahl steht nur im Kommentar in der DTD.
        15px ist also formal korrekt, aber inhaltlich falsch...

        Wieder was gelernt - danke für die Erklärung.

        Schöne Grüße aus Köln-Ehrenfeld,

        Elya

        --
        Wikipedia: Die freie Enzyklopädie http://de.wikipedia.org
      2. Hallo,

        Die Einschränkung auf eine Zahl steht nur im Kommentar in der DTD.
        15px ist also formal korrekt, aber inhaltlich falsch...

        Es gibt diverse SGML-Experten, die halten den (überwiegend) natürlichsprachigen Teil der W3C-Spezifikationen, also nicht den maschinenlesbaren Part, für den entscheidenden, normativen Teil, der lediglich noch soweit wie möglich in den DTD- oder XSD-Dokumenten maschinenlesbar wiederholt wird.

        Gruß,

        MI

        --
        XFrames Working Draft (Deutsche Übersetzung) : http://jendryschik.de/TR/xframes/
        Die Wissensgesellschaft : http://jendryschik.de/michael/inf/wissensgesellschaft/
        Einführung in XHTML, CSS und Webdesign: http://jendryschik.de/wsdev/einfuehrung/
        Feste Positionierung, richtig angewandt : http://jendryschik.de/wsdev/css/fixed/
        sh:( fo:) rl:( br:& br:] ' n4:& | n4:? ' ie:| va:) de:] zu:) fl:{ ss:| ls:& js:|
        1. Hallo,

          Die Einschränkung auf eine Zahl steht nur im Kommentar in der DTD.
          15px ist also formal korrekt, aber inhaltlich falsch...

          Es gibt diverse SGML-Experten, die halten den (überwiegend) natürlichsprachigen Teil der W3C-Spezifikationen, also nicht den maschinenlesbaren Part, für den entscheidenden, normativen Teil, der lediglich noch soweit wie möglich in den DTD- oder XSD-Dokumenten maschinenlesbar wiederholt wird.

          Wieso begeht das W3C angesichts dessen den unverzeihlichen und abwegigen Fehler, einen Dienst anzubieten, der den expliziten Anspruch hat, ein Dokument auf seine »Konformität mit den W3C-Empfehlungen und anderen Standards« zu prüfen, welcher aber tatsächlich lediglich gegen die DTD validieren kann? Damit kolportiert das W3C die Missverständnisse, niemand liest die Specs und niemand kommt auf die Idee, dass es fern dem »This Page Is Valid XYZ!« noch andere in Betracht zu ziehende Konformitätskriterien gibt. Zu allem Überfluss wird nirgendwo in der Begleitdokumentation, schon gar nicht direkt beim Benutzen, darauf hingewiesen, dass der sogenannte Validator die Konformität nur sehr eingeschränkt beurteilen kann (in der HTML 4-Spec steht es allgemeines dazu, ein Teufelskreis). Gerade das W3C sollte wissen, dass die Begriffe »Validität« bzw. »(Standard-)Konformität« nicht beliebig definierbar sind und dem Eindruck bzw. der Fehleinschätzung »Der Validator segnet es ab, es ist folglich standardkonform« vorgebeugt werden sollte.

          Vor allem ist es insofern schade, dass der Validator ein recht populäres Werkzeug ist, selbst bei denjenigen, die sich für die anderen Quellen auf w3.org nicht interessieren, und gerade auch Anfängern empfohlen wird, die noch nicht direkt mit den Specs gearbeitet haben - dabei sind die Fehlermeldungen zum Lernen und Verstehen der Hintergründe ungeeignet, und die Lektüre der Specs nimmt der Validator auch nicht ab. Andererseits langweilen bzw. überfordern die technischen Kleinigkeiten und Details der Specs gewöhnliche Webautor wahrscheinlich, sodass die Auseinandersetzung mit den Primärquellen von Anfang an zu verlangen ebenfalls nicht den gewünschten Lernerfolg bringt.

          Gegen das XML Schema für XHTML zu validieren, wäre vielleicht ein anfänglicher Fortschritt (so denn XHTML eingesetzt wird), nur erfordert das ebensoviel Wissen und liegt noch ferner der Lebenswelt eines gemeinen Webautors. Zahlreiche HTML-kompatible XHTML-Dokumente sind sowieso nicht gleichzeitig XML-kompatibel (bspw. fehlt die Kodierungsangabe, weil die XML-Deklaration samt encoding-Attribut weggelassen wurde und per HTTP keine Kodierung mitgeliefert wurde)... und wer liest schon die XHTML-Spec samt Kompatibilitätsrichtlinien im Wortlaut; diejenigen, die blauäugig XHTML schreiben, weil es eben die neustes Variante ist, wissen oft nicht, was sie sich damit für einen Rattenschwanz an Problemen aufhalsen bzw. was sie alles beachten müssen bzw. sollten.

          Grüße,
          Mathias