CiJay86: Tabelle mit bestimmter Höhe

Beitrag lesen

Hoi ;-),

Hallo,

Noch einmal anhand von Inner Frames (das Problem ist ähnlich, quasi dasselbe wie bei Frames):

<img src="http://home.t-online.de/home/dj5nu/fanhost/msie-compatmode.png" border="0" alt="">

Zwei ordinäre iframe-Elemente mit gleicher Größe. Die Dokumente in den iframes sind absolut identisch bis auf den DOCTYPE, sie enthalten im Grunde genommen nur ein paar Textabsätze und sind ansonsten unformatiert. Das Dokument im linken Inner Frame enthält einen XHTML 1.0 Strict-DOCTYPE und löst im Internet Explorer den standardkonformen Rendermodus aus. Das Dokument im rechten Inner Frame enthält neben dem XHTML 1.0 Strict-DOCTYPE eine XML-Deklaration am Anfang und löst den Quirks-Modus aus. Dies hat noch mit einem anderen Bug des MSIE zu tun, hier ist lediglich interessant, dass der Quirks-Modus ausgelöst wird, dies kann wie gesagt durch eine unvollständige Dokumenttypdeklaration oder eben über eine XML-Deklaration passieren.

Zu beobachten ist, dass der MSIE die Breite des Dokuments im linken Inner Frame so anlegt, dass sie der Breite des iframe-Elements ohne Abzug der Scrolleisten entspricht - dadurch geht der Text unter der Scrollbar her und es wird eine horizontale Scrollbar angezeigt.
Im konkreten Fall lässt sich so etwas nur mit bestimmten Styles und der proprietären Eigenschaft overflow-x unterdrücken:
html {margin:0; padding:0; overflow-x:hidden;}
body {margin:0 17px 0 0; /* 17px entspricht der ungefähren Breite der vertikalen Scollbar */ padding:10px;}
Das Problem ist, dass andere Browser alles korrekt machen und man deshalb jedem Browser verschiedene Styles liefern müsste, weil nur der MSIE einer Sonderbehandlung diesbezüglich bedarf (meist werden »CSS-Hacks« verwendet, über welche durch bestimmte Tricks und Selektoren Styles vergeben werden, welche von dem einen Browser ignoriert werden, weil dieser den Selektor nicht versteht, und von anderen Browser interpretiert werden).

Mir ist nicht bekannt, wieso der MSIE diese komischen Sperenzchen macht und auch nicht, wie man sie sauber umgehen kann. In vielen Fällen ist es notwendig, die Breite des body-Elements explizit festzulegen - nur ist diese Möglichkeit nur bei Frames/Inner Frames gegeben, deren Breite fest ist, bei Frames mit variabler Breite lässt sich höchstens raten (95%? 98%? ...).

Danke! Eine ähnliche Beobachtung durfte ich machen, als ich spassighalber den von dir erwähnten Doctype bei der home.htm Seite eingebaut habe. Prompt war im Frame ein horizontaler, absolut sinnloser Scrollbalken (Breite von Tabellle war schliesslich festgelegt). Ich werds wenn nötig umgehen!

Im Grunde sollte diesbezüglich zumindest im MSIE 6 kein Problem bestehen, denn dieser sollte Formatierungen auch in die Tabelle vererben. Meine kurzen Tests zeigen keine Schwierigkeiten.

Dachte ich auch, ich werde nochmal schauen und beheben!

Was ich absolut nicht verstehe (es muss nicht heißen, dass es falsch ist):

<font color="#ffffff">> </font><a href="home.htm">homeBase</a><font color="#ffffff"> < | </font>
<a href="">news</a><font color="#ffffff"> | </font>
<a href="">chase</a><font color="#ffffff"> | </font>
<a href="">gallery</a><font color="#ffffff"> | </font>
...

Warum sind hier die font-Elemente nötig? Du kannst für die Zelle (über theoretisch für jedes Element darüber) color:white; angeben, dadurch sollte der Text in der Zelle weiß sein. *Links hingegen* haben, sofern die CSS-Regeln dafür entsprechend und richtig angebracht sind (und dass sind sie in deinem Fall), immer die Formatierung, die du ihnen zuweist - insofern kannst du ruhig pauschal eine Schriftfarbe vergeben, ohne dass die Links davon beeinträchtig werden.

Die Links sind nicht extra doppelt mit Markup versehen, hier *zieht* die CSS-Datei so wie es sein soll. Das bestehende Markup ist für die Zeichen zwischen den Links angedacht, es reicht aber sicher aus, wenn ich das in der Zeile nur einmal definiere, mal schauen.

<font color="#ffffff">> </font>
                      ^ Dort ist übrigens ein > zuviel.

Keine Sorge, das ist beabsichtigt, das Zeichen soll man extra sehen. Sollte Komplikationen auftreten (Könnte?) werde ich einfach ein anderes Zeichen nehmen, oder es wie die Umlaute und das Leerzeichen allverständlich kodieren. Ich bin dahingehend meist ein wenig faul, aber wenn der Rohling erstmal vernünftig fertig ist, brauche ich die schon fertigen Inhalte ja fast nur per Copy & Paste nachtragen ;-)

Das wäre durchaus möglich, es besteht die Möglichkeit, mehrere Zellen zeilen- und spaltenübergreifend zu einer Zelle zusammenzufassen. Dazu bedient man sich der HTML-Attribute colspan (column span, Spalten-»Spannweite«, folglich die Anzahl von horizontalen Spaltenzellen, über welche sich die Zelle erstrecken soll) und rowspan (row span, Zeilen-»Spannweite«, folglich die Anzahl von vertikalen Zeilenzellen, über welche sich die Zelle erstrecken soll). Siehe: SELFHTML -> HTML/XHTML -> Tabellen -> Zellen verbinden http://selfhtml.teamone.de/html/tabellen/zellen_verbinden.htm. Das sähe in der Anwendung folgendermaßen aus:

<table>
<tr>
<td colspan="3"><img src="liniengrafik.png"></td>
</tr>
<tr>
<td>erste Spalte</td>
<td>zweite Spalte</td>
<td>dritte Spalte</td>
</tr>
</table>

Die erste Zeile erhält folglich eine Zelle, welche sich über drei Spalten erstreckt (deshalb muss in dieser Zeile nur ein td-Element enthalten sein). Da diese Tabelle das einzige wäre, was in dem unteren Framedokument enthalten wäre, könntest du ihr per CSS height:100%; verpassen (das Attribut height ist für das Element table nicht erlaubt, aber wahrscheinlich für alte Browser notwendig, falls du diese unterstützen willst).

Danke, ausführlich und in einem Beispiel erklärt. Man lernt halt immer wieder Tags kennen. ;-)

Ja, den Großteil der Zeit verbringt man mit dem Umgehen von Browserunterschieden, -unzulänglichkeiten und -bugs.

*sehr* viel ist nicht mehr zu tuen. Einen Teil habe ich auf meiner Festplatte schon geändert, unabhängig von der Online-Version. Werde noch hier und da Kleinigkeiten entdecken und *lifte* den Quelltext immer weiter, er soll auch möglichst sauber sein im GG. zu vielen von mir vorher geschriebenen Webseiten, wo man daran nicht so dachte. Hat ja auch alles funktioniert, aber 1-2 Leute gibs dann doch immer, bei denen die Seite *verhunzt* dargestellt wurde, weil eben was wichtig falsch gemacht wurde, oder mal ein Hack zur Behebung von Bugs unbekannt war.

Dar Exkurs weitet sich ja ganz schön aus, hilft mir aber, mein teilweise nur sporadisches Wissen weiterzuverarbeiten.

CYA
Christian

Grüße,
Mathias