nicht angemeldet
Hallo,
Für das beschriebene Problem ist der DOCTYPE aber meines Wissens nicht wichtig, weil bei Tabellen das width/padding-Problem eigentlich nicht vorhanden ist. Da der MSIE auch zusätzlich noch einen komischen Scrollleisten-Bug hat, wenn der standardkonforme Modus angeschaltet ist, würde ich dir explizit zum Quirks-Mode raten.
Scrolleisten-Bug ? Was exakt ?
Hm, scheinbar ist das Posting, in dem ich es erklärte, gerade im Zwischenreich (nicht mehr auf der Hauptseite, aber auch noch nicht im Archiv verfügbar).
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%? ...).
Frage vorweg: Bin ich richtig in der Annahme, dass du auf den footerfame.htm eingegangen bist ?
Ja.
Im oberen Frame hatte ich explizit das Problem, dass in der Tabelle die Schriftfarbe (nur Farbe) beim IE6 trotz vordefinierten CSS nicht angezeigt wurde, darum habe ich - meiner eigentlichen Annahme zunächst nach - dazu entschlossen nur zur Sicherheit diese deiner Meinung nach überflüssige Markup reinzunehmen. Werde das von dir angesprochene mal austesten und meinen Bedürfnissen anpassen!
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.
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.
<font color="#ffffff">> </font>
^ Dort ist übrigens ein > zuviel.
Zur Grössendefinition: Ich habe in einer extra platzierten CSS-Datei der <font size="1"> Tag eine feste Pixelformatierung zugeordte (1-3, mehr verwende ich wenn dann nicht). Opera hat dies genau wie NS korrekt erfasst, daher rührt mein Problem sicher nicht.
Ja, ich wusste nicht, ob das eventuell ein Problem darstellen könnte. Ich hätte eher darauf getippt, dass die lokalen Formatierungen über das font-Element in ihrer Wichtigkeit ähnlich wie style-Attribut behandelt werden, nämlich dass sie die globalen Styleregeln überschreiben.
Zeilenhöhe sollte aber eigentlich auch exakt definiert sein (so würde ich es jetzt machen) ?
Die Zeilenhöhe wird meist implizit über die Schriftgröße definiert, das heißt, die Zeilenhöhe/der »Durchschuss« (meines Wissens definiert als Abstand der Basislinien der Zeilen) ist in der Regel Pi mal Daumen Schriftgröße multipliziert mal 1,4 oder so etwas. Du könntest jetzt mit verschiedenen Wertepaaren herumspielen, sodass die zwei Zeilen in der rechten Spalte (Test und Countergrafik) zusammen oder auseinanderrücken, beispielsweise font-size:13px; und line-height:16px;. Zusätzlich wäre wie gesagt die vertikale Ausrichtung (vertical-align) der Grafik (des img-Elements) interessant, dabei machen auch einige Browser Unterschiede (aber eher Mozilla/Gecko, siehe http://www.dodabo.de/html+css/img-table/).
Anders herum könntest du die Tabelle natürlich auch mit height:100% formatieren und die weiße Liniengrafik einbeziehen... oder oder oder.
Wie meinst ? ;-). Wenn ich die Liniegrafik in das Tabellenkonstrukt einbeziehe, meckern doch die Browser, dass die erste Zeile einspaltig ist und die 2. beispielsweise 3.spaltig ? Oder meinst du was völlig anderes ? ;-)
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).
Als Hobbybastler ist man oft noch weit entfernt von einem perfekten Allfunktionstüchtigen Quelltext.
Ja, den Großteil der Zeit verbringt man mit dem Umgehen von Browserunterschieden, -unzulänglichkeiten und -bugs.
Grüße,
Mathias